Why D kicks serious ass over C++, leaving it dead and broken on the sidewalk | Hacker News Reader

Why D kicks serious ass over C++, leaving it dead and broken on the sidewalk

boscoh.com

14 pointsnickb17 comments

"A lot of the features are designed to make it easier for the compiler writer."

That kind of scares me. Who cares how hard the compiler writer's job is? A compiler is written once, whereas the programs that the compiler compiles (hopefully) comprise a much larger body of code.

That said, the article sure made D sound like an improvement over C++, with many of the same benefits. Of course, getting rid of the preprocessor seems kind of strange... I've used quite a few macros in my C code. Even the crappy macros you get with C (as compared to, say, Lisp) are certainly better than none at all.

It's really hard to tell what he's getting at with that comment. It appears that there is a stated goal of making it a 'systems' programming language, suitable for replacing C and C++.

Based on features such as the ability to write source code in 6 different character formats, it doesn't seem like the sort of features he's talking about imply sacrificing anything in the language.

It probably means things like this (http://www.digitalmars.com/d/lex.html)

Complex literals are not tokens, but are assembled from real and imaginary expressions in the semantic analysis:

       4.5 + 6.2i		// complex number

Stuff that is invisible to a programmer. (This was a completely random example, I don't know whether it's really such an optimization or not.)

One reason to make a compiler easy to write is that it makes the language more portable, which is an important feature of a low-level systems language. Low level languages are more difficult to make portable. One of the reasons the original C was so successful is that it was (relatively) easy to implement a compiler for your architecture.

I think it means mostly that D is easier to parse than c++, which is not just an advantage for compiler writers, but also for any other tool which has to work with the sourcecode.

"In D, objects are always allocated on the heap. ... <snip> ... So you can eliminate the -> operator. It's always obj.property and your code becomes that much easier to read."

I think one of the best reasons still to use c++ is your control over memory and the speed which you can only get when allocating objects on the stack. Maybe that was the sort of problem he was fighting with in c++, but for me it's an argument which would make D a worse choice than c++ for those tasks where I would use c++ now.

Not very convincing.

Those who try to fix C/C++ with a "nicer" declaration syntax always fail unless they just copy C/C++. So what's so special about C-style declarations?

  int a[10];

vs.

  int[] a;

The first is more natural, since you are going to apply the index operator [] to a later on, many times. This is purely psychological. This shows that our understanding of "regularity" and "relevance" of a formal syntax may be against our instincts.

The problem with the first one is that what you are declaring is effectively a const pointer named 'a' to 10 consecutive memory locations allocated for the size of int. The second is a declaration of a variable-length array named a.

So, for example, you can't do this:

       int a[10];
       int b[10];

       a=b;

You get a type error, or an lvalue error, because you can't assign anything to a constant.

Good point, but still, you can apply operator [] to a and b in some non-C dynamic language, which means the "int a[]" style is probably more relevant psychologically.

I agree that int a[10] feels more natural, though if the brackets are empty my only preference is that the language pick one or the other. Don't make "int[] a;" and "int a[];" equally valid syntax, but totally different semantics.

My main point is that this is a relatively cosmetic issue relative to the ability to use 'foreach' syntax instead of iterator objects and while loops.

C++0x addresses those things -- foreach etc.

There's clearly a market for some sort of a fixed C++ but not the Java/C# way. D tries to fill the niche, but it doesn't give a feeling of elegance or otherwise of something really new and unseen before.

The article only mentions a few of D's features. There are a lot more improvements. The templating system for instance is quite innovative. http://www.digitalmars.com/d/templates-revisited.html Variadic Templestes: http://www.digitalmars.com/d/variadic-function-templates.htm...

But there are other things as well like the lazy evaluation, and built in contract and unit test support.

Ave a look at the articles on this page http://www.digitalmars.com/d/

And the specifications http://www.digitalmars.com/d/lex.html

Templates in D look like just a syntactically polished variation of C++ templates. Of course there are some new features there, but I don't see anything that can't be done with a compiler that is capable of evaluating some functions at compile-time. C++ can't do that, but my point is, why bother creating such a complicated template system for something that can be done the easy way?

Variadic templates: can be done with variant arrays and again, with smart compile-time evaluation if necessary.

Isn't Java an adequate alternative to C++ for nearly any purpose?

You may find this article about Java, Lisp, D interesting: http://www.digitalmars.com/d/lisp-java-d.html

"D is a multi-programming language"

No wonder there are so many useful applications written on D!

I have used at least one.

I believe E will be even better then D.

D is a very young language that is still under development, so this is the reason why you have not yet heard of very many "useful applications". It does have some innovative features, like unit test support built into the language among other things.

Reply on news.ycombinator.com