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
