The Case for D
ddj.com
ddj.com
D2 on the other hand doesn't feel like D anymore at all. Sure, there are a couple of nice things in it like ranges, but on the general perspective I could make this comparison: D1 is like C with C++ made right. D2 is D++, what C++ is to C - bloat and inconsistency.
There is also a huuuge problem with D2 and leadership/drama, which split the community. There is also problem with Phobos vs Tango - where Tango is clearly and measurably better, but that thread of issues leads to leadership drama.
Let me be clear on this (I use D every day for my projects - I am into graphics/gamedev with it). Do yourself a favor and learn D1/Tango - toolchain is bearable and there is a book about it from Apress. Community is responsive (#d, #d.tango on freenode if you demand prompt resolutions). Use Tango from SVN, use LDC or DMD if you are on Windows.
Also, check out http://www.team0xf.com:1024 - especially dog (OpenGL platform agnostic binding) and hybrid (gui on top of it). Check out http://www.dsource.org .
There are some movements within the community that will resolve by themselves soon enough - it's too good to fall apart. In the mean time you should really do yourself a favor and give it a go.
1) Everyone treats D2 as being the current stable version of the language, when it isn't. 2) Tango vs Phobos when it comes to D1.
But trust me, the D community is aware of those things. [1] There are a lot of tensions over the developments of D2, how they're going, etc. If and when D2 ever actually comes out, it should address lots of the issues.
But you may see something sooner than that.
Your comment is akin to "After seeing the debacle with the C++0x committee, I will rule out C++ for anything until I hear it's no longer a train-wreck." Which might be legit. Just saying.
On the other hand, reading that blog post about D has confirmed my worst suspicions about the instability of the language and the immaturity of the tool set.
- The tool are certaintly not rock solid. Parsing requires arbitrary look-ahead and semantic pass, order of headers inclusion matters, #if and dirty tricks are everywhere
- compilation is slow
- non standard extensions makes painful portable C++ across compilers and platform, because you need them and they can have incompatible syntax
- C++ const is useless when it comes to optimization or concurrency.
- any real world project involving C++ is going to be challenging if you're not working with top C++ library implementers or emasculating rules (like "no exceptions" or "nothing goes in the constructor" at Google)
Anyway, even if C++1x was already here and completely supported (which C++03 is not), D would still have an edge.
Despite its current problems D greatly enhance productivity over C++. Refactoring is _way_ faster when you have import and no headers to maintain. Properties enhance expressivity a lot. You have access to the machine, value semantics, and reference returns, so there is nothing conceptually wrong with it.
Also, in D there is much less skill diffference between library writers and typical programmers as compared to C++.
Finally if you really want C++1x features, I sincerely advises to try D because there is a lot of overlapping.
What I've learned is that people don't really care about full builds when doing large projects. The separation into header and source files means that when you change a source file, only this one has to be recompiled. You only do massive rebuilds when modifying headers.
In case of D, when you modify a module, the change can possibly propagate indefinitely. Even when you just change the body of a function and think the modification should be isolated, consider that the build tool must assume this function may potentially be used at compile-time to generate code for other modules. The changes propagate as far as they would with .h files (unless the build tool can do semantic analysis or make unsafe assumptions).
To this fact, add how DMD only outputs template instances into one object file when compiling multiple modules at the same time. If you're lucky, at the next incremental build it will output them into the same modules. If you're not, you end up with unresolved references. This template emission method is an optimization - the alternative is a lot of bloat that object files generated by C++ compilers suffer from. I agree with Walter's position that what DMD does should be the default. And it is possible to make a good build tool that deals with this issue. I've tried doing that for DMD-Win, but its case, such a build tool is currently infeasible due to toolchain issues.
The compile speed advantage D has over C/C++ is that in the latter the header files must be reparsed for every source file. In D, the header files only need to be reparsed once, and then it is looked at symbolically for the rest of the source modules.
D is also faster at compiling because the lexical grammar is designed to require little processing.
1) It's very sensitive to the contents of .d files. For instance, It leaves the bodies of inline-able functions in, thus if you modify such a function in the .d file, it will again mean a change spill to the .di and modules importing it (directly and indirectly). Similarly if you just reorder the functions in a module or change a private constant. This could partially be mitigated by a sufficiently smart build tool that tracks symbol importing, aliasing and usage in order to infer the modules that need to be recompiled. Sadly, this is quite complex and no current tool does it at the moment.
2) It assumes none of the functions will be used at compile-time (by stripping away function bodies depending on whether they may be inlined), which forces you to stuff them all into compile-time-only modules.
I kind of remember this argument with Ada over the years, particularly when the GNAT front-end to GCC was mainlined. Having tools available is a big noticeable percentage of the problem; maybe 30-45%. Tooling is becoming more than just a compiler though, an eclipse IDE for D would be nice too and it's probably required for serious consideration by the masses. Supported and live are important for this stuff.
Another aspect of adoption seems to be adoption. It's a snowballing kind of thing. In the GNAT/Ada days there were a lot more advocates of its use than there were users. If you really want D to start getting more attention, then start doing some successful D software, particularly packages that get attention seem to be good (see Mono and Tomboy) Ada has a good complaint compiler that is supported and still doesn't have many users. Some free/open software that shows some of the benefits and advantages of D would help.
LDC is a really great project. It's not being abandoned anytime soon, trust me. Those guys are working hard, and they answer bug reports really, really fast. Though I'm admittedly slightly biased, since they use my kernel as a test case.
There are several IDEs that support D, though I can't think of them off of the top of my head, since I use vim. Posiedon?
There have been several intersting D projects, but you're right, more would certainly help. The blog post I linked to's author wrote a little language called MiniD that's pretty interesting, I (and several others) are writing a kernel, etc... but dsource.org can look like a graveyard sometimes...
The Digital Mars D compiler is the official D compiler by Walter Bright. The compiler front-end is licensed under both the Artistic License and the GNU GPL; the source code for the front-end is distributed along with the compiler binaries. The compiler back-end source code is available but not under an open source license.
Also, this guy has been working on the book for over two years now. Even when it's done, it's going to be just like Grails is now: you can read the online docs, but you don't really get it until you read a certain book.
Isn't that expected and normal for anything that involves thinking about things a different way? D has language features that most programmers aren't familiar with, so to use the effectively involves a shift of thinking. Same with Grails.
When taking over you must not just be better, you must be a hell better to justify the cost of the switch.
Of course, individual tastes may vary.
Is the output binary as good as a C++ one? That would be my first purely technical concern.
Other concerns would be related to the building tool chain and the quality of IDEs.
But the real concern is business oriented.
For pet projects I'd be inclined to give a green light. It's always nice to play with new technologies as it opens your mind and give you new ideas.
For full fledged commercial products you expect to live several years, that's going to be a solid red light. I wouldn't take the risk of using an unsupported language.
This is D2 - I don't use D2 and wouldn't use it. I was talking about D1/Tango combination. I don't think I'll make a switch to D2.
"Is the output binary as good as a C++ one? That would be my first purely technical concern."
That depends on the compiler/linker, of course. In short - dmd good enough, ldc great (llvm as the backend after all).
"Other concerns would be related to the building tool chain and the quality of IDEs."
You can download DMD/Tango package from their Trac page and you're ready to go, however I would strongly advise you to use SVN tango version - which implies you need MSYS(on Windows) to build it. Ask for help on forum there (dsource.org/projects/tango) or on irc d.tango (freenode). As for IDE, you can use Descent for Eclipse, as some people do. I use Emacs for everything though, same applies for D - there is a module for it.
"But the real concern is business oriented."
There is no concern here, since basics of risk management should tell you not to use it. Same applies for other emerging or obscure technologies as well (I'm looking at you Lisp). Short answer, don't use it for business critical things yet, though some have done that with success.
Secondly, lots of people won't ever switch to D2, even when it's done, because they feel that it adds a lot of feature bloat for very little gain.
- D2 looks and feels foreign to me as a somewhat D1 experienced user
- Templates maelstrom and strong emphasis on them
- D1 grew organically, D2 looks like an academic exercise where stuff is put in just for the sake of it by the people that don't write programs in D at all (Andrei)
- D2 book and Andrei are a filibuster for D2
- Walter Bright listens to Andrei (ok, a smart guy) but he doesn't write D programs, I doubt even Walter writes them (seriously). If you look at his code, it is more of a C in D than D code.
- I have little to no trust in DMD/OPTLINK, LDC/LLVM is what I'm after and that front is D1 only, and looks like it will be
- Lots of people smarter than I am are on D1 also (Tango, namely) - and I don't want to go against the trend since it would isolate me from little support I can get
these are just of top of my head, there are more. General summation could lead to "It just doesn't feel right" - at least for me as a heavy D1 user.
Templates are the killer feature of D. There is nothing wrong in the emphasis on them.
Yes I agree that there are problems in D2. But there are much more problems in D1.
If I were you, I wouldn't do such an anti-advertisement campaign here. Instead you could have pointed at what you think are the problems with D2. That would be more constructive.
>> Walter Bright listens to Andrei (ok, a smart guy) but he doesn't write D programs
You stated twice that he doesn't write D programs. Well since you are mentioning Tango, it's unfair because he writes code for a _standard_library_. And he is writing a good code.
All this "template maelstrom" makes sense and is unavoidable to have powerful and expressive statically-typed languages.
This is so generic a remark as to be worthless. You do know Lisp signifies a family of languages, right? Of which most or neither emerging nor obscure.
"For pet projects I'd be inclined to give a green light. It's always nice to play with new technologies as it opens your mind and give you new ideas."
I had no success in learning another languages now that I know D... be cautious :p
"For full fledged commercial products you expect to live several years, that's going to be a solid red light. I wouldn't take the risk of using an unsupported language."
I would have said that a year ago, but it becomes less true over time.
You are likely to encounter less bugs in D1 than one year ago. DMD is released frequently, usually fixing a lots of bugs you didn't even worried about.
All problems other than compiler bugs aren't really blocking. There is also bugs in C++ compilers.
void main() { writeln("about to do something important"); doSomethingImportant(); }
is this really not going to run doSomethingImportant() if the writeln fails? I find that to be a poor default for a systems language.
This may just be a personal preference, but I strongly want a systems language to do one of 2 things:
1) Require me to explicitly state when I care about an operation failing 2) At compile time ensure that my code explicitly states when it's not going to handle an exception. (Java with this, like so many things, gets it 90% right and then falls on its face)
Silently passing exceptions out to the system is a bad default for something that is supposed to be able to be used to build the system!
Note that this preference does not apply for a large swath of applications programming. For a webapp, it may be reasonable to log any uncaught error conditions to a log file, since we can just signal the client to try again.
You can declare functions as "nothrow", in which case the compiler will complain about any uncaught exceptions in the function body.
I'd really like to use D, it's the non-sucky C++ I've been waiting for, but it's just far from being usable and reliable yet.