Although it hasn’t (yet?) caught on much in industry, anyone who follows modern computing trends will no doubt have heard of D. Its Web site describes it quite nicely: 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. The D language is statically typed and compiles directly to machine code. It’s multiparadigm, supporting many programming styles: imperative, object oriented, and metaprogramming. It’s a member of the C syntax family, and its appearance is very similar to that of C++.
There exists a listing of the language features of D. One thing we should notice rather quickly is how it acts as a solid bridge between the worlds of procedural, object-oriented and functional programming.
Although it may not have the rigorous mathematical backing of a functional language like Haskell, it does bring over many of the most practical features. For instance, it offers garbage collection, closures, nested functions, type safety, lazy function argument evaluation, compile-time function evaluation, generics, implicit type inference, and a lot more.
But unlike Haskell, it also offers a C-like syntax that is no doubt familiar to a great number of C, C++, Java and C# developers. This is where a lot of D’s power lies. It brings many of the benefits of functional programming, while also allowing developers to continue to use the syntax they’re familiar with.
A number of people within the functional programming languages community say that syntax is irrelevant; the semantics are what truly matter. That’s a shallow view to take. When it comes to developing large software systems in a rapid manner, reuse becomes a necessity. That includes not only code reuse, but also the reuse of previously-acquired skills, such as the quick comprehension of code with a C-like syntax.
It’s becoming clear that we will need to start making use of some of the features traditionally offered by functional languages if we want to continue developing more complex software. D will surely allow this to happen, likely to the degree initially necessary to truly realize the benefits of such an approach. But we have to ask, will a transition to purely functional languages ever be necessary if languages like D offer the functional features in a manner that is sufficient for most developers?
When considering the software development landscape at this point, I’d have to say that many developers will be swayed towards D, rather than going all the way to Haskell, Standard ML, OCaml, Erlang, Common Lisp, or a host of other functional languages. D may very well offer the best trade off between code/skill reuse and productivity increases from functional language features.
If D keeps improving as it has been as of late, we may very well begin to see its adoption on a far greater scale. It took a number of years for languages like Ruby and Python to really start to take off. D may be just around the corner.