www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Transactional Memory, localized procedural programming, etc

reply 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
that please tell me. I think Scala and F# are different).

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
Jan 02 2009
parent 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
think Scala and F# are different).

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
Jan 03 2009