Is worth the effort to learn D? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 8 years ago.

开发者_运维技巧 Improve this 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 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?

---

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: Examples of what D’s 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.

---

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.

---

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.

---

I would just like to say I became a D enthusiast yesterday, when I learned how much better it is than C++, and I have been studying D for two days straight out of sheer love. Oh, it's not perfect, but compared to C++? No contest. Ditto for Java. C# was my language of choice as of 3 days ago, but today I think it has moved down a rank.

Not having used D for any serious work yet, I could be mistaken. But D has an answer to every major criticism commonly raised against C++, from compilation time, to poor type safety, to the headache of maintaining header files, to slow compilation. D isn't just an evolutionary improvement, it has innovations found in none of the world's popular languages:

• It is said to have one of the world's fastest compilers
• You can use try/catch/finally and RAII, but scope(exit) makes exception-safe code easier to read and write
• You can define closures that the compiler can inline (do any C++11 compilers do that? I'm not sure, I'm stuck on Visual C++ 2008 due to a need to support Windows CE)
• Garbage Collection is standard but optional, so you can write programs with low-latency guarantees by avoiding GC allocations (but how to manage memory instead? I suspect one could use alias this to make smart pointers a la C++?)
• Slices, a collection access mechanism that is far safer than C++ iterators and also far more convenient, no need to repeat yourself as in lower_bound(blobCollection.begin(), blobCollection.end(), blob)
• Generics are more flexible than in C++ and don't produce pages of error messages
• Compile-time metaprogramming that vastly outclasses C++ (and obviously C# too)
• Compile-time reflection which (I hope, but can't confirm) one could use to build a run-time reflection system if one wanted
• A well-designed, multi-paradigm approach to concurrency with interesting features for both shared-memory and message-passing architectures
• Built-in support for unit tests
• Array-wise expressions, e.g. a[] = (b[] + c[]) / 2 (MATLAB does this more tersely, but among general-purpose languages this kind of feature is rare)
• Superior floating-point features (e.g. nextUp()/nextDown()/ulp(), hex floats, control of hardware exceptions)

For a compiler or search engine library, D would obviously excel. And since D is so similar to C++, you wouldn't have to spend a lot of time learning it, so why not? Plus, it shouldn't be that hard to port small programs and libraries from C++. I have the impression GUI bindings have been improving too, so maybe D would work well for a text editor these days.

Admittedly, I'm not happy with everything. They are still catering to the C crowd, so you still have to fill your switch statements with breaks, the static keyword is confusingly overused, lambdas require braces and a "return" statement (as opposed to C#'s quicker x -> x+1 syntax), all functions and try/catches requires braces, pass-by-reference is implicit at the call site... but what D offers is too good to pass up.

But of course, while the D language is clearly terrific, and the standard library has apparently matured, the surrounding tools might not be so good: IDEs, support for smartphone platforms, etc. The only IDE I tried, Visual D (IDE plugin for Visual Studio) works pretty well, including debugging which seems to work as well as the Visual C++ debugger, and which can step into the standard library (fun!). However, Code Completion doesn't work very well yet.

Compared to C#, D is better in most areas but seems weak when it comes to dynamic linking and reflection. For example, your text editor could easily have a plug-in system under .NET, but I'm not so sure about D. .NET also offers runtime code generation while D does not. However, a research compiler exists to compile D to .NET code. Given that C++/CLI already compiles to .NET (C++/CLI), perhaps someday one will be able use D equally well for managed and native code (with a small performance hit in managed land, of course.)

Interoperability with C/C++ and .NET are pretty decent. D is supposed to interoperate with C++ functions and singly-inherited classes via extern (C++) and C++ name mangling (but which compiler's name mangling?), while you can easily create COM interfaces callable from .NET and other languages.

---

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.

---

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