const

Sean Kelly sean at invisibleduck.org
Thu Mar 27 15:48:05 PDT 2008


== Quote from Darryl Bleau (user at example.net)'s article
> Walter,
> > 4. Here's the biggie. Points 1..3 are insignificant in comparison. The
> > future of programming will be multicore, multithreaded. Languages that
> > make it easy to program them will supplant languages that don't.
> > Transitive const is key to bringing D into this paradigm. The surge in
> > use of Haskell and Erlang is evidence of this coming trend (the killer
> > feature of those languages is they make it easy to do multiprogramming).
> > C++ cannot be retrofitted to supporting multiprogramming in a manner
> > that makes it accessible. D isn't there yet, but it will be, and
> > transitive const will be absolutely fundamental to making it work.
> Could you expand on how this would help? Is it as simple as being able
> to guarantee that certain data is not going to be altered, thusly
> removing any need for guard locks et al?

Pretty much.  The reason imperative languages tend to stink for this sort
of thing is because programs written in these languages typically share
data across processes (threads), which introduces the need for
synchronization.  I suspect the idea is that by shoehorning invariance
into the everyday practice of programming (via 'string', etc) that we
may be able to make applications more conducive to parallelization
without actually altering the basic approach for writing applications.  I'll
admit to being a bit skeptical that this will actually be sufficient as a long-
term solution, but it's worth a shot.  Personally, my money is still on
functional languages though.


Sean



More information about the Digitalmars-d mailing list