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)

Comments

This won't work...

[PurifyYourMind]

...it's just another version race. D may have won for now, but someone out there is already working on the E programming language. ;-)

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:This won't work...

[TERdON]

Now, after F do we get G or 10?

Either it'll be called 10, or H. G, has already been taken, not only once, but twice.

For your reference (kudos goes to Wikipedia), the following single letter (sometimes including some additional nonalphabetic characters) have also been implemented:

A+ A++ B C C-- C++ C# D E F F# G (now known as Deesel) G J J# J++ K L M4 Q R S S2 T X10

So - that only leaves you the letters H, I, N, O, P (sic!), U, V, W, Y and Z if you don't want to have a name clash with another programming language. Technically, M and X are followed by numbers in the previous examples, so you could argue for them as well, and even A (as it has a plus behind the letter)

I'm mostly surprised that noone has thought of a (P)rogramming language. :)

Re:This won't work...

[sacrilicious]

So - that only leaves you the letters H, I, N, O, P (sic!), U, V, W, Y and Z

I hope someone creates an "O" language. That way, interface bindings for it could be called "O-interfaces", or "O-faces" for short. So when you create a nifty library for the language, publishing it could be known as "showing the world your O-face".

Re:D is surprisingly good.

[matrixise]

from http://digitalmars.com/d/interfaceToC.html

D does not provide an interface to C++. Since D, however, interfaces directly to C, it can interface directly to C++ code if it is declared as having C linkage.

D class objects are incompatible with C++ class objects.

Currently learning D

[kihjin]

Note: I've been programming in C/C++ for four years.

I took it upon myself to learn D not more than a few weeks ago. A classmate introduced me to the language last spring.

While I'm still learning D, it has some notable features:

• auto keyword for inferred type declaration
• lazy keyword for evaluation
• delegates are like function pointers, but cooler. Literal statements can be passed as variables, and aren't evaluated until the delegate is called.
• scope(exit|failure|success), specify a block of exit code
• in/out/inout function keywords, offer readable code for determining what a parameter in a function is designed for.
• get/set methods automatically become a property (accessed like a public variable)
• foreach, foreach_reverse, container iteration
• with statement, C++'s using on a object-level

Of course one may argue that none of this is necessary and could be made independent of the language itself. My belief is that would increase the complexity of coding in D.

If you're interested in D you should visit http://www.dsource.org/. There are some interesting projects such as Derelict (collection of C game bindings) and Bud (make and SCons replacement).

It looks like a step down

[Anonymous Coward]

After working so hard to get from C to C++, I don't see why I would settle for D. My next programming language is going to be B- or better.

Re:Another 'Toy' Programming Language

[nacturation]

I'll stick to languages that have at least a professional following, in use by real software engineers (that is, engineers who can legally call themselves engineers), not the run of the mill code monkeys. I'm dying to know... do you mean Fortran or Lisp?

Re:java native code compilation

[Decaff]

Java isn't that much slower if you actually take the time to compile it to native code first. Using something like a JIT compiler http://en.wikipedia.org/wiki/Just-in-time_compilat ion can greatly increase the speed of your code and put it close in line with C++.

This is a bit of an old myth. Almost all Java is run as native code these days, even on VMs, and is mostly pretty close to C++ speed. Benchmarks that show Java as significantly slower than C++ usually result from not allowing the VM enough time to perform native code translation of time-critical code. Java has moved away from JIT compilation (as against the later optimisation of HotSpot) because it led to long start-up times - you had to wait for code to be compiled to native before it ran. Now Java usually starts up as interpreted, with the translation to native code happening later on, in the background.

Where C, C++ and D win out over Java in terms of performance is when you need programs that have to start up fast, run fast, but only for short periods (a few seconds).

Re:GC, No Vm or performance hit

[Anonymous Brave Guy]

garbage collection ... No virtual machine ... How do they square that particular circle?

The same way as countless other programming languages have in the past, I imagine. Why do you think garbage collection requires running your code under a VM?

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.

Of course, you're overlooking all the overhead of monitoring the code long enough to determine which on-the-fly optimisations are worth performing, and of compiling the code itself, neither of which is trivial.

GC has a lot to do with the perceived slowness.

True, though of course it's not without overheads. Almost all of the Big Claims(TM) made by GC advocates in these discussions come with a catch: state-of-the-art GC method number 17 has a lower amortised cost of memory recovery than explicitly freeing it C-style!*

* But only if your system contains 10x as much memory as the program will ever need anyway.

This is traditionally followed by a wisecrack about how memory is cheap, followed by three enlightened posters pointing out the stupidity of that argument for multiple reasons. :-)

Isn't it disingenuous to tout both "native code speed" and "garbage collection"?

That depends a lot on context. If you really have a system where the overheads of GC are trivial but all the advantages are present, it seems a fair claim. It's just not likely to be universally true, and representing it as such would indeed be disingenuous.

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.)

Python and D

[MightyMooquack]

One area I see D being useful in is integration with Python. Writing to the raw Python/C API is cumbersome. (Managing reference counts is tedious.) Boost.Python is difficult to build and slow to compile. I've written a library for D called Pyd, whose purpose is not entirely unlike Boost.Python's.

Pyd is easy to use. It provides its own extension to Python's distutils. Usually, you just need to make sure the D compiler is on your PATH, write a setup.py file, and run python setup.py build.

"Hello world" in Pyd looks something like this (and I apologize for the lack of indentation):

import pyd.pyd;
import std.stdio;

void hello_func() {
writefln("Hello, world!");
}

extern (C) void PydMain() {
def!(hello_func);
module_init();
}

Re:Because the ones we have suck?

[thephotoman]

Wait...C++ without the bullshit? That takes away all of C++!

Comparison to Objective-C?

[Jimithing DMB]

I noticed that a comparison to Objective-C is quite conspicuously absent from the list of languages compared to D. Why is it missing? Granted D seems to be a much greater change to C than Objective-C is but I can't help but thinking that one of the main attractions to D seems to be its heap-based garbage-collected object system. You can already get the object runtime with Objective-C. If you use GNU you can even have Boehm GC (which is apparently the GC that D uses). If you use Apple you will have to wait for Leopard to get GC. Another new Objective-C feature is the ability to use full C++ objects as instance variables in your Objective-C classes and do the right thing with initializing (calling the default no-argument constructor upon alloc).

On top of that, Objective-C actually includes tons of reflection information. Although Objective-C has protocols which are roughly equivalent to Java/C# interfaces they are almost completely unnecessary. In Objective-C one can query at runtime whether a method is implemented or not and if so call it. So whereas in Java you'd do this:

if(anObject instanceof MyInterface) ((MyInterface)anObject)->doSomething();

in Objective-C you can do this:

if([anObject respondsToSelector:@selector(doSomething)]) [anObject doSomething];

The difference being that in the Java case you have to declare MyInterface as containing the one doSomething() method and inform java that your object extends MyInterface whereas in Objective-C you merely need to provide a doSomething method on your object.

Basically that means that in Objective-C every single method effectively becomes an interface. You would not believe how useful this is once you realize it. Note that at runtime there is ZERO difference. In both the Java and Objective-C cases the object is being checked to see if it implements something. Same with C++ if you use dynamic_cast<>()

Granted every language has its niche and I'm sure D will find its. Objective-C's niche is definitely GUI programming. The ample reflection information allows for easy implementations of archiving (serialization) and most importantly key-value coding and the related action methods pattern. It's a pretty damn cool thing when your RAD tool simply outputs archived objects that refer to methods to be called upon certain actions simply by name.

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?