Lambda the Ultimate

From The Computer Science behind ToonTalk:

ToonTalk is an interpreter for a concurrent constraint programming language. Concurrent constraint programming is a synthesis of concurrent logic programming and constraint logic programming. (See, for example, Saraswat). The class of languages for which programs are roughly interchangeable with ToonTalk programs include Oz, E-Lang, Janus, Flat Guarded Horn Clauses, KL1/KLIC, Flat Concurrent Prolog, Parlog, and Strand. The syntax of all these languages is textual while ToonTalk has an action-oriented video game animation syntax. The programming environment is completely different as well. In ToonTalk, the process of constructing, testing, and debugging programs closely resembles playing a video game.

A major lesson from the whole ToonTalk endeavor is that powerful concepts actually simplify programming rather than complicating it. Programming is complicated when you are not able to use all the natural concepts for a problem.

Children use ToonTalk but they don't usually reason about programs. Professional software engineering requires the ability to reason about programs (whether formally or unformally) and this is one reason why restricted models can be useful. They may complicate programming, while simplifying reasoning.

IMHO, the use of the word "may" here is extremely misleading: every day in my current job, professional software engineers attempt to reason about a concurrent distributed system written from the OS API level up in C++. C++ certainly implements a more restricted model that ToonTalk or Oz, but I can tell you from bitter experience that it doesn't simplify reasoning about my company's product; far from it. So if you're going to select a restricted model relative to a ToonTalk or an Oz in order to simply reasoning, by all mean do so, but the implication is that you have N potential models to select among and the freedom to select the one that best matches your application domain. I'm quite certain that my employer didn't select C++ through a process even remotely resembling that. By contrast, I take Peter's point to be that if first-time programmers are actually exposed to multiple models early on, they'll be in a better intuitive position later on in life to make sound judgments as to whether any given model is best applied to solving any given problem or not. With further education, these intuitions can be made explicit and then articulated. The problem that I so often see is that experienced working programmers' intuitions about other models are non-existent, as when I asked a fellow C++ programmer about some code including std::for_each(v.begin(), v.end(), cout << constant(ios::setw(2)) << constant(ios::setfill('0')) << _1 + 0); and he insisted that the code wouldn't even compile, whereas in fact it's a pretty straightforward application of boost::lambda.

The bottom line is that it's just like, IIRC, John Coltrane said: you have to know the rules before you can break them.