• bearophile (6/6) Jan 02 2009 According to this article, the only hope for the future of efficient pro...
• Sean Kelly (19/25) Jan 03 2009 There was a good article in Communications of the ACM about

bearophile <bearophileHUGS lycos.com> writes:

According to this article, the only hope for the future of efficient
programming is going all the way toward immutable data (with a functional
programming style, I presume):

http://enfranchisedmind.com/blog/2009/01/02/the-problem-with-stm-your-languages-still-suck/

I don't know much still about this topic, but I think a compromise solution may
be possible/better: the whole global program may be purely functional, where
all data/objects are essentially immutable. But there can be kernels (generally
methods/functions) that are mostly meant to run on a single CPU for a short
time that inside use locally mutable data and procedural code (they can be like
pure functions in D2). I think today there are no languages that allow this,
designed for this type of mixed programming (If you know of a language like


Can D2 be programmed like that? Probably not, it requires a different kind of
compiler (able to compile typical FP constructs more efficiently), and a
different mindset for the programmer.

Bye,
bearophile

Sean Kelly <sean invisibleduck.org> writes:

bearophile wrote:
 According to this article, the only hope for the future of efficient
programming is going all the way toward immutable data (with a functional
programming style, I presume):
 
 http://enfranchisedmind.com/blog/2009/01/02/the-problem-with-stm-your-languages-still-suck/

There was a good article in Communications of the ACM about 
transactional memory a few months ago that discusses its problems in 
greater detail, but that blog article is in the right ballpark.  The 
short answer is that it's a neat idea with potential, but it does have 
some fundamental problems that make it not ideal for a lot of applications.

 I don't know much still about this topic, but I think a compromise solution
may be possible/better: the whole global program may be purely functional,
where all data/objects are essentially immutable. But there can be kernels
(generally methods/functions) that are mostly meant to run on a single CPU for
a short time that inside use locally mutable data and procedural code (they can
be like pure functions in D2).

This is what I've been saying for years.  I think it's where we're headed.

 I think today there are no languages that allow this, designed for this type
of mixed programming (If you know of a language like that please tell me. I


Erlang /might/ be in this category, if only because it's a functional 
language with some support for mutable data.  But realistically, it's 
more likely that some processes in an Erlang app would be written in C, 
with the requisite message passing between them and the Erlang app.

 Can D2 be programmed like that? Probably not, it requires a different kind of
compiler (able to compile typical FP constructs more efficiently), and a
different mindset for the programmer.

Since it's possible for mutable code to call pure code but not 
vice-versa, I think D2 is designed somewhat the opposite of what you're 
suggesting.  But since even pure code can use local mutable data, the 
picture isn't quite so clear.  Toss in monads for system operations and 
D2 may just be able to do this sort of thing.  The outstanding question 
is whether the syntax and such will make it appealing to do so.  I 
personally haven't done enough FP in D to say.


Sean