▲ 56 points
back
47 comments
D1 + Tango == yes! Excellent combo, but serious lack in the toolchain department. DMD and OPTLINK especially is a failboat currently. LDC is based on LLVM and is "the future", but lacks windows support (exceptions! and this is inherently LLVM's problem now). DDBG is a good debugger, but is unmaintained. GDC is D on GCC, but is unmaintained.
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.
There are two big problems with D.
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.
A top quality, supported, opensource compiler would help. The LLVM front-end looks promising but I half expect it to be abandoned. It's kind of odd, it definitely seems like there is a desire for a compiled machine code producing language to compete with C and C++.
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.
Yes. This is actually is one of the main points of contention... that the dmd frontend is 'source available.' The community is doing some things to address this, but that's all I'll say.
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 dmd front end is GPL'd.
Thanks for the correction, Walter. As Wikipedia says:
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.
Having read that blog post, I can completely and emphatically rule out using D at all for anything, unless and until I hear it's no longer a pitiable train-wreck (and I won't hold my breath).
Honestly, 99% of this doesn't matter if you're not concerned about the politics of the development of the language itself. If you code with D1, and pick a library... none of this matters.
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.
It's not akin to C++/C++0x at all. C++03 is standardized and the current mainstream compilers do a good job of implementing that standard; the tools are rock-solid. C++0x is coming along nicely, with support from the big industry players. Concepts were dropped, but the rest of the features are still a massive improvement over C++03 and I can't wait to use them.
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.
There is an awful lot of problems with C++ though.
- 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.
> - compilation is slow
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.
You can do "header" files with D, too. They're called .di files and the compiler will even generate them automatically, or they can be built by hand.
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.
D is well-designed and has many wonderful features, but its documentation is so bad as to make it unusable for serious work. This article is the best reference work on D2 that I have yet seen, which should not be the case.
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.
The Phobos vs Tango thing put me off too.
> 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.
It's not that books are bad, it's that there is only one book. If it's not in The Book, you essentially can't find it anywhere, unless your mailing list spelunking skills are particularly good.
I never read The Book, instead learning the language entirely by the spec. It's honestly not that hard.
I learned Python by reading the official tutorial and hacking away until it made sense. I did the same for O'Caml, and later for Haskell (although that one took longer). Isn't that normal?
I tend to learn languages by writing compilers for them. I'm sure that isn't normal <g>.
The question is, is D better enough than C++ to make us switch?
When taking over you must not just be better, you must be a hell better to justify the cost of the switch.
As always, it depends on what you want. I personally find D to be way better than C++, or I wouldn't be writing a kernel in it.
Of course, individual tastes may vary.
D might not be better from the glance over it, but it's little things in it that REALLY add up. I strongly recommend anyone who ever wrote C++ code to give it a go for at least a couple of months and see for themselves. That is the best way to measure - I can only give you my sincere recommendation to try it out.
It looks great, I agree. I like the range approach for the standard library. I also like the end of the include nightmare.
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.
"I like the range approach for the standard library"
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.
I'm curious, why don't you want to do the switch to D2? Is it because it's not mature enough?
There are several reasons. I'll try to list them, but it might not be complete:
- 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.
I wouldn't be that confident. D1 is a dead-end. If you ask a C++ user, he wouldn't drop C++ and a damn lots of libraries, IDE's, debuggers and industry support for it. I recently talked to my C++ friend writing scientific multithreaded stuff, and he was only convinced by D2.
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.
>> ...the people that don't write programs in D at all (Andrei)
>> 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.
Maybe you could have a read at Modern C++ Design by Andrei.
A mind expanding book with incredible insight in meta-programming.
All this "template maelstrom" makes sense and is unavoidable to have powerful and expressive statically-typed languages.
First of all, D2 is not mature at all. It's like asking "Is C++0x mature enough?"
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.
I don't think many-cores compatibility is a little gain.
Same applies for other emerging or obscure technologies as well (I'm looking at you Lisp).
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.
Unsupported is a bit strong.
"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.
D started 10 years ago. It's not a flash in the pan.
I find it a lot better.
Okay, I'm totally going to bite on the "find something you don't like in 30 seconds" and it's the hello world example.
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.
Uncaught exceptions are caught by the D runtime code, and the appropriate message is printed.
You can declare functions as "nothrow", in which case the compiler will complain about any uncaught exceptions in the function body.
I've tried several times to write a project in it, and every time I found some horrible bug, something missing, broken (OSX support is poor) or libraries turned out to be useless/outdated (dsource is a graveyard), or that I've chosen the wrong set (D1 vs D2, Phobos vs Tango).
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.
Kenta Cho, sole member of ABA Games, uses D to write his (excellent, open source, freeware) shmups. Go for the code, stay for the games:
It doesn't seem like he uses D anymore. His last two games were written with C# and XNA.
`[...] the classic "hello, world" for other languages such as Java (code omitted due to space limitations [...]'