Lambda the Ultimate

First of all, I think that Lambda the Ultimate should be renamed to Pi the Ultimate. In my view, the lambda calculus is past tense; the future belongs to process calculi deriving from the pi calculus. Process calculi are much more expressive: e.g., one I am studying now, the M calculus (Schmitt & Stefani) can express many important idioms of distributed computing in a simple way. There are many other interesting calculi; I don't want to digress too much on any specific one right away.

The lambda calculus is too limited in expressiveness; we need concurrency and explicit state, and we need to talk about distributed systems and partial failure and security, and so forth. These and other concepts will eventually trickle down into the programming language, and process calculi are showing the way.

The general kernel language of my book (which I will call 'CTM' from now on) is a process calculus that is based on concurrent constraints. It has a different design goal than the usual process calculi, which are designed to be minimalist. The kernel language is designed to be expressive, i.e., to have the concepts needed by programmers. But it is still a process calculus.

As a final point, note that we are not losing anything w.r.t. the lambda calculus, since it is a subcalculus of a well-designed process calculus. A good process calculus has a layered structure; you pick the subset that has the concepts you need and this determines the reasoning techniques that you can use. So you can still do nonstrict functional programming (or whatever) in those places where it's best, and what's more the functional programming interoperates seamlessly with the rest.

(There are a few other topics I would like to discuss; I will start separate discussions for them.)

I think I would find this much easier to take if I didn't imagine the sound of cell phones ringing every time I read about the pi calculus. ;-)

I wonder if distributed models can help us with these issues, or do they only add more issues that need to be addressed.

A distributed model will not help with sequential programming AFAIK, but a concurrent model can be useful. As I mentioned before, a sequential program ties together its components too tightly. I.e., if one component needs to do something then all others have to wait for it.

Ehud, what a catch! Welcome, Peter Van Roy, and thank you for signing up. I second Ehud's exhortation to be opinionated. One thing that impresses me about your work is its attention to the problem of putting useful academic results into the hands of workaday programmers. LtU shares that laudable goal, maybe not as the prime directive, but in general. Many workaday programmers scoff at academic work, so part of the task includes clear-cut, but measured, opinions. Take Frank Atanassow as your model for opinionated style. (That's a compliment, Frank.)

Another part of the task is to create tools. It's good to see Flow Java on the LtU home page and more attention-grabbing LtU headlines about Alice ML and the rest of the family. Looking forward to more, -Mark