retard wrote:
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?
The Linux 64 bit dmd is well on its way to completion. The library compiles, and
simple programs work. I'm working my way through the test suite (which is fairly
extensive).
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.
Would you believe them if I did?
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?)
That depends on if your project needs an xml framework or not. Worst case, which
is far from bad, you can always connect to any C library. Googling "c xml
library" turned up several on the front page.
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.
It's foolish to assume any compiler is reliable if you're going to be writing
critical software. Assuming perfection in any part of such a system is a
thorough misunderstanding of how to create reliable systems.
I believe it is also an error to require a tool be perfect before you can pick
it up. All that is required is that its benefit/cost is higher than that of
other tools. D has quite a few advantages that are available with it right now.
