27

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?

nbro
  • 15,395
  • 32
  • 113
  • 196
Nisanio
  • 4,056
  • 5
  • 34
  • 46
  • 7
    Without knowing what you want to do, or the languages you already know, it's impossible to answer. Moreover, the people who are qualified to talk about D vs. other languages are almost sure to be D enthusiasts, so you're unlikely to get a balanced answer. – David Thornley Sep 01 '10 at 19:26
  • 4
    How could we possibly answer this without more detail? Clearly it's worthwhile for *some*, and not worthwhile for *others*. What do you expect out of the language? Are you planning to develop something with it, or is this a learning experience? Have you looked into what D offers at all? – Michael Petrotta Sep 01 '10 at 19:27
  • About the question of Michael Petrotta, yes, I'm looked about what D offers, but ALL languages offers the Heaven and The Paradise base on this or that feature. I want to know from people who really have been working in real stuff if this features are so wonderful as they said. – Nisanio Sep 01 '10 at 19:53
  • 1
    This isnt a forum, please edit your original question with your edits. – Mornedhel Sep 01 '10 at 20:05
  • 1
    @Nisanio: Thing is, you'll get enthusiastic answers about any language whose users use it by choice, be it D, Common Lisp, Forth, or something I haven't even heard of. You can't rely on such answers to find out if the features are really wonderful, because you're getting a really big selection bias. – David Thornley Sep 03 '10 at 20:41
  • And that isn't useless... Let me explain: even an enthusiast NEED may arguments about they choices, focus en the real differences about the languages. Obviously this question wasn't post for D fans, but for D programmers (there are different things), but i can make the filter of opinions – Nisanio Sep 03 '10 at 21:17
  • https://hackr.io/tutorials/learn-d-programming-language is a great place to find best online D language tutorials. All the tutorials here are submitted and recommended (upvoted like SO) by the programming community. – Saurabh Hooda May 17 '17 at 12:29

6 Answers6

33

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.

Community
  • 1
  • 1
dsimcha
  • 67,514
  • 53
  • 213
  • 334
  • 3
    To your comment about boilerplate code I would also add--when you have to create boilerplate, you can often do it *in the language itself* using string mixins. Which are also compile-time checked. In essence, you get to use the D compiler itself as a code generator! – Tim Keating Oct 01 '10 at 04:51
9

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.

Taco de Wolff
  • 1,682
  • 3
  • 17
  • 34
  • 5
    I must add, after 1.5 years, that the standard library has progressed significantly. It is very usable and stabilizes quickly. The compiler also rapidly matures. The current hindrances are a lack of thorough documentation and little compiler bugs of corner cases. I hope this latter will solve with GDC being integrated into GNU compiler toolset. – Taco de Wolff Jan 15 '12 at 11:32
8

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.

You
  • 22,800
  • 3
  • 51
  • 64
  • 5
    While true when this was posted in 2010, D2 is here with gcc and LLVM support. D1 is a relic of days gone by. – Matt Kline Feb 13 '14 at 18:53
7

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.

Qwertie
  • 16,354
  • 20
  • 105
  • 148
2

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.

Lothar
  • 12,537
  • 6
  • 72
  • 121
  • 4
    *non existance of a good D debugger* — gdb supported D recently, and also check out [Visual D](http://www.dsource.org/projects/visuald). – kennytm Sep 05 '10 at 19:25
  • Yes i knew people would mention gdb, thats why i wrote the non existance of a good debugger. And thanks i will check out Visual D next time i do a spare time D project again – Lothar Sep 05 '10 at 19:37
0

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

ponce
  • 919
  • 5
  • 15