Fri, 22 Oct 2010 00:33:15 -0700, Jonathan M Davis wrote: > On Friday 22 October 2010 00:09:31 Walter Bright wrote: >> Jonathan M Davis wrote: >> > In any case, that poster seems knowledgeable enough that I don't see >> > much point in arguing with him. His opinion obviously differs from >> > that of most of us on this list, but it's generally based quite >> > soundly on facts, so only time will prove him wrong. >> >> Sure, but it all depends on how one interprets those facts. >> >> For example, C++ is hardly the same language it was in 1988 or so, when >> it became widely used. I don't think any pre-2000 C++ compiler would be >> remotely considered usable today. Languages that are not dead go >> through substantial revisions and upgrades. It is not a defect in D >> that it does so, too. >> >> As anyone can see in the changelog, we've stopped adding features to D2 >> and are working on toolchain issues. There's been a lot of progress >> there. > > Oh, I agree that he's wrong, and I agree that D2 is making serious > progress, but he's got enough of his facts right that I don't think that > he can be convinced by correcting what he's saying. I see value in > correcting people if they misunderstand the situation, but trying to > convince someone whose opinion differs when they have their facts more > or less straight is likely to just result in heated arguments. > > The fact that D2 is not 100% stable is, of course, not something that we > want, but I do agree that it's completely understandable why D is the > way it is at the moment and that it's not unreasonable for it to be that > way. D is improving and it will eventually reach the same level of > stability that modern C++ compilers enjoy. However, it's also pretty > much a given that many people won't want to use D until it has a level > of stability comparable with the compilers that they use for more mature > languages. But there's nothing that we can do about that except continue > to improve D until it reachs that point. And the more stable it becomes, > the easier it will become to get people to try it and stick with it.
What annoys me the most in pro D articles is the author usually tries to prove (in a naive way) that despite all the deficiencies the language and tool chain is better even *now* than all of the competition or that the *potential* is so high that the only logical conclusion is to move to D *now*. Clearly this isn't the case. These kind of articles give people the wrong impression. I'm just trying to bring up the *pragmatic* point of view. For instance, I'm starting the implementation of a 64-bit systems/ application programming project *now*. The implementation phase will last N months (assume optimistic waterfall process model here). How many weeks/ months must the N at least be to make D a feasible option? A typical lead developer / project manager has to make decisions based on some assumptions. E.g. Platform Implementation Developer Performance Platform Time Market Index Risk factor -------------------------------------------------------------- C/x64 Linux 12 months good 100 medium C++/x64 Linux 10 months ok 110 high Java/x64 JVM 8 months excellent 80 low C#/Windows 64 7 months very good 85 low Python/Linux 4-5 months very good 30 low D 12+ months? very bad 80-115 ? very high The metrics are imaginary. The point was to show that language goodness isn't a single scalar value. Why I think the D platform's risk is so high is because the author constantly refuses to give ANY estimates on feature schedules. There's no up-to-date roadmap anywhere. The bugzilla voting system doesn't work. Lots of production ready core functionality is missing (for example how long has d2 distribution had a commercial quality xml framework?) For example gcc has had 64-bit C/C++ support quite long. But it took several years to stabilize. The implementation of a 64-bit X-ray machine firmware in D cannot begin one week after 64-bit DMD is announced.