Home > D Programming Language, programming > The Future of D is Functional

The Future of D is Functional

The D Programming Language has an impressive list of cool features. That is not always a good thing. A feature should contribute to the philosophy and foundation on which the language was built. If it doesn’t, harmony breaks down and the result is a language that is harder to learn and to use.

Some people think D suffers from such a feature creep. To some degree I can agree. D has features that are unlikely to become widespread, but most of them are aligned towards a common goal. That goal is bringing productivity to the world of low-level programming.

Lately, a new goal has emerged from the D community, and it has triggered some real intense activity. The future of D seems to lie in the field of functional programming, making the imperative and the functional paradigms truly come together.

Why is this important? Let me quote Walter Bright from a discussion at the D forums:

The future of programming will be multicore, multithreaded. Languages that
make it easy to program them will supplant languages that don’t.
The surge in
use of Haskell and Erlang is evidence of this coming trend (the killer
feature of those languages is they make it easy to do multiprogramming).

As we all know, multithread programming in an imperative language is a real pain. It’s complicated and easy to get wrong, but that is not the case in a functional language. A pure functional program is thread-safe by design, since it’s free from mutable state and side-effects.

You never have to worry about deadlocks and race conditions because you don’t need to use locks! No piece of data in a functional program is modified twice by the same thread, let alone by two different threads. That means you can easily add threads without ever giving conventional problems that plague concurrency applications a second thought!

Quote from Slava Akhmechet’s excellent article Functional Programming For the Rest of Us.

What the people behind D want to do is to create a true functional subset of the D Programming Language, and create a safe interfacing to parts of the program that are imperative. The functional subset would enforce pure functional programming, like disallowing access to mutable global state and calls to non-pure functions. In effect that would enable you to write parts of your program that need to be thread-safe in a functional style, while using the style of programming that most of us are used to for the rest.

But, it might not stop there. Andrei Alexandrescu, who’s one of the driving forces behind the functional subset, has suggested that the enforcements inside a pure function can be relaxed to allow mutability of what he calls “automatic state,” thus allowing imperative techniques to be used as long as the mutability doesn’t leak across the function barrier. Here’s an example from Andrei’s slides on the subject:

int fun(invariant(Node) n) pure {
  int i = 42;
  if (n.value) ++i;
  int accum = 0;
  for (i = 0; i != n.value; ++i) ++accum;
  return n.value + i;

This code doesn’t look a bit functional, but the result of fun() is solely dependent on its arguments, so seen from the outside it’s pure.

Mixing pure functional and main stream imperative programming is certainly bleeding-edge. As far as I know it has never been done in any other language. But even though I’m excited, I can’t help wondering whether this is the right way to go. There’s a risk that D spreads itself too thin, and that the pure functional subset of D will be too noisy; I anticipate a heavy use of the invariant keyword for instance.

Would it be a better option to create a completely new language, say Functional D, and make D and Functional D interoperable on a binary level? At least that would battle the noise by reducing the need for explicitly expressing things like immutability, which can be taken for granted in a functional language. I also suspect that the compilers would be less difficult to implement than a compiler that has to support both styles.

But then again, I don’t know much about making compilers. I just happen to be more of a minimalist when it comes to computer languages. (As opposed to my preferences for APIs and Framworks.)

Expect more posts on this subject as I plan to delve into details next.


  1. anonymous
    April 16th, 2008 at 11:11 | #1

    One word is very low syntactic baggage considering the verbosity most people are willing to accept from java.

    • April 17th, 2008 at 06:59 | #2

      True, but I have a couple of small objections:
      1. The invariant keyword is long, and must probably be used all over the place.
      2. As suggested, all pure functions needs to be marked with the “pure” keyword. That makes it two new keywords.
      3. Just because it’s less verbose than some other language doesn’t make it better.
      But I see what you mean, and I’m not negative about the functional subset. I’m merely venting concerns.

  2. anonymous
    April 16th, 2008 at 12:11 | #3

    “Mixing pure functional and main stream imperative programming is certainly bleeding-edge. As far as I know it has never been done in any other language.”

    smalltalk, python, javascript, ruby all mixed in varying degrees of functional with OO/imperative.

    ocaml, F#, scala are highly academic approaches at mixing functional with OO/imperative.

    clojure an interesting mix of lisp (which includes many imperative constructs), pure-functional, concurrency, and jvm.

    • April 17th, 2008 at 07:11 | #4

      Thank you for your input. I don’t know much about the functional languages you mention, but for the imperative ones (javascript and ruby) they don’t have mechanisms to enforce “purely” functional constructs, and thus cannot take functional advantages like parallelism on a compiler level.
      But, maybe I should change my claim to: “Mixing pure functional into a main stream imperative language is bleeding-edge.”
      The other way around might have already been done, as you indicated, in languages like OCaml and F#. But I wouldn’t know anything about it.

  3. Daniel Yokomizo
    April 16th, 2008 at 14:11 | #5

    It’s great to see functional programming finally finding a place in D. In 2001/2002 when I was active in the D community I tried to convince Walter of the importance of functional programming, but I wasn’t too convincing (and the time wasn’t right). Recently I saw your posts on D and went to take a look on it. Now it seems to be huge, lots of features and not much language design. From your post it seems that FP will be added upon D, which isn’t the best solution but maybe results in something better than Java, C++ or C#.

    • April 17th, 2008 at 07:40 | #6

      I like the attempt to unite these two paradigms, but I, like you I guess, am not sure it’s the best solution.

  4. Sebastian
    April 16th, 2008 at 14:23 | #7

    anonymous, none of those mix functional with imperative in the sense that is meant in this article, as none of them offer any guarantees that the functional part really is functional.

  5. Michael
    April 16th, 2008 at 15:14 | #9

    I’m a systems programmer who hates C++ and really really wanted to embrace D, but my biggest problem with the language has bee nit’s complete lack of identity. Much like C++0x, it seems like nothing more than a hodge-podge of cutting-edge language-geek coolness mashed together and given a name. There’s just no coherency.

    I see the interest in functional semantics to be just more of the same… a language with no identity frantically embracing every interesting thing that comes along without any consideration for the final form of the beast.

    D is a capable language with some great marketing bullets, but it’s being managed like a toy language, and will suffer a similar fate unless some focus is provided.

    • Jamie
      April 16th, 2008 at 15:44 | #10

      What a load of sensationalist nonsense. It seems to have a pretty clear identity to me, it’s a systems language that aims to provide some high-level language features in the interests of productivity, but also lets you do low-level systems programming.

      Which feature is at odds with this identity? functional programming is being embraced because they believe it will make systems programming on multi-core and multi-processor systems easier.

      • rickhg12hs
        April 22nd, 2008 at 00:33 | #11

        “but also lets you do low-level systems programming”

        Not low enough. D can’t interpret Linux kernel header files so Linux kernel modules can’t be written in D and use the Linux kernel module build facility.

  6. April 16th, 2008 at 15:39 | #12

    If he really cares about concurrent programming how about fixing the stop-the-world mark-and-sweep GC that D currently employs?

    The D community needs to focus on fixing bugs in their runtime. You can’t adopt D for real-world usage. Every feature added makes the language less stable. The last chunk of features were all around meta-programming which contains so many bugs that it’s pretty much unusable.

  7. miguel rodriguez
    April 16th, 2008 at 17:09 | #13

    … and people say that C++ is a complicated language, come on, don’t enter in that world of complexity, if I want a complexity language I got C++

  8. databus
    April 16th, 2008 at 17:31 | #14

    Love it, can’t wait to use it.

    I’ve investigated D several times, but it’s never managed to sway me over from c and c++.

    I have an interest in functional languages, and these new features in D would tempt me into trying a few projects the language.

  9. goalieca
    April 16th, 2008 at 18:01 | #15

    I’ve seen “academic” languages with function annotations like “commutative” but I think “pure” would make a lot more sense. One of the goals of functional annotation is compiler optimization. Compilers are pretty good at optimization small sequences of code but whole program optimization remains elusive. I’m thinking things like automatic parallelization too!

  10. Marcus
    April 16th, 2008 at 19:40 | #16

    This reminds me a great deal about that talk Tim Sweeney had at some conference a few years back, http://www.scribd.com/doc/5687/The-Next-Mainstream-Programming-Language-A-Game-Developers-Perspective-by-Tim-Sweeney.

    Hopefully I’ll get the chance to use D in a real project some time in the near future.

  11. Erik
    April 17th, 2008 at 02:38 | #17

    D is merely trying to catch up to what OCaml and F# has already achieved.

    • April 17th, 2008 at 07:47 | #18

      That’s probably true, unfortunately I wouldn’t know anything about it (I haven’t had time to dig into those languages yet, probably will – F# seems promising) The difference (I’m guessing here) is that those are functional languages with an imperative subset, while D will be an imperative language with a functional subset.

  12. May 3rd, 2008 at 15:51 | #19

    Scala ( http://www.scala-lang.org ) is my poster child for hybrid FP/OOP. It’s been around as a research effort for a few years, but has gained considerable maturity and visibility in the past year or two. Although its syntax contains elements resembling dynamic languages (e.g. Python, Ruby, etc.) it uses compile-time type inference to achieve strong, static typing.

    It is implemented on the Java Virtual Machine, compiles to Java class files, and interoperates with Java code. Those facts explain the interest shown in Scala at “mainstream” conferences such as JavaPolis and JavaOne, as well as smaller-scale conferences such as the JavaPosse Roundup (both 2007 and 2008) and CodeMash. One of the best introductions to the language is the presentation by Martin Odersky (the father of Scala and a major player in the history of Java generics) at JavaPolis late in 2007 ( http://parleys.com/display/PARLEYS/Scala ) .

    In addition to the above, Microsoft supports full .Net “citizenship” for F# (their functional language based on OCaml). These facts persuade me that hybrid FP/OOP, which has been around for several years, is a serious alternative for real production development in the coming years.

  13. January 15th, 2010 at 16:52 | #20

    Perl allows one to mix imperative and functional techniques.

  1. May 20th, 2008 at 12:00 | #1