Well, well...

[Sean Kelly]

Walter Bright wrote:
> Nick Sabalausky wrote:
>> I'm not trying to de-emphasise concurrency, it's just that reliability 
>> and productivity are where my focuses have been lately, so that's what 
>> I have the most to say about. My only experience with concurrency has 
>> been just with one microcontroller (Parallax's Propeller).
> 
> I'm beginning to suspect that many issues that surround concurrency are 
> related to reliability - issues like better modularity.

I think this is true.  Concurrency designed around message passing is 
far more scalable than concurrency involving shared state, for example, 
and message passing is really nothing more than a mechanism to increase 
modularity.  In fact, I've pretty much decided recently that concurrent 
programming is really slowly working towards a pure message-passing 
design similar to Erlang, and that library solutions in traditional 
imperative languages are simply attempts to extend the useful life of 
existing code (futures, etc).

What I would personally find most interesting is if systems programming 
facilities were exposed in such a language, since this would provide a 
solid mapping between a task and a CPU.  From what I gather, Erlang 
currently calls C routines for much of the performance-critical or 
low-level work, and the need to integrate two languages doesn't seem 
terribly ideal, assuming everything could be elegantly combined.

As an aside, one interesting aspect of Erlang is that it turns code 
reliability on its head to a degree by simply aborting the process if an 
exception occurs.  This seems far preferable to the manual exception 
recovery typically done in C++, Java, and D, which reduces code clarity 
and can be difficult to get right.  Concepts like DBC, however, provide 
a quite useful degree of boundary checking, and seem applicable 
regardless of the degree of modularity introduced.


Sean