Guy Steele on Language Design

(via PLNews)
Thoughts on Language Design

Computers with multiple processors are becoming more and more common. We need programming languages that support the use of multiple threads of control. [...] In such a context, the organizing principles of structured programming may not always be appropriate. I'm not talking about avoiding goto. (Java has no goto statement.) I'm talking about sequencing, if-then-else, and loops.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

FP already offers what Steele asks for.

Pure functional programs are already fit for multiple processors.

It seems to me that that the IT industry is going in circles. LISP is already 50 years old, yet we are now rediscovering its principles.

Perhaps more CS education is needed?

Surely, pure FP offers a real

Surely, pure FP offers a really good way to do it - and I'll bet Guy Steele understands it better than ourselves :) - but it demands muich more training and education than more complex solutions, e.g. OO-ed threads.

IMHO you are partially right: more CS education would bring classical but modern stuff to the busines world, but I think the business itself rejects the academic CS education influence when possible[1], trying to maintain the programmers' work cheap.

[1] Well, I'm talking about mainly small and medium corporations.

Small and medium corps?

I think it's especially the big corps that warm up non-academic kludges when they have all kinds of treasures in their research departments. See Sun or Microsoft.

OO threads are easy? demands muich more training and education than more complex solutions, e.g. OO-ed threads.

Is teaching OO threads (really monitors), the ins and outs of locking, deadlock and starvation avoidance, really all that much less difficult than teaching FP? There are entire textbooks devoted to multithreaded programming in (as one example) Java, because it's so hard. Most Java texts recommend avoiding threading unless you absolutely need it, in part because it's so hard to get right. Now, if we were talking about a different concurrency model (such as Erlang's, or occam's) I'd agree that concurrency is easier to teach than FP. But otherwise, I have a hard time seeing it.

monitors, coroutines and 'real threads'

As a beginner, I wish we would stop talking about general "threads"...the term covers too much. I've never seen an explanation of threads in terms of monitors, coroutines, futures, promises, data flow, etc. in one place. I've been trying to understand how Oz can create 100 times more threads than Java...but haven't found a simple explanation (something to do with a smaller stack, but not in detail, certianly not for non-experts). Perhaps someone can point to a paper or do a little write-up explaining various kids of 'threads' AND how they are implemented in real compilers.

Lightweight threads

as in Oz, in Scheme48, and in many other languages (Erlang too I think) are user-level threads, as opposed to kernel-managed threads that involve system calls, overhead in the kernel etc.

User-level threads don't need an extra stack, as they can use other memory management schemes, such as a global garbage-collected heap, or small individual heaps, or smaller-than-usual stacks, if you know they don't need much space. OS-level threads always have to be open to anything, so they pack a full stack that can run arbitrary C code, without the kernel having to know anything about the actual *code* that's run..

Light-weight threads using cheap continuations

One way to implement light-weight threads is to use a language (or rather a language implementation) that provides cheap continuations. That is (AFAIK) basically how Concurrent ML (CML) is implemented on the SML/NJ compiler. The CML book Concurrent Programming in ML has a chapter on the implementation techniques of CML. You can also find examples of how to implement threads using continuations from many sources. For example, see the slides 40-42.

I really doubt FP requires more training than OO.

I bet that if someone did tests on which kind of programming is easier to learn (for someone not infected yet with OO-ness), the results would clearly show FP a much better proposition. OO is very hard to use effectively, especially with braindead languages like Java or C++.


man, you changed a lot. I remeber you claiming C++ was the best language out there and imperative programming was king. And that was just a few months ago! New Year's Resolution? ;)

FP-for-multiprocessor references?

Can you point to any studies/papers about using FP versus explicit threads? (real threads, of course; not coroutines)

The software I work on right now absolutely requires full use of dual-processor machines.

Maybe I'm wrong

but from what I understand threads are really no different from processes, it just has to do with the level of sharing between the threads/processes. Threads are on the one end where almost everything is shared, and processes are at the other where nothing is shared. As I understand it, there is no fundamental reason why there cannot be more flexability as to what exactly is shared and what is not shared. In fact, if I remember correctly, the Linux Kernel allows such a dynamic in sharing between processes, so that there can be full threads (everything shared), light weight processes (some stuff shared), and heavyweight processes (nothing shared). So, in the end, there is no reason why you would need threads per se, as you don't have to share memory to have concurrent processes. There are other models of concurrency out there besides shared state concurrency, and although shared state concurrency should perform better, once you put in place the nessicary mutexes in place not only is it less effecient, but now you have a whole host of problems with deadlock and starvation. Of course languages could use threads in the background, even though the model of concurrency isn't a threaded model. Erlang, for example, could do such a thing (I don't believe it currently supports true threads yet. Anybody know?)


What I'm interested in is the difference between:

* FP's referential transparency, where no synchronization/mutexes/semaphores/etc are needed (because there is no shared (mutable) state). There is of course synchronization needed when waiting for a return value, but this can be hidden, especially when the semantics of the language don't specify evaluation-order.


* "Threads"' need for synchronization methods.

Both can run on multiple-core machines, but where FP would need (?) to provide some kind of indication where a function call should be run, the typical threading mechanisms require explicit management of many more things.

Anyone see any good publications on this?


Steele seems to be a literate person.

Why doesn't he mention Erlang (which was designed for concurrent programming) or one of languages which were extended for concurrent programming (Pascal , C++, Haskell,..)?

It is bit depressing that a mainstream publication like DDJ gives no hit, when searching for Erlang. :(


but not surprising at all

"bit depressing that a mainstream publication like DDJ"

mainstream is mainstream



Re: Ada?

Re: Ada?


The article reads like the beginning of a marketing drive for Fortress....

I'm thinking that, for the processors that (I think) Steele is thinking about, traditional threads and distributed languages will not scale. Take, for example, the Cell processors: potentially a large number of processor cores made up of a general purpose processor and a large number of special purpose processing elements. I could be wrong, but for most situations I don't see how programmer-level parallelism could take advantage of such a beast.


  • Data-flow,
  • Thread-per-object,
  • or functional programming.
Or, something else entirely.


Sorry, I cannot not resist to promote my current favorite language, but Occam has exactly the properties that Guy Steele wants to invent! It is imperative, and concurrency feels as natural to write as sequentiality. If only people would not be alienated by things like UPPERCASE and
indentation that matters.

Sigh ...


My, a blast from the past. Who is still using it? I've not seen anything about the language since the Occam 3 guidebook, which must have been around 1990 or so.

KRoC and the Transterpreter

The good people at the University of Kent at Canterbury have been working on the KRoC occam compiler for some time. KRoC is built on top of the INMOS occam compiler, but adds a bunch of extensions to allow things like mobile channels and mobile processes. Fred Barnes, who is the principal developer on KRoC these days, has also started work on a brand new occam compiler, built from scratch.

You might also be interested in the Transterpreter, which is a VM for Transputer byte code, and runs on Windows, Linux, Macs, and Sun Sparcs (as well as LEGO Mindstorms). It'll run code generated by KRoC, although I don't believe that it implements all of the mobility extensions.


Looks interesting. Very interesting, in fact.

I liked occam as a programming language, but the language environment, at least for UNIX, was simply horrible. It's nice to see people playing with the language again.

Occam adoption

I don't think that mandated indentation is a big issue - after all, Python and Haskell (among others) use whitespace for block delineation. Granted, occam is a little more strict on the use of whitespace (although I think that recent versions of KRoC may have an option to be less strict.

The uppercase keywords are a bit of a problem. They make occam seem "old", and they can be somewhat uncomfortable to read for people who are used to thinking of uppercase as "shouting". There are some proposals out there for modifying the syntax to be more palatable . Not sure if they'll ever catch on though.

Having said all of that, I don't think the syntax of occam is all that big a handicap. IMHO,what has really been holding back occam is the lack of a cross-platform compiler or runtime (for some time it's been Linux-only - at least up until recently), awkward I/O (no printf's), very limited libraries, limited documentation on new features, and very little in the way of graphics capabilities (although Fred Barnes has recently done some work on that end of things). In other words, all of the same things that hold back many languages that have some neat features, but are missing enough things that most people aren't willing to give them a go.

Don't get me wrong - I think occam (particularly in its occam-π incarnation) is a great language. And I have high hopes that the transterpreter VM will increase occam usage (especially if they can support the mobile code features of occam-π). But right now occam simply lacks critical mass.