Linux Agora D thread

[retard]

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.