A possible future purpose for D1

[Lutger]

bearophile wrote:

> I think this comment contains a grain of truth: languages that start
> simple can gain an user base, and then they can slowly grow more complex:
> 
> 
http://www.reddit.com/r/programming/comments/b74jv/scala_books_in_general_are_just_not_selling_well/

I think you need to distinguish between accidental complexity and inherent 
complexity. For example, C++ has a lot of accidental complexity that is 
actually not necessary, this is nothing more than a hindrance. But take 
javascript's lack of a module system for example, this makes the language 
itself simpler but the scaling up javascript programs much harder. In this 
regard python's module system is way more complex, which makes programming 
way more simple.

Tacking on features while remaining backwards compatible is what grows a lot 
of accidental complexity in languages. D2 is not free from that of course as 
it's designers are leaving the 'no issue left behind' stage of development 
behind in order to actually finish something.

> The const/nothrow/pure system of D2 is useful, but in practice it's
> restrictive and a bit fussy too: there are legal and useful D1 programs
> that just can't be compiled by D2. I have shown a small example problem
> here (I think this problem can be fixed):
> http://d.puremagic.com/issues/show_bug.cgi?id=3833

But these examples are genuine bugs right? They are not inherent flaws in 
the type system (I hope).
 
> So the D1 language can be useful as ladder to climb to the complexity
> heights of D2 language. People can learn D1, that's simpler and less
> fussy. Once they know D1, if they like it and they need it they can learn
> D2 too. Sometimes you want to use D2 just because you want to create
> larger programs (while D1 can be fitter for smaller ones).
> 
> If this usage of D1 is more than an illusion of mine, then the future
> evolution of D1 language can be shaped to help in such
> didactic/introduction purposes. To do this the D1 can be changed a little,
> removing some of its features that are absent in D2 (but not all of them,
> some of them were removed in D2 because of other improvements that are
> missing in D1), and adding few useful features that are very simple to use
> and understand, (like struct constructors, that I think (despite
> increasing the compiler complexity a little) can decrease a little the
> complexity of the language because they remove a special case, you don't
> need to remember that structs don't have those constructors).
> 
> Bye,
> bearophile

D is a complex language allright, but it's made to implement complex 
programs. It's a competitor to C++/C#/Java and not bash for example. After 
D2 spec is frozen and the most important bugs are fixed, it will be more 
clear whether it is *too* complex or not. I think (hope) most of the D2 
features you mention as complex can just not be used if they are not suited  
for the kind of program you are writing.

What about D1? I think a better stepping stone to D2 is just the subset of 
D2 that is simple or more familiar to most programmers. At least you don't 
get any questions about what 'public static void main()' means and what a 
class is when introducing hello world :)

D1 has but one major advantage over D2: it is much more mature. I think D1 
has a future as long as that is the case, or as long as there is a large 
enough body of code depending on it. Assuming Walter Bright keeps supporting 
it of course (as he has).