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

[Jacob Carlborg]

On 2010-11-08 20:55, Andrei Alexandrescu wrote:
> On 11/7/10 6:33 AM, bioinfornatics wrote:
>> So D community will be split in 2. And D1 continue to evolve without
>> D2 community, D1 frontend is open source and he coulb be used for
>> improve and fix D1
>
> The current situation and the dynamics are quite interesting, and I am
> looking forward to witnessing how things will unfold.
>
> There is a community for which D1's offering is just fine. They've used
> D1 long enough to use it idiomatically and to derive better enjoyment
> than from the likes of Java or C++. The gain in power, albeit marginal,
> is present. That base has been understandably annoyed by D2 being
> backwards incompatible with D1, and has a dim view of the advantages
> brought about by D2's additions (mainly concurrency and its
> paraphernalia - immutability and no default sharing). The fact that the
> implementation of the newest features is incomplete fuels arguments
> against D2. The immaturity of alternative back-ends (gdc, llvm for D2
> are both quite young) contributes to the perception that D2 does not
> offer a net advantage when compared with D1.
>
> It is my perception (though I might be wrong) that the dichotomy has
> become to some extent political. D2 offers little political incentive to
> a Tango port. Tango is currently the de facto standard library for D1 as
> the vast majority of D1 users use D1 and Tango in conjunction, which
> precludes use of the underpowered Phobos1 (D1's de jure standard
> library). Due to Sean's work on making druntime independently available,
> porting to D2 would lower Tango's status from the standard library to
> one of the libraries that may be used in conjunction with Phobos2.

Here's the problem with that: since Sean basically forked the Tango 
runtime, removed any non DMD specific code and any code for a platform 
that DMD doesn't support. And stopped contributing to Tango while others 
improved the Tango runtime we're back at square one with two 
incompatiable runtimes and the Tango runtime still seems to be better. 
For this to work the Tango team and the druntime 
contributors/maintainers have collaborate and work together on a runtime.

> So in the current equilibrium D1 and Tango form a bond: D1 is platform
> offering Tango exclusivity as the standard library and Tango is the
> library that makes D1 attractive. The risk assumed by that bond
> (assuming the assumption above is correct) is isolation in a position
> condemned to inevitable obsolescence.
>
> As far as language proper is concerned, D1 has the option of becoming an
> incompatible fork by choosing to evolve its own features independently
> of dmd. That process could be greatly helped if a strong language
> designer would decide to work on D1. I see that as a possible but
> unlikely scenario (unlikely because a language designer would have to be
> primarily politically motivated to make such a decision).
>
>  From the D2 side, it all boils down to the question: are D2's additions
> worthwhile or not? D2 places bets on concurrency, correctness, and
> opt-out safety. Those bets looked much riskier two years ago than they
> look now, but still carry a risk. Also, as I mentioned above, currently
> the implementation of many new features is superficial. This is caused
> by the current development model of the reference compiler - features
> are implemented without a formal description.

Exactly, they need a formal description. This is also a problem with no 
proper language specification. If you encounter a problem/bug you never 
no what to except: is it a design bug? An implementation bug? And then 
it's hard to figure that out because you never no what can to trust, the 
language specification? The reference compiler? TDPL?

> There is disproportionate reliance on the compiler test suite to effectively define the language
> by exercising all of its features and feature combinations. The test
> suite is undeniably useful, which makes it even more difficult to
> explain its problems. Some more complicated features are first
> implemented to simply make a narrow test pass, and then spend a long
> time in an "almost-well-defined" state in which bug reports are fixed
> and added to the test suite. I believe that the informal language
> development is curre
> ntly the single most important liability of D. (That is, somewhat
> ironically, a matter in which D2 is at an advantage to D1.)
>
> The insufficient implementation of new features propagates the
> perception that D2 is unstable, although the more conventional, D1-like
> subset of D2 is as solid in both languages. But then the perception is
> justified, because one would want to use D2 primarily for its new,
> unique offerings. A longer term perception problem is that some might
> think the _design_ of such features has unsolvable issues, which hurts
> the image of the language. I know of no major design flaws, but that is
> only an academic argument in wake of perennial implementation
> insufficiencies.

There are still things in D1 that are not solid, just look at the bugs 
and newsgroups posts by bearophile. The module/import system, for example.


-- 
/Jacob Carlborg