Goedel's Theorem and Theories of Arithmetic

Logic is the cornerstone of computer science in general and much of programming language theory in particular. Goedel's results are fundamental for any real understanding of modern logic.

This book by Peter Smith might serve as an introduction to Goedel's incompleteness results. Twelve chapters are online, and seem quite readable.

New result re "linguistic determinism"

Hunter-gatherers from the Piraha tribe, whose language only contains words for the numbers one and two, were unable to reliably tell the difference between four objects placed in a row and five in the same configuration, revealed the study.

A new study may provide the strongest support yet for the controversial hypothesis that the language available to humans defines our thoughts.

The result is controversial enough that I withhold judgement until I read the journal paper.

Error handling strategies

Some kind of language support for error handling (e.g exceptions of various kinds, on error blocks, Maybe types, continuations etc.) has become standard. The exact mechanism is yet another language design decision designers have to make.

Eric Lippert describes VBScript's error handling mechanims. The VBScript approach is perhaps more confusing than it has to be (though I personally didn't find Eric's examples confusing). Tying exception handlers to blocks is more structured and perhaps better.

Be that as it may, I think better error handling constructs are still waiting to be discovered (or designed).

Graham Hutton: Programming in Haskell

The first five chapters of Hutton's introductory Haskell book are online.

The chapters cover fairly basic features, and wouldn't be of interest to the Haskell experts among us, except as teaching material.

However, those intrigued by all the recent references to Haskell can get a taste of what Haskell is about from this readable introduction.

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).