Fully transitive const is not necessary

[Craig Black]

"Sean Kelly" <sean at invisibleduck.org> wrote in message 
news:fstoa0$14ss$1 at digitalmars.com...
> == Quote from Janice Caron (caron800 at googlemail.com)'s article
>> On 01/04/2008, Janice Caron <caron800 at googlemail.com> wrote:
>> > However, in the future, you will be able to declare
>> >
>> >     class X
>> >     {
>> >         private static int _x;
>> >         invariant int x()
>> >         {
>> >
>> >             return _x++; /*ERROR*/
>> >        }
>> >    }
>> >
>> >  and suddenly - bingo - the offending line will not compile.
>> Well, not exactly. I made a fatal typo in that code, and consequently
>> completely screwed it up! So much for forward planning! Let's try
>> again. What I meant was:
>>        class X
>>        {
>>            private static int _x;
>>            pure int x()
>>            {
>>                return _x++; /*ERROR*/
>>           }
>>       }
>> and suddenly - bingo - the offending line will not compile.
>
> You know, I'm a huge fan of D, but now we have const, invariant,
> and pure, all ostensibly for making it possible for D to act more
> like a functional language when functional languages don't need
> all this mess to be parallelizable.  Perhaps it's because of the C++
> 0x post from yesterday, but the above is beginning to give me
> flashbacks to C++ in that I'm starting to feel like D is trying to
> be the universal solution to all problems, and thereby not an
> ideal solution for any problem at all.  One thing D has really had
> going for it thus far is conceptual and semantic simplicity, but
> I'm starting the feel that the const features are causing that
> simplicity to be lost.

Agreed, but this one's tough.  I've thought it through a million times, and 
the arguments for const (of some sort) are very compelling.

> Here's the thing: if I want to write heavily concurrent code I'm
> not going to use D because imperative languages, D included,
> are not structured in a way that inherently lend themselves to
> parallelization.  It's certainly possible to write code that could
> come close to matching a functional language--use 'pure' and
> 'invariant' everywhere, forego loops in favor of tail recursion
> (which is hopefully optimized by the compiler to avoid stack
> issues), etc.  But why mimic a functional programming structure
> in an imperative language when I can simply use a functional
> language in the first place?  I can only think of one reason:
> in a large company it is often more difficult to choose one's
> language than to choose one's programming style.  That's it.
> But if that's the case then I probably won't be able to use D
> anyway--I'll be using C++.

As you well know imperative/OOP languagaes are much more popular than 
functional languages.  Functional features in D will ease the transition 
into a more functional style.  From what I have read, pure functional 
languages suffer from severe limitations, just as pure OOP languages do, so 
a good mix is probably a better solution.  And while we are comparing 
functional languages to D, I'm not so sure that functional languages will be 
any better at being simple, since non-pure functional languages (Haskell in 
particular) seem to suffer from feature drift and language complexity just 
as much as D does.

The growing push toward concurrency is still sketchy.  Although it will 
probably help, I'm not so sure the functional paradigm alone will be "the 
solution" to the problem.  I find it hard to believe that any paradigm will 
magically make parallelism automatic.  I think it will always require some 
knowledge of the underlying hardware, and how things work at the low level 
to glean optimum performance.  Language features such as pure functions may 
help some with this, but I still think it's going to be increasingly hard to 
write software that scales well.  It is difficult to forsee the scalability 
issues that will arise the number of processors per die increases at an 
exponential rate, and as streaming processors like those found in the Cell, 
AMD's FireGL, and NVidia's Tesla become mainstream.

> I can truly appreciate the desire to have D scale effectively
> as programming becomes more concurrent.  At the same
> time, I am beginning to worry that the struggle to achieve
> this will end up destroying D's primary selling point (in my
> view)--its simplicity.  I know this is all new ground for an
> imperative language so there's nothing to do but wait and
> see... I just wanted to get this out so I could move on with
> my day :-)  Here's to hoping that D doesn't follow in the
> way of C++.

Time will tell.  A reassuring observation about Walter is that he has been 
known to change directions if something doesn't pan out (although it may 
take an act of God for this to happen with the const stuff).

-Craig