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)

This won't work...

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

Now, after F do we get G or 10?

Re:This won't work...

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 [wikipedia.org], but twice [wikipedia.org].

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

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

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

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

UTF-32 does, indeed, do that. It is quite a good way of working internally. You can do things with UTF-32 much more efficiently than with UTF-16 or UTF-8 (e.g. searching for a character just requires you to compare each 32-bit value to the target, without having to check it isn't a special character that is the first in an escape sequence). Most modern processors come with a vector unit that can handle vectors of 32-bit integers, so if you have to handle large quantities of text you can speed certain things up even more by running streaming calculation on the vector unit.

Re:This won't work...

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:Because the ones we have suck?

There is no such thing as an interpreted language. There are languages, and there are interpreters and compilers. Lisp, for example, can be both interpreted and compiled (Scheme is usually interpreted and Common Lisp is usually compiled, but there are exceptions). Tcc can both compile and interpret C code. Java can be compiled by something like gcj or interpreted by a JVM. If you compile Java you lose some of the features; the JVM bytecode format is designed so that it is easy for automated tools to reason about. At load-time, the JVM will parse the class files and check that they do not violate the Java security model; this is theoretically possible with compiled code, but much harder.

The Squeak runtime for Smalltalk is written in Smalltalk. There is a smallish subset of Smalltalk used to write the basic functionality, which is compiled to native code. This then supports the whole language. The same model is, I believe, used for JNode, an operating system written in Java...

Re:Because the ones we have suck?

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

D is surprisingly good.

I'm looking at using it via GDC for my next project. For people who use C/C++ regularly, this is something you ought to look into.

It's not a toy language. If you're a C++ programmer, you'll be almost immediately functional in the language. And you can call C and C++ libraries seamlessly. It's pretty sweet.

Re:D is surprisingly good.

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

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.

Re:D is surprisingly good.

Please see: http://dsource.org/projects/bcd [dsource.org]

Weird writeup:

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.

java native code compilation

All other considerations aside, runtime speed really should be a justification as a bonus to Java. 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 [wikipedia.org] can greatly increase the speed of your code and put it close in line with C++. I would certainly consider D if both 1 and 2 were better than Java.

Re:java native code compilation

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 [wikipedia.org] 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).

Cheers for D!

Cheers for D, and happy new year to Walter and all the rest! As much as the D community is often derided for their sometimes aggressive marketing, D is actually a programming language that can run with the best of them.

GUI for D language

I am hoping that D is or soon will be a good alternative to C#.net and Mono. What is the preferred GUI environment for D? I was watching the D forums during the first half of 2006 but I could never post any questions to the D forums so I gave up. It looks like I gave up too soon. Does anybody know why I could not post to the D forums?

Slashdot doesn't read full archives

Most Slashdot community comments in these articles have been offered on feature X or spec Y without reading through the extensive D newsgroup archives

You must be new here.

Currently learning D

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/ [dsource.org]. There are some interesting projects such as Derelict [dsource.org] (collection of C game bindings) and Bud [dsource.org] (make and SCons replacement).

It looks like a step down

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.

Do we really need another D infomercial?

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,