Is worth the effort to learn D?

Question

Ok, let me reformulate the question. Imagine you have 3 projects: A text editor for programmers, a compiler and a search engine library for at least 3 types of files: html, .xls and pdf. You have 3 choices: C++, java and C# (or any other languages I previously mention), or you could explore the alternative of doing it with D. Then, you ask to more wises programmers: Could D give me a significant advantages in this task, in the areas of: modularity, bug fixing, team work, and machine efficiency?

Thanks

Answer 1

If you want the "power" of C++ without the cumbersome syntax, or the "power" of C with useful features such as proper strings and classes, I'd say it's worth it. If you like having a giant API to lean on (C#/Java), D probably wouldn't strike your fancy. Also make sure to use D 1.0, since library (wxD & other GUI libs) and compiler (GCD, LDC, anything not DMD) support is appalling for D 2.0, even though that version of the language is a clear improvement.

Answer 2

As I see it, D has the following advantages over more "traditional" statically typed languages:

1. Insanely powerful compile time metaprogramming facilities. For example, check out std.algorithm or std.range in the D2 standard library. A std.parallelism module is likely to be included soon, and if/when it is, it will be another good example. These facilities are powerful enough that the language sometimes feels almost duck-typed, but with the performance of a statically typed language. Also see the SO question about D metaprogramming: http://stackoverflow.com/questions/3555456/examples-of-what-ds-templates-can-be-used-for

2. The default D2 concurrency model is based on message passing. If you don't subvert the type system in obvious, greppable ways, there can be no implicit sharing of data between threads in D2. Of course, if you really want unchecked data sharing, you can break this with a cast. For example, the std.parallelism module that's currently in review does this to get pedal-to-the-metal multicore parallelism.

3. D tends to make simple things a lot simpler than C++ or Java. (I'm not as sure about C#.) By simple things, I mean things like basic file I/O or the strategy pattern don't require nearly as much boilerplate. In fact, I feel like one of D's primary design goals was to banish boilerplate code from the face of the Earth, as avoiding the need for it is heavily emphasized in the design of both the language and the standard library.

Relative to dynamic languages, D has:

1. The performance of a natively compiled language while giving up much less convenience than you would expect, mostly because of the awesome metaprogramming facilities and their use in the design of the standard library.

2. Static checking. Your program won't one day crash because you mistyped a variable name or tried to assign a string to an integer.

3. The ability to do low-level work. For example, except for a few small pieces of inline assembler, D's garbage collector is written entirely in D.

Answer 3

I myself am in the process of learning D, coming from a C / C++ background. D attracted to me because of it's elegance, it's well thought through design. That feels like heaven after intensive, deep and dark C++ corners.

For me, the one big disadvantage of D is the lack of libraries. Even the standard library I don't find very well done. The language is great, the libraries not (yet). You can use C libs though, which is a big thumbs up.

Although D seems to have many know-hows and many language aspects, it's not half of what C++ has. So I'd argue it's remarkably quicker to learn (definitely because 90% comes from C++ or related languages). So learning the language should be a matter of weeks / months.

Since there aren't great tools for GUI's yet, you might want to develop the editor in something else. The other two projects are perfectly suited for D.

Answer 4

I would give +1 for efficiency, 0 (no pro or con) for modularity, 0 for team work and a huge -1 for bug fixing.

The -1 comes from the fact that D is not really used enough to make the libraries feature complete and bug free. In this cases you will always loose time by fixing 3rd party code. Also a huge -1 for the non existance of a good D debugger.

Normally - as an Eiffel programmer - i would give D a +1 for having design by contract but this is not used constantly across the standard library and absolutely not used by 95% of the additional libraries. So you will not gain a lot of benefits from it.

Answer 5

I think D is definately best suited for the compiler, and less suited for the two other tasks.