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
