Just recently discovered the E Programming Language. Very interesting concept. It’s nice to see a something growing out of the Algol/C/C++/Java tree that improves the syntax. And a mainstream language that can handle concurrency well without blocks and locks is definitely needed. Making programmers deal with threads and mutexes is definitely too hard, just like assigning registers in Assembly language is too hard. I wonder, however, if E doesn’t merely shift the focus of the problem without truly solving it. If I understand E in a Walnut, programmers using E still have to keep mental track of the difference between local, immediate-return method calls and possibly-remote, eventual “promises.” The when (xVow) -> done(x) syntax also looks a bit odd.
My question is this: is it necessary to distinguish, at the language level, between immediate values and promised values? As long as the compiler knows which is which, who cares? The when-catch construct seems to exist primarily to help programmers used to conventional threaded multiprocessing and try/catch blocks catch their breath.
I have always assumed that in purely functional languages — Haskell, ML, maybe Scheme? — expressions could theoretically be evaluated in any order, on any processor. Note I say theoretically, as I am not aware of any implementations that do this. Could one write an expression, using values that may come from any computer, anywhere, and trust that the compiler will do the necessary things to ensure that all the values end up in the right place at the right time to produce the final result?
Update, 4 May 2006: Maybe not. A Note on Distributed Computing says that, in the real world of latency, unreliable networks, and component failures, local and remote objects are inherently different and have to be treated differently at the application level. A reasonable argument, but I still like to believe it would be possible to have the differences handled by a compiler.