Walter had a great idea thinking that code documentation should be built into the language spec, but unfortunately it ended up having the reverse effect on the language.

The markup isn’t doxygen compatible so doxygen can’t be used, but the theory is that should be okay since the compiler has built in docgen. Unfortunately because it’s built into the compiler, and you don’t want your compiler to require various graphing and other strange libraries as dependencies, clearly no compiler based docgen is ever going to be as good as an add on tool.

And, because there is support built into the compiler, clearly no one’s going to put effort into adding D docgen support to existing tools.

Sounds like a small problem right? Well unfortunately no, it’s not. The whole reason Tango’s (and nearly all D projects, including D itself) documentation is so crappy is because it needs to be built with D’s docgen. The output of candydoc is really terrible compared to other tools: it doesn’t alphabetize functions, can’t insert equations via LaTeX, etc, etc. Basically it’s just a mess.

Stability and a good library get my vote. Must haves!

From my short lived programming career back in the 80’s and 90’s the things that always stood out for me and my colleagues with the programming languages we used were the availability of well documented libraries and stability. D is still not stable enough to be a serious contender for serious projects. Tango is very much doing the dance around and beyond Phobos but it also still has some way to go before it’s a well rehearsed rock solid stage ready production.

To Walter, given the age of D as a language it is a very impressive effort, but in my experience stability is still nagging at the edges.

To the Tango team, nice, saved me a heap of time on a recent small project, but documentation??

Stability and a good library. In my opinion both of these issues must be thrashed out to clear the way forward for D fof D (D Future OF D).

I actually spent most of my time with gdc as I’m a Linux guy and a Tango fan. Unfortunately gdc + windows + tango is still a bit of an issue as well, so when compiling on windows I had to use dmd.

If you have no need to use dmd your mileage will probably be quite a bit better, as almost all the major problems I encountered were with dmd… that being said it’s still quite easy to ICE gdc, especially if you start playing with mixins or doing any template metaprogramming. Other small issues with gdc: default function parameters being assigned via static struct / class opCalls can segfault the compiler. Little things like that, fortunately which are mostly easily worked around.

My intent with the post wasn’t to dissuade people from playing with D (which I still think is a great language), I just wanted to make sure people are aware of the real deal when it comes to developing with D.

Learning D has had a major impact on my programming style, and what I’ve now come to demand from a language, so regardless of the fact that I won’t be using D until some time in the future when the issues are sorted, I’m still grateful I took the time to learn it.

firstable thanks for your insights. I was just starting to look into D and quite liked what i saw so far. However, to judge a language’s potential you need to try it on a huge project as you obviously did, so you might have saved a lot of people a lot of time, at least for now. What i was wondering is: Did you only consider the the Digital Mars Compiler or did you also try the GNU one (gdc)?

And totally agreed on the simplicity.

The cool thing about D is it has a lot of the syntactual niceties of Python — array slices, built in strings and associative arrays, easy collection iteration, and is definitely way simpler than C++.

One of the things that really (and I mean REALLY) shines about D though, is the Tango standard lib. It’s by far and above the best language runtime I’ve ever come across both in terms of design and quality, and for striking a perfect balance between including a nice full feature set, without offering too much (ie no Java’s even-the-kitchen-sink-isn’t-as-bloated-as-this-API issue).

Don’t get me wrong, I’d never say that D is more efficient to develop in than Python or Ruby as a general statement — obviously there’s cases where Python is the right choice, and there’s cases where D might be, or C++, or Objective-C, and so on. I do, however, still hold to the statement that if D lived up to its potential, it really could fit the bill as a low-level system level language that can be as fast, or even faster, than some of the scripting languages (including Python) to develop in (for certain tasks).

And you’re right the reason is part syntax, part standard library, and part simplicity.

If it weren’t for the issues I discussed in the post D really would be a joy to develop in.

p.s. Thanks for the note on the Firefox 3 issue! I’ll look into that.

I’m submitting by hitting return with the cursor in the “Name” field, but many people wouldn’t know that trick…

Python’s major virtue, in my mind, is its simplicity. There’s relatively little you have to learn and know to read and write Python programs. Compare this to Perl or C++’s massive lists of “things you must know in order to be fluent”.

It’s not the syntax, that much is clear. In fact if anything the Python syntax is slower than C/C++/D. No increment / decrement operators, no ternary operator, and just more verbose all around.

So what is it then? It’s language features and standard library. Python is so handy because of its built in strings, associative arrays, and quick and easy to use runtime. Python is actually a different case because it’s a dynamic language so that helps in some cases and detracts in others, but D also makes some rounds in that area with its extensive traits system.

The thing that I argue puts D on par with languages like Python and Ruby is precisely those language features. D has associative arrays, garbage collection, etc, and a super handy standard lib / runtime. I’m just as much a Python user as a D developer, and I really do believe D can be faster to develop in — they just serve different purposes, so you have to pick your task accordingly of course.

But… if you don’t believe start playing with D and give it a go yourself! Despite my post-mortem I’m still glad I picked up D. It opened my eyes to the fact that there is a hole in the system-level language area, and although I don’t think D covers it yet, maybe some day it will, or maybe something else will? Maybe C++ will step up. Who knows.