Will hybrid languages like D render functional languages like Haskell, OCaml and Common Lisp irrelevant?
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.
November 5th, 2007 at 11:30 pm
The answer to the question is “No”. Not without referential transparency. (and full type-safety with a type language at least as expressive) Most of the things you list only work at their best in pure code, and most code you didn’t write yourself - so how can you trust it? You need the language guarantees to really be effective with most of the nifty features in Haskell.
November 6th, 2007 at 11:42 am
Scala is another hybrid language to keep your eye on: functional, imperative and object-oriented code are all possible. It offers most (if not all) of what D offers, but targets the JVM. Further, it’s completely interoperable with existing Java code which makes it a viable option for Java shops looking to increase their developer productivity.
November 7th, 2007 at 10:38 am
D doesn’t even have variant types and pattern matching let alone anything even vaguely like the type systems of OCaml, Haskell and F#.
November 8th, 2007 at 4:06 pm
If anyone is interested in a “Universal Programming
Language” concept please visit the URL below:
http://groups.google.com/group/universal-programming-language/
November 12th, 2007 at 10:10 am
To John Harrop
D has variant types, not builtin indeed, but as part of it’s standard libraries.
http://dsource.org/projects/tango/docs/current/ at tango.core.variant
Same is valid for regexp.
To Greg M
In fact you can trust foreign D code. Walter Bright (the author of D) has written a nice article regarding function hijacking :
http://www.digitalmars.com/d/hijack.html
In general:
It would be nice to see some OCaml code translated into D and vice versa. Just a suggestion for your next Blog
November 12th, 2007 at 10:19 am
I think the question is too strong. Hardly can D (or any other language) make functional or any other kind of languages irrelevant. However, that also means functional languages do not render languages like D irrelevant. Of course, referential-transparency is the most important thing, but also the possibility to reuse knowledge from C++/Java and practicality of language is very important. As for D: it merges some functional features into C-like language. (And in the future even more http://s3.amazonaws.com/dconf2007/WalterAndrei.pdf), allowing more developers familiarize it with them. And maybe in the future, when we will know how to merge D or new C# with Haskell, we will have our Nirvana: http://beta.channel9.msdn.com/Media/Simon-Peyton-Jones-Towards-a-Programming-Language-Nirvana/
November 12th, 2007 at 12:29 pm
I agree with Jon that variants and pattern matching are certainly one of the most commonly used functionnal language trait, and that they would be appreciated in D. I’d actually love to see a language that lets you choose on what objects the GC will act, this would certainly permit to do array-intensive computations (like for computer vision) with functionnal languages and would provide a way for lot of researchers and engineers with a functionnal programming background to continue using functionnal languages for such tasks
November 12th, 2007 at 6:20 pm
I’m not too impressed with D. It doesn’t offer enough advantages over C++ after the new standard or even C++ and boost to be worth a huge switch.
However…
Hybrid languages are clearly the way forward because they broaden the available set of problems that you can accomplish with a single programming system. Languages that support higher-level concepts like generics, metaprogramming, functions, etc. doubly so because you can write some concepts using other language elements. At the same time, languages that appear to work largely along existing procedural/object-oriented paradigms will have a faster adoption rate because they provide enough familiar things to grasp for.
November 12th, 2007 at 7:30 pm
You mentioned ?? the title OCAML and CL as if these are NOT hybrid languages :))
November 12th, 2007 at 9:42 pm
Do you think that D has gained sufficient traction is its specified domain to be considered a viable programming language in the realms of corporate IT?
I can’t say that I have any evidence to support this, the same is not true of OCAML and HASKELL, and certainly ERLANG has significant deployments.
November 13th, 2007 at 12:14 am
reply to Jon Harrop
as for variant types, I don’t want them.
With regards to pattern matching (If you are referring to “match types of the form ….”) then I am surprised to find that I am working with something that doesn’t exist. Joking aside, I am working on a lib that is basically nothing but pattern matching. Unfortunately it is not ready for even alpha release so I can’t show any code.
If you are referring to something else, then I’m at a loss as to what it would be.
November 13th, 2007 at 1:31 am
D has automatic parallelization planned for the future too (i.e. if a function is pure, the compiler can parallelize it for multiple cores), making writing pure-functional code in it even more attractive.
November 19th, 2007 at 9:00 am
Not D, perhaps Nemerle. But Nemerle has a disadvantage of being tied to a single platform (.NET/Mono, I guess it limits areas where it can be applicable)
January 21st, 2008 at 12:58 pm
Wow, just read your “End of an Era?” and now this, and I just have to wonder if you ever come out of where ever it is into the real world?
The KDE release seemed to have less effect than pissing in the ocean. And D? Does anyone use D? Last time I looked for a new systems programming language (to write a VM in) it looked like D couldn’t actually replace C since some things one needs to do were not doable.
In any event D will have similar problems to C++: simply to complicated. What languages like C++, Perl and various others have *actually* taught us is that making a language too complicated makes it hard and error prone to use, and extremely expensive to maintain.
Your comment about people having acquired a skill to “quickly read C code” is bogus. C is so complicated and unreadable that very experienced C programmers commonly misread lines of code leading to bugs.
Learning a simpler language with very simple syntax is not hard. The way forward is not with more ridiculous over complicated C derived languages, it is breaking with our tradition of trying to prevent ourselves from succeeding. Stop over complicating everything and embrace the power of simplicity.
Or don’t and let the programming world leave you behind. But based on the posts I’ve seen on your website so far, I don’t think you’d ever notice.