The D Programming Language, Version 1.0

penguinblotter writes in a journal article: "Soon, Walter Bright is scheduled to release version 1.0 of the D Programming Language. D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. Special attention is given to the needs of quality assurance, documentation, management, portability and reliability. D has appeared on Slashdot a few times before, and Walter has continued to add more and more features. Most Slashdot community comments in these articles have been offered on feature X or spec Y without reading through the extensive D newsgroup archives. It has been here over the past seven years where extremely gifted and experienced programmers hashed out discussions and arrived at excellent implementations of all the ideas discussed." Read on for the rest of penguinblotter's writeup.

For those with a C/C++ background, D offers:

• native code speed
• extremely fast compilation times
• garbage collection (although you can manage your own memory if you want)
• OOP - by reference only, easy initialization, always virtual
• cleaner template metaprogramming syntax, more powerful templates, as well
• built-in dynamic and associative arrays, array slicing
• versioning (no preprocessor madness)
• link-compatibility with C
• nested functions
• class delegates / function pointers
• module system

For those with a C#/Java background (a shorter list, but one with big wins):

• similar syntax
• No virtual machine or interpreter
• built-in unit testing and design-by-contract

These two comparison sheets can go into more depth on how D stacks up against other languages.

From D's creator:
For me, it's hard to pinpoint any particular feature or two. It's the combination of features that makes the cake, not the sugar, flour or baking powder. So,

1. My programs come together faster and have fewer bugs.
2. Once written, the programs are easier to modify.
3. I can do (1) and (2) without giving up performance.

Get your compilers and start hacking D!

• DMD (Digital Mars reference compiler, Windows & Linux, x86)
• GDC (GCC front-end)

Weird writeup:

[Per Abrahamsen]

From the compared to C/C++ list:

        * native code speed

As opposed to C/C++.

        * extremely fast compilation times

Point granted (compared with most C++ compilers).

        * garbage collection (although you can manage your own memory if you want)

Point granted, even though C and C++ arguably have optional garbage collection as well (if you link to the right library).

        * OOP - by reference only, easy initialization, always virtual

Only value semantic? Meyer had to accept that value semantic was useful, and add it to Eiffel eventually, and C# added it over Java.

And no way to specify that a function will always be the one specific. Good luck doing any kind of reasoning there.

Bragging about missing features, that are essential to many tasks.

        * cleaner template metaprogramming syntax, more powerful templates, as well

*More* powerful templates? The usual complaint is that C++ templates are too powerful (a Turing-equivalent compile time language).

        * built-in dynamic and associative arrays, array slicing

Not exactly a recommendation that the core language apparently is so weak that these can't be put into libraries.

        * versioning (no preprocessor madness)

I'm guessing he meant variants here, the preprocessor is often used for variants, rarely for versioning.

        * link-compatibility with C

Which C and C++ of course lacks?

        * nested functions

Point.

        * class delegates / function pointers

Obviously both C and C++ have function pointers.

        * module system

More preprecessor replacement here.

The C#/Java list:

        * similar syntax

But totally different from C++?

        * No virtual machine or interpreter

You can compile Java and C# to native code as well, so this is just another case of bragging about a missing feature.

        * built-in unit testing and design-by-contract

I'm a C++ programmer, and this is by far the most interesting aspect of the D language (and of Eiffel before that). Don't know why it should be in the Java/C# list.

Re:This won't work...

[jlarocco]

Why do we need yet another programming language?

Exactly. There's already Fortran and COBOL, everything else is superfluous.

Seriously though, why don't we need another programming language? It's not like we only get a finite number of them. We're not going to run out of space or anything.

If it doesn't interest you, don't use it.

Re:Erm how is this better..

[Nasarius]

Try using .NET for systems programming. Or projects (I've made several thousand dollars from one so far) that must be portable to NT4, 2K/XP without requiring your clients to install extra junk on every computer, etc. Contrary to what Microsoft may want you to believe, .NET is not the solution to all the world's problems.

Re:This won't work...

[0racle]

Did you say the same thing when Python or Ruby were created? People do things in different ways, different languages end up with their strengths and weaknesses that way. So until there is a perfect language that is all things to everyone, yes there is always a need for another language.

Because the ones we have suck?

[Dion]

C/C++ are primitive languages barely above the level of Assembler macros.

Java is a bit nicer than C++ but it just can't perform at the level of C (how many OS'es are written in Java?)

perl/ruby/python are closer to being good languages, but they still don't perform like a compiled language.

I don't know if D gives the features of Perl with the speed of C, but it's certainly a step in the right direction.

Do we really need another D infomercial?

[Anonymous Brave Guy]

I'm sure D is a lovely language, but it just seems like another incremental change over C++, like Java and C# before it, and like both of those languages what it's lost and the opportunities it misses are as telling as the little tweaks it makes to improve things.

No-one has yet been successful, IMHO, in developing a really good industrial programming language. Those that make it tend to be pragmatic, practical tools like C and Perl and FORTRAN and COBOL. To be sure, each of these has many widely-acknowledged weaknesses, but the overall balance between those weaknesses and what you could get done using the language was right.

I can increasingly see why some well-known programming language designers shy away from feature comparison ticklists. I think it's because as soon as you go down this route, you bias the comparison so much that it's meaningless. For example, consider the first checklist [prowiki.org] cited in the Slashdot write-up. (I note in passing that this is a wiki, and may change before you read this.) Here are some of the "yes or no" (almost) categories:

Templates or executable macros

No difference in expressive power is acknowledged between LISP macros and C++ templates.

Thread synchronization primitives

With no reference to how expressive they are, and how powerful the idioms supported by them? This one is really telling, IMHO, because I don't believe the future lies in classical thread sync and locking primitives. The whole approach is just too prone to deadlocks and race conditions to withstand the heavily parallel future that multicore chips are starting to bring into the mainstream. When you have ideas like pure function programming languages, operating in a world without side-effects where explicit locking isn't necessary, or interesting ideas for inter-thread communication such as those in Erlang, another variation on built-in pthreads just isn't worth much.

Enumeration

So again, we acknowledge no difference between simple and low-level enumerations such as those in C, and concepts such as disjunctive types and pattern-matching that are very powerful, remarkably elegant, and mainstream in certain families of programming language. Again, this is just papering over a gap, where other languages operate on an entirely different level.

Long double floating point (80bit)

This is just desperation. Pretty much no-one uses 80-bit floating point arithmetic IME (and yes, I do work in the field). The portability hazards and lack of true support from almost every mainstream architecture make them almost irrelevant, except perhaps for a few very small niches.

Lexical Closures

Another telling omission: the power of all those neat functional programming features is dramatically reduced when you can't construct functions on-the-fly.

On top of all of this, the feature lists invariably gloss over some less concrete things that are nevertheless very important to systems programming languages. How portable is D? How many production-quality implementations are available? Is the language standardised or under the control of a single, commercial body? How much backing is there behind the language in the commercial development space; do others write libraries specifically for this language, or is it reduced to using C-style interfaces at the lowest levels anyway, and what impact does this have on the usefulness of features like DBC, exceptions, and so on? Does the language have an active hobbyist/volunteer community supporting it?

I could go on, but I don't want this post to disappear into the oblivion any more than it already will. Although I'm deliberately focussing on criticising in this post, as I often do with D, I keep an open mind and will happily engage in debate with others, or even be proved wrong by people who have found D to have compelling advantages. So go ahead, D advocates, start your counter-arguments here...

GC, No Vm or performance hit

[StrawberryFrog]

garbage collection ... No virtual machine

How do they square that particular circle?

native code speed

Just In Time Compilation in C# or Java has "Native code speed", in fact it goes one better - since the compilation happens at a later time, more processor or other specific optimisations can be made. That's not the slow part. GC has a lot to do with the perceived slowness. Isn't it disingenuous to tout both "native code speed" and "garbage collection"?

Re:D is surprisingly good.

[Geoffreyerffoeg]

If you don't know pointers, then you don't know how the machine works. I would never use a doctor that didn't know how my body worked.

Yes, but last time I went to the doctor he didn't grab a hand pump and start pushing my blood around.

And when was the last time C let you manually push items onto the stack?

The feature-checklist school of software design...

[stevenj]

...is obviously the birthplace of D. Heavens, it's the union of C++ (already a nightmarishly huge language), C99, and C#, along with dozens of other features halfway borrowed from functional languages and other inspirations. More features must be better, never mind that the language becomes insanely complicated! (Next they'll be throwing in the Fortran 2000 standard.)

My feeling is that languages shouldn't try to satisfy all possible needs. Rather, we should have small and clean languages, use the right tool for each job, and combine code libraries from different languages when needed. (I regularly use 3-6 languages in a single project and my life is much happier for it.)

(Legacy support is critically important too, but it is vastly better to provide legacy support by providing ways to call older languages, especially the lingua franca of C, rather than demanding that the new language be a superset of the old. I still call numerical libraries written in pre-1970 Fortran, but that doesn't mean I have to write my code in a Fortran derivative.)

Re:Do we really need another D infomercial?

[stevenj]

Long double floating point (80bit) — This is just desperation. Pretty much no-one uses 80-bit floating point arithmetic IME (and yes, I do work in the field). The portability hazards and lack of true support from almost every mainstream architecture make them almost irrelevant, except perhaps for a few very small niches.

Um, considering that the vast majority of the world's floating-point hardware is x86 and supports extended precision, saying that it lacks "true support from almost every mainstream architecture" is comical.

(I agree that relatively few numerical applications need extended precision on a regular basis, but it is awfully useful on occasion. A very simple use is to assess the impact of roundoff error on a double-precision program: by far the easiest way is to increase the precision and see how much the answer changes, but this requires a floating-point type with greater than double precision. Yes, you could drop in an arbitrary-precision type, but this may be too slow in a large computation.)

In any case, D's claim to this feature is a bit odd, since every x86 C/C++ compiler worth its salt already compiles long double to extended precision.

Keeping It Simple

[rumblin'rabbit]

Amen. Here's a quote from the article:

Special attention is given to the needs of quality assurance, documentation, management, portability and reliability.

So where is the word simplicity in all of this? Anybody that has learned to use C++ really well has, to my mind, earned the equivalent of a Master's degree. This makes C++ a brilliant failure. So to learn D will we require the equivalent of a PhD?

Good designers make things both simpler and more powerful. They improve the product as much through subtraction as addition. Instead we get this...

and Walter has continued to add more and more features.

Bloody hell.

object oriented

[elmartinos]

From TFA:

// Object Oriented Programming
CmdLin cl = new CmdLin(argc, argv);

Why do they always insist on this bad syntax? Why can't they write
CmdLin cl = CmdLin.new(argc, argv);
This way you can think of CmdLin as an object, new is just a method that returns a new instance. Voila, one keyword removed, and much cleaner syntax. This would not even offend the Java people because they can have the same syntax with a static method.

Re:More old junk repackaged to look new

[rbarreira]

Hey hey, calm down. Are you sitting now? Ok, read:

Programming languages are to intended to be used by humans.

Missing the point

[pammon]

The largest problem with C++ is its complexity, which causes the language to fragment into partially intersecting sublanguages representing each programmer's comfort zone. D does not address this problem; in fact, it makes it much worse. Example? C++ has seventy some keywords, but D has more than ninety. Another example? See if you can guess what this means in D:

0XA1_2_C35_4_5_6_5P6_Li

Give up? Why, it's an imaginary real. Yes, you read that right. Oh, and I specified it in hexadecimal, just to prove I can. And I threw in some underscores because you're allowed to do that too. Have you guessed what an imaginary real is yet? This is supposed to be the "simpler C/C++ replacement."

A good language strives to find a few constructs that solve multiple problems. A bad language takes the kitchen sink approach. C and C++ are not good languages, but wide deployment and support make them useful anyways. D does not have that, but the designers do have the luxury of learning from the mistakes of the past. So what the hell is their excuse?

Re:Erm how is this better..

[TheGavster]

Sodding lot of good that does if the vendor of the VM is only going to build for Windows.

Re:Missing the point

[donglekey]

A good language strives to find a few constructs that solve multiple problems.

D does this. You are looking past the dozens of examples where D has cleaned up problems that have been plaguing programmers for years to grasp at a chance to make a piece of code as messy as possible. Maybe you are comfortable working with C/C++ and don't want to deal with another language. I am not comfortable dealing with all the fucked up C and C++ out there. I have worked with D and it is exciting and refreshing. It is much cleaner and you either know it already or need to look harder.

Re:I have a problem with GC in a systems language.

[thona]

::Garbage collection in a language with destructors leads to wierd semantics, which is why Microsoft's "Managed C++" is a nightmare.

Really? I had to use Managed C++ for a part of a .NET project some time ago. Basically we used ISDN low level programming, and without an interpreting SDK the bytestreams of the messages are a pain in the ass to work with, and all SDK's are for C++, so we created a nice object model in Managed C++ that the C# main application could then use.

I found the managed C++ syntax tio be pretty nice, given the constraints of C++ to start with. Damn nice, to be exact. ::What seems to work in practice is reference counting

What does NOT work, is reference counting, except in the eyes of some programmer without a clue. Reference counting can not be used for any caching that should release items under memory pressure (which I happen to write a lot), and reference counting is deadls in case you have systems like a pointing to b pointing to c pointing to - a. Circular references get never collected.

Happens a lot to me. I often build trees of objects (A contains a list of childs, contains a list o childs) and any object has a pointer up to it's parent. Normal GC will release the whole tree the moment it is not reachable anymore, a "oh so working" reference counting GC will happily keep htat crap in memory, as there are always references.

SOmehow your programs seme to be simplistic - I run weak references and circular references basically in every project I do. But then, I work on database middleware, not exactly primitive web pages.

Re:This won't work...

[TERdON]

wasteful with western languages

I'm not sure which ones you are referring to, except of course English.

Swedish has ÅÄÖ. Norwegian has ÅÆØ, and so does Danish. Finnish has Ä and Ö. German has ÄÖÜ and ß. French has even more weird characters, including Ç. Spanish has Ñ, Ü and accents, and the list goes on. For really weird characters, check Polish. :) I don't doubt that a few of these are codable in pure ASCII, but for the rest of us, we're happy to be out of the code page choosing problems.

Re:Weird writeup:

[arkanes]

It's worth pointing out that the lack of core strings and vectors means that every C++ library more than 5 years old has it's own implementation of them, which means hooking libraries together means you get to waste time, memory, and performance on shuffling between almost identical string and array implementations. Multiple implementations of things like strings and basic vectors is a weakness, not a strength. The ability to provide specialized implementations of these is a strength, and D has that.

Re:Do we really need another D infomercial?

[WalterBright]

VC++ is one of the most widely used C++ compilers. The fact that it does not support 80 bit long doubles has apparently convinced a lot of people that such precision is unnecessary - and this wrong idea tends to propagate into other languages, since language designers are rarely familiar with numerical analysis.

The C++ Standard allows this to happen with C++ compilers. It's about time, however, that modern languages have decent, proper support for numerical analysis, and that means requiring the support of the full precision of the underlying hardware. D aims to fully support numerical analysis needs.

If other languages refuse to do so, well, that's another reason why there is a need for D.