why a part of D community do not want go to D2 ?

[oldtimer]

Mon, 08 Nov 2010 13:06:23 -0800, Andrei Alexandrescu wrote:

> On 11/8/10 12:48 PM, bearophile wrote:
>> Andrei:
>>
>>> A longer term perception problem is that some might think the _design_
>>> of such features has unsolvable issues,
>>
>> That's my fear (so it's problem, even if it's just a perceived
>> imaginary problem). But I am not in a rush, so I am not going away.
>>
>>
>>> I know of no major design flaws,
>>
>> Uhm... For example the whole implementation of nonnullables in D2 is
>> already becoming a big design flaw.
> 
> I think we have different definitions of what a design flaw is. C++
> export was a design flaw. PHP also has several design flaws. The fact
> that you can't implement non-nullable references in e.g. C++ or Java is
> not a design flaw in those respective languages.
> 
> Generally I think the case of non-null references is overstated. It
> doesn't deserve that much agitation. It's being mentioned as a life or
> death matter in spite of the simple evidence that many mainstream
> languages are doing well without it, and without a landslide popular
> vote for adding it. (And it's not a flaw in their design that they don't
> make non-null references implementable.)
> 

For some members of the community D has been a learning process; D has introduced the members to new features in language design. It has been an informal trial and error process. Even Walter has learned a lot, which is nice. This has caused at least two problems. The requirements have changed and developers expect now more advanced functionality. The amount of suggested design ideas has grown, but the development speed hasn't scaled as well. The development process doesn't scale up since almost no documentation gets written. The expectations may be unrealistically high. Sometimes the expectations are realistic, but the combination of legacy design choices in D1 and D2, TDPL pressure, D2 stabilization pressure, and D2 schedule has brought a suboptimal implementation.

The second problem is, the developers now expect more knowledge from the language designer. It gets really frustating if we need to start teaching him to get better features. This is universal - if your kids go to a really bad public school, you might want to start teaching them at home or consider some private school (= other language). If your lawmakers don't understand the laws they pass, you might consider moving to another country (= other language/platform). I can say I'm not really convinced. I'm probably not the only one.

It's bad for the publicity that digitalmars can't articulate any kind of official *written* roadmap for new features. You don't want to dedicate much (financial) effort on projects using the cowboy coding paradigm. The project has a trac page. Writing down: "1. 64-bit dmd (N months) 2. concurrency fixes (M months) etc." shouldn't take too long. If my guess is right, you can even copy'n'paste it straight away. But you also need to update it! This is basic project management these days.

One reason why Python/Ruby are so popular is their terse syntax. The library based solutions in D2 aren't that cute. Some developers value the beauty of code. If the solutions are too ugly, people will switch to other languages. Compare Pascal with C, the languages are quite similar modulo syntactic changes. The other one won.

For commercial users of D the feature set matters a lot. If D2 can't deliver the power of D1 & Tango, there's nothing you can do. A sane corporation would not donate code to Phobos just because its quality is worse and it's an empathetic thing to do. Corporations don't work this way. Those who are fixing Phobos are individual zealots swimming against the stream. They have a very long term technical agenda (D2 will beat comtemporary technologies in 10+ years), a religious agenda, nothing better to do, or some kind of mental illness. Corporations aren't interested in very long term technical issues, they care about short term solutions (1 to 36 months).

Some of us hoped D2 would solve the ugly corner cases of the language and unify a lot of features. Unfortunately not any kind of macro system was implemented, templates got even uglier, the alias this hack, snake oil template!X syntax shortcut and all kinds of unnecessary features were added. Of course also good features were added, but overall this just isn't good enough.