Preliminary call for participation to MOZ 2004

MOZ 2004 is devoted to bringing together people interested
in the Oz language and the Mozart development platform.
MOZ 2004 will take place in Charleroi, Belgium on October
7-8, 2004. Early registration is possible until August 22.

MOZ 2004 will have two invited speakers (Gert Smolka, the
father of Oz, and Mark Miller, the father of the E secure
distributed language) technical sessions (see the list of
all 23 accepted papers), five tutorials (general overview,
constraint programming, distributed programming, teaching
programming, and tips on practical deployment), and a
panel on the future of Oz. Last but not least, MOZ 2004 is
an excellent opportunity to meet and discuss with the
Mozart designers and other users.

Erlang the Movie


From: mike@erix.ericsson.se (Mike Williams)
To: erlang-questions@erlang.org

[...]

As one of the main "actors" in "Erlang the Movie", I
absolutely and categorically forbid its showing *anywhere*. If there
was a competition for "turkey" short movies, I think we would win
hands down.

So, please, please, please, forget we made that retched film in 1990!

That's right, now you too can own the movie that "Bjarne used whenever he wanted to get rid of unwanted guests at CS lab parties"! Download the torrent or the file on erlang.org if you have 200MB of disk space to spare!

No, no and again, NO!!!

Well, that's one way of doing it...

You're part of the C# language design team thinking about the next version of C# (ie the version after VS 2005). You get the following email:

When I'm writing code, I often come across a situation where my code throws an exception because another component called with a null parameter. I'd like a way to prevent that from happening.

What are the pros and cons of such a feature? What are the ramifications of adding it to the language? What would have to change? What is your recommendation? Exactly what would such a feature look like?

A discussion over on Eric Gunnerson's weblog.

I suppose this is one way of doing language design. You are welcome to comment on the specific issue, or on this cutting edge language design technique ("just blog it, silly")...

Just to get the juices flowing, I should point out that this is a type system issue.

Should we have a language design department for general discussions about language design?

The right default: concurrent components with message passing

Here's something to offset all the
long discussions on typing that
have been taking place recently
(see Concurrent Components With Message Passing):

In our experience, the right default for structuring programs is as concurrent components that communicate through asynchronous message passing. Components should be sequential or communicate synchronously only if necessary. This is not a new idea; Carl Hewitt anticipated it thirty years ago in the Actor model. But today we have many strong reasons for accepting it. For example: [...] (discussion continues with
references to Erlang, E, and CTM)
[...] Unfortunately, these reasons and their conclusion are almost completely ignored by mainstream languages and by books on program design. In both, object-oriented programming and shared-state concurrency are given priority, even though they are the wrong default. [...]

So, is this heresy or an unfortunately ignored truth?

Python Decorators

A short and accessible explanation of decorators (new in Pyton 2.4). [via Keith]

Scrap more boilerplate

Scrap more boilerplate. Ralf Laemmel and Simon Peyton Jones. ICFP'04.

We extend the "scrap your boilerplate" style of generic programming in Haskell to accomplish an additional range of applications. This includes several forms of serialisation and de-serialisation, test-set generation, type validation, and type erasure. To this end, we provide a well-designed reflection API for datatypes and constructors, and we also provide more general means of extending generic functions for given monomorphic or polymorphic types. The presented approach is readily supported in the GHC implementation of Haskell.

The previous "boilerplate" paper was discussed here in the past.

This is a interesting paper and there are many reasons why I should link to it, but I'll let you guess the number 1 reason (hint: check section 10).

"Your" RDF Query Language

Kendall Clark of the Data Access Working Group (part of the W3C's Semantic Web initiative) has posted regarding their work on a query language and access protocol for RDF. The DAWG has recently released the 2nd draft of its Use Cases and Requirements and is looking for community input. Their initial query language design, BRQL, looks SQL-like but is designed to operate on graphs/sets of triples.

Programming as an Experience: The Inspiration for Self

(this paper by way of lispmeister)

    Abstract: The Self system attempts to integrate intellectual and non-intellectual aspects of programming to create an overall experience. The language semantics, user interface, and implementation each help create this integrated experience. The language semantics embed the programmer in a uniform world of simple objects that can be modified without appealing to definitions of abstractions. In a similar way, the graphical interface puts the user into a uniform world of tangible objects that can be directly manipulated and changed without switching modes. The implementation strives to support the world-of-objects illusion by minimizing perceptible pauses and by providing true source-level semantics without sac rificing performance. As a side benefit, it encourages factoring. Although we see areas that fall short of the vision, on the whole, the language, interface, and im plementation conspire so that the Self programmer lives and acts in a consistent and malleable world of objects.

Featured in Sun Labs: The First Ten Years (1991-2001).

Unfortunately their website appears as a black hole if you have TCP Explicit Congestion Notification enabled. This is the default with Linux 2.6, but you can disable it with:

echo 0 > /proc/sys/net/ipv4/tcp_ecn

MzTake: A Scriptable Debugger

The scripting in MzTake is done in the FrTime language. This connection is based on the observation that the program being monitored is a source of events, and FrTime is designed well to receive events from the outside world. Therefore, the script programmer has the full power of FrTime (which includes almost all of Scheme, graphical routines and some rudimentary GUI support, in addition to several event-based programming primitives) for automating program monitoring.

The site includes several examples that are worth checking even if you aren't planning on installing MzTake.

I like the idea of program monitoring. It is related to the notion of instrumentation, which is of course a well known sofware design technique.

This is yet another example of how language design can help handle software engineering issues.

Udell: A strategic vision for dynamic languages

We're going to need a fabric of pervasive intermediation, and the TCP/IP of Web services -- that is, SOAP -- will enable that. But we're also going to need a whole lot of agility woven into that fabric. I want middleware that works like Indigo, but I want to program it in a language that works like Python.

Jon Udell is one of the champions of so-called dynamic languages. This item is yet another attempt to explain the importance of dynamic languages and the central role they should play in building complex networked applications.

I am sure all you guys debating static typing in the forum are going to find this worth reading (and worth debating).