Nowadays we here lots of hype about .NET and J2EE, lots of propaganda about how both C# and Java are "The Way of the Future." But as we all know, sometimes the real gem is the unsong underdog, the one that don't have full page ads in tech journals. And today I'm going to take a look at one such gem: The D Programming Language.
What is D?
D is a (relatively) new addition to the C family of programming languages, intended as a successor to C++ but also incorporating ideas and improvements from other C-like languages such as Java and C#. It is an object-oriented, garbage-collected, systems programming language that is compiled to executable rather than bytecode. The specification and reference compiler are currently at version 0.82, and are expected to reach 1.0 within the year. The reference compiler runs on both Windows and Linux x86, and the frontend if Open-Sourced. A port of the frontend to GCC is underway and already functional on Linux x86 and Mac OS X.
Maintained by Walter Bright, author of the Digital Mars C/C++ compilers and former compiler programmer for both Zorland and Symantec, is the language's primary author and maintains the reference implementation, though most if not all language decisions are made only after discussion on the D newsgroup. (See links at the end.)
How's That Different Than What We Had Before?
D is designed to address the shortcomings of C++. While a powerful language, years of history and unneeded complexity has bogged down that language. Five years after the language's standardization, most compilers are still struggling to become compliant. While C++ pioneered in generic programming and brought objects to the masses, its complexity makes it very hard to add new features, and so it lags behind in newer techniques such as design-by-contract, unit-testing, and include dependency resolution.
In most respects, however, D functions like C++: most C++ code can be converted directly and will, generally speaking, function as expected. Perhaps the largest change in D is the addition of automatic garbage collection, though explicit delete statements will still function as they do in C++.
While not the direct parent of D, many of Java's techniques have been incorporated into it. Some claim that D's object definition syntax is more similar to Java's, though it really ought to be familiar to any modern object-oriented programmer.
In terms of similarities, D and Java are both garbage-collected, both do not make a distinction between the ".", "->", and "::" operators, both include null as a keyword, and both feature try-catch-finally exception handling. Also D's module system of includes is similar to Java's packages. As to differences, D is compiled to an executable instead of bytecode, and is not as rigidly object-oriented. Unlike Java, D does not force the object-oriented paradigm on the programmer and can be used just like procedural C. Finally, D allows (but does not encourage) pointer manipulation.
C# and D are really both answers to the same basic question: How can we improve C++? Both are derived from C++ with specific elements drawn in from Java. Both share most of their major features. The biggest difference is that unlike C#, D does not run inside a VM, and can thus be used to write systems (low-level) code. This also allows D to offer the programmer the options of performing manual memory management, which C# does not, nor does C# have anything like D's templating capabilities, which are on par with C++'s.
OK, What Does It Do?
Having now established what D is not, it might serve us well to note what D is, and to examine some of its features:
Binary C Compatibility
D programs can import and link against C code and libraries, providing D with free access to a huge amount of pre-written code. Note, however, that D is not link-compatible with C++, so pure C wrappers are required to access C++ code in D.
Because D is compiled to binary rather than bytecode, and it does not run inside a virtual machine, D can be used for systems and low-level programming. It allows in-line assembly, and the garbage collector can be regulated (or even disabled) if real-time capabilities are necessary.
Lexicial, Syntactic, and Semantic Clarity
One of the major goals of D is to eliminate a lot of the complexity of C++ that has made it so hard for compilers to live up to the standard. A simplified syntax makes the job of both the compiler and the programmer easier, as it allows compilers to be more efficient and reduces the likelihood of compiler bugs. As an example, D drops the much-contested angular bracket syntax for declaring templates, making code easier both to read and parse.
Design-by-Contract and Automatic Testing
D advocates the use of design-by-contract and provides built-in facilities for automatic unit-testing. While both are technically possible in C++, D makes them core tenets of the language to make them easier to use for novices. The hope is that with testing built into the language bugs will be easier to identify and fix, especially if programmers get into the habit of using the testing features.
Removal of Archaic Features
Probably the language's greatest goal is the elimination of archaic and/or needlessly complicated features. For instance, D does away completely with the C preprocessor, relying instead on built-in versioning capabilities. Forward declarations are out the window on the same token. Also, it replaces the often-complicated multiple inheritance of C++ with Java's single inheritance and interfaces. Most of these features are also related with the above of clarity, making the code easier for a human to read as well as easier for a compiler to convert into binary.
These are by no means the only features of D, but for the sake of brevity I shall leave the exploration of the others as an exercise for the reader. For more information, see Walter's SDWest paper.
- "D language, Page 1/2"
- "D language, Page 2/2"