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

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Mon Nov 8 11:55:12 PST 2010


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.

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. 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.

TDPL's publication brought about a change of pace in D2 from design to
implementation. Currently there is strong focus on the 64-bit port,
which is a gating issue. Work on D2's standard library has increased in
intensity and scope. I have good reasons to believe that such
developments will continue growing at a robust pace for the foreseeable
future. Probably participation to the standard library will increase
faster than participation to the compiler implementation, mostly for the
obvious reason that library work is easier to parallelize.

Going forward, I see any adoption of D (be it D1 or D2) beneficial. I am
confident that most people who will get first acquainted with D1 will be
ultimately compelled to use D2. The community would be helped if
factionalism would subside, but for the political reasons mentioned
above I don't see that happening soon. Anyhow, I don't think that that
would impede the success of D in the long term. The problems that D is
currently facing are all solvable with quality implementation. To me it
seems that the talented and growing contributor base that can rise to
the challenge.


Andrei



More information about the Digitalmars-d mailing list