const

[Russell Lewis]

Sean Kelly wrote:
> 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.

I'm mostly with you, but I am guessing that what will actually happen is 
a merging of the two.  Functional languages are great for expressing 
"what" questions, while imperative languages are great for expressing 
"how".  Neither does well in the other's area, IMHO.  Having a compound 
language which allowed imperative programming for the sequence-heavy 
code and functional programming for the easily parallelizable code makes 
a lot of sense to me.  I think that Walter is trying to push the 
language that way.  It remains to be seen whether it will work or not, 
but it's a valiant effort.