[Peter Van Roy](http://www.info.ucl.ac.be/~pvr/) recently claimed

([article](http://www.info.ucl.ac.be/people/PVR/flopsPVRarticle.pdf),

[slides](http://www.info.ucl.ac.be/people/PVR/flopsPVRtalk.pdf)) that

there are signs of a *Definitive Programming Language* emerging that gives

> good solutions at its level of abstraction, allowing computer

> science researchers to move on and work at higher levels.

The argument is based on the observation that *four* languages,

designed *independently* and for *different purposes* all arrived at

the *same* layered language design of

1. strictly functional language at the core

2. deterministic concurrency (aka dataflow concurrency)

3. asynchronous message passing

4. global mutable state

The claim is that the odds of this happening at random are the same as

lightning striking in the same place four times and that instead we

should consider this particular language structure as a definitive

design that arises naturally and inevitably.

Unfortunately these claims do not stand up to scrutiny.

There are not four languages. The languages examined are Erlang, E,

Oz and, er, Oz. In other words Oz is in there twice, once as a

language for network-transparent distributed programming, and once as

a teaching language.

There are not four different purposes. The stated purposes of the

languages are Fault Tolerant Programming (Erlang), Secure Distributed Programming (E), Network-Transparent Distributed Programming (Oz), Teaching Programming Languages as Unified Discipline (Oz).

It is well-known that the only way to get fault-tolerance is through

redundancy, and that the only way to get redundancy is to have

multiple machines. This implies distributed programming. Many of the

language design choices in Erlang are due to it needing to deal with

this, not with fault-tolerance per-se. Similarly, E from the very

beginning aimed to be a language for *distributed* secure programming,

and many of its design choices are motivated by needing to deal with

distribution, not security per-se. Thus both Erlang and E derive many

of their design decisions from the feature that has been the main

driver for Oz – distributed programming.

The languages were not designed independently. It may be true that the language designs were carried out independently from *each

other*. However, there was a large body of previous research in the

area of distributed programming, which heavily influenced the design

of all the languages.

The languages do not have the same four layers. Erlang and E are missing layer 2 and 4

respectively, and E has a completely different layer 1 than claimed –

its core language is imperative, not functional, and E’s functions are

in fact just sugar for objects. The only layer that is common to all three is message passing. Given

that we have identified distributed programming as *the* guiding

design objective of all languages that is hardly surprising since

message passing is *the* fundamental mechanism by which distributed

systems communicate.

So we really have *three languages*, designed with the help of a large

*common body of research*, for the same *single purpose*, arriving at

the same *single layer* of abstraction for that purpose. There is no

statistical significance in that.

Even if the statistics were right, the idea of judging the fitness of

programming language design on the basis of such statistics is

fundamentally flawed. The known design space isn’t all that large so

the chances of several languages independently making similar design

choices is quite high. Language design follows trends. It is not at all uncommon to see several languages make similar design decisions which ultimately turn out to be wrong. For example there are a whole bunch of

languages with an imperative core, threads & locks, rpc, centralised

or replicated transactional store. That doesn’t make it any more

likely that this particular design is correct.

Despite all that the conclusions of the paper still have some

merit. The proposed four layers are indeed a pretty good design for a

distributed programming language. However they are by no means the

*only* sensible design. For example, actors and process algebras have

concurrency and distribution at their heart and arguably span all of

the proposed four layers with a minimum set of non-layered language

constructs. I am also becoming increasingly convinced that

transactions will turn out to be an essential, fundamental

feature. Overall there is still a lot of research to be done and we

are nowhere near a definitive language yet.