Pinderkent

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.

I saw an article today, written by Clinton Forbes, suggesting that it's useless to compare compiled and interpreted programming languages. The target of his wrath is this comparison of D and Ruby, with it claimed that it is "comparing apples to oranges."

That is clearly not the case. It is often necessary, and quite acceptable, to compare two programming languages. Both Ruby and D allow for a human to instruct a computer how to perform various tasks. Thus they are the same thing. The execution method (compilation versus interpretation) is nothing but yet another factor to be considered when performing a comparison.

The D versus Ruby article actually offers a very balanced, accurate and informative comparison of the two. The benefits of each are clearly pointed out, as are the weaknesses. In the end, the author finds that D is superior for his task, which is the implementation of a new interpreted language. This is a very sensible conclusion, as the implementation of an interpreted programming language interpreter in an interpreted language will no doubt offer terrible runtime performance.

But I also think Clinton's article is indicative of a trend I have noticed among many of the advocates of dynamic languages like Python, JavaScript and Ruby. Namely, they're often unwilling to critically compare their preferred language to other languages, especially when one of the main criteria is runtime performance. I suspect his might be because dynamic languages are often severely handicapped when considering this very critical factor. Their very nature prevents them from overcoming their runtime performance disability.

So as I stated earlier, it's perfectly fine, and necessary, to compare compiled and dynamic programming languages. And it's absurd to consider such comparisons to be "useless".