notes-computer-programming-programmingLanguageDesign-prosAndCons-lucid

" One of my favorite old languages is one called Lucid by Ed Ashcroft. It was a beautiful idea. He said, “Hey, look, we can regard a variable as a stream, as some sort of ordered thing of its values and time, and use Christopher Strachey’s idea that everything is wonderful about tail recursion and Lisp, except what it looks like.” When he looked at Lisp, he had a great insight: which was that tail-recursive loops and Lisp are so clean because you’re generating the right-hand side of all the assignment statements before you do any rebinding. So you’re automatically forced to use only old values. You cannot rebind, so there are no race conditions on anything.

You just write down all of those things, and then when you do the tail recursion, you rebind all of those variables with these new values. Strachey said, “I can write that down like a sequential program, as a bunch of simultaneous assignment statements, and a loop that makes it easier to think of.” That’s basically what Lucid did—there is no reason that you have to think recursively for things that are basically iteration, and you can make these iterations as clean as a functional language if you have a better theory about what values are.

This idea, by the way, was used in [Squeak contributor] Dave Reed’s fantastic thesis for coordinating object siblings where you have one logical object but many physical manifestations of the same object on different machines, and you have to make them track each other by transactions.

The way to get rid of these things (like Smalltalk) is to make something that is much, much more powerful as a computation model and much more expressive for the core programmer who is trying to write programs. In these late programming languages, you can disappear the old guy and just leave the new guy behind. So we are doing that at this moment. " -- Alan Kay, queue.acm.org/detail.cfm?id=1039523