Fully transitive const is not necessary

[Tim Burrell]

Sean Kelly wrote:
> I'm currently of the opinion that the ideal solution is to use a functional
> language like Erlang for the concurrency aspect and then to use a language
> like C for the performance-critical or systems bits.  For example, from a
> statistic I saw somewhere, the Ericsson switch code has approximately as
> many lines of C code as it does Erlang code (a few hundred K of each), with
> the structure I've described.

Agreed.  But what we really need is a language that's also good at 
shared memory parallelism (Erlang's really geared toward shared-nothing 
setups -- good back in the day, but today a modern shared memory 
compiler can perform suitable optimizations).  We really only have 
Fortran and C++ that currently fit the bill -- but perhaps D could be 
that language?

> I'd modify that by saying that adding concurrency support makes an
> imperative language ridiculously complex.  The problem (as someone in
> this NG put it) is that while functional languages describe /what/ should
> happen, imperative languages describe /how/ it should happen.  In
> instances where the programmer knows more about how to optimize
> the process than the compiler may, using an imperative language is
> clearly the correct solution... and systems languages are clearly necessary
> when systems work is to be done (ie. operations involving direct memory
> access, etc).  But it's fairly well accepted these days that concurrent
> programming is just too difficult for most programmers if they have to
> worry about the 'how' part.  At best, most such programs achieve only
> a large-scale granularity as tasks with logically distinct divisions are
> manually separated out into jobs for thread pools and the like.

I agree with you here on all parts except the one that an imperative 
language needs to become complex by adding concurrency support.  It's 
all about how it's done.  You're right, we need to be describing what, 
not how.

I think I'd call D a multi-paradigm language in the same way I'd call 
C++ multi-paradigm.  It's all how you use it.  If we had some proper 
multiprogramming capabilities it could very well be a description of 
what, and not how.  That'd be the goal for sure.

> I actually think that the const system could help somewhat.  Pure functions,
> for example, offer guarantees that are fairly similar to what a functional
> programming language offers.  However, for such an approach to compete
> with a true functional language the D programmer would have to use pure
> functions almost exclusively rather than sparely, which is what I expect.  And
> in the case that the programmer uses pure functions exclusively, what he's
> doing is mimicking functional programming in a language that isn't naturally
> suited to it.  So in short, I think the pure/const/whatever stuff may actually
> get D part of the way there, but I also think that it's a bit like using a boat
> in an automobile race.  Sure you can bolt some wheels to it and drop in an
> engine, but why do that when you could use a car instead?

Yeah I hear what you're saying here.  It's a tough thing, because you 
definitely don't want the bolted on after-thought feeling.  On the other 
hand it works pretty good for C++, and since D is directly competing 
against other system level languages (like C++) it's really not going to 
be a competitor in the upcoming parallel battle if something's not 
figured out.

> In these arenas, the only mainstream competitors for D that I'm aware of
> are C and C++ (and maybe Java, if you count it as an embedded language).
> That's it.  And this field isn't liklely to expand any time soon.  Further, I
> think we've gotten to the point where there's no longer any compelling
> reason to write monolithic programs entirely in a single language, so why
> even try to be the go-to language for every problem?  Particularly if doing
> so risks diluting the strength of one's offering in another area.

You make good points.  And I agree with everything you say.  I just keep 
wanting to hold onto the idea that it should be possible to provide a 
reasonably simple way to give parallel programmers a hand when using D. 
  Hell I'd even be happy with an implementation of the upcoming OpenMP 
3.0 draft.  It's not original, but it'd sure as hell help!

> performance then there may well be something too all this mess.  I only wish
> that it could be done in a way that doesn't bring so much baggage along
> with it.  We went from one way to declare functions in D 1.0 to at least four:
> unlabeled, const, invariant, and pure, all of which cover the same basic
> conceptual domain.

I feel the same way.