Fully transitive const is not necessary

[Sean Kelly]

== Quote from Tim Burrell (tim at timburrell.net)'s article
...
> People aren't using C++ and Fortan because they're the best suited
> languages... and parallel people are always looking for something better
> because, like you said, in theory there should be a lot better choices
> available to us.  Functional languages promise neat and tidy
> parallelization with no side affects, etc, but in reality they're too
> slow and don't produce optimized code on the machines that parallel
> developers need to write code for.

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.

> What we want is a fast, system level language, that can be targeted by
> an optimizing compiler, but that is also quick and enjoyable to write
> code in.

I think we have that with D 1.0.

> If D did have some support for parallel programming I think it would be
> a major selling point, and I don't think it would need to complicate the
> language at all.  The whole problem here isn't that adding parallel
> support automatically makes a language ridiculously complex.

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.

By comparison, because data in most functional languages is immutable
and the program structure is inherently function-oriented, it is easy for
the environment to spread function invocations across multiple cores,
machines, whatever.  There is no shared/global data to worry about,
no state to synchronize, and no loops to unroll.  Combine this with a
message passing system for explicit parallelization and the program may
take advantage of not only automatic parallelization but explicit
parallelization as well.

(For the record, I've looked at languages Cilk and think they're a pretty neat
idea but still too bogged down in the 'how' aspect.  Haven't looked at OpenMP
yet though, and I really should do so.)

> The real issue is Walter's wacky and complex const system.  Somehow he
> thinks it's going to help with parallel development, so the issues are
> getting mixed, but in reality they're completely unrelated.

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?

Insofar as concurrency is concerned with D, I'd prefer to focus on tight
integration with "control" languages such as Erlang and to add a few
simple constructs to make more traditional imperative concurrency
easier.  Just give me a reason to use D instead of C/C++ for the areas
I care about:

* Embedded systems programming
* General systems programming
* Optimization points for programs in less performant languages (Python,
   Erlang, whatever)

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.

I could be totally off base here, but I think that D's advantage over C is its
support for sensible OOP, optional garbage collection, Unicode, and elegance /
understandability (lack of a pre-processor, delegates, etc), with its semantic
simplicity as an additional advantage over C++--it's far easier to create a
compiler for D than it is for C++.  This means that I feel D is more powerful
than C, easier to learn than C++, and in my experience is prone to fewer bugs
(by virtue of its syntax) than either language.  These are its core strengths, and
I worry about any feature that threatens to dilute them.  On the other hand, I
suppose it's difficult to sell a language to a C/C++ shop without a list of bullet
points.  C++ folks often insist on logical const features, etc.  Also, I could just
be worrying about nothing and all this stuff will turn out to be the bees knees
for D.  My initial impression is simply that we're trading away too great an
increase in complexity for the benefit offered by the 2.0 rendition of const.

All that said, I do think that CTFE is an absolutely fantastic option for certain
programs, and pure functions seem to be a great way for extending this
feature quite naturally.  If the goal is simply blistering end-to-end runtime
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.


Sean