Erlang white paper: http://www.erlang.org/white_paper.html

It is based around the concept of processes that communicate by passing messages to each-other. So while each process acts like a program in a functional language, there is some overall system state defined by the message queues of the processes.

It includes a lot of other features to support fault-tolerance, transparently accessing processes on distributed nodes, and dynamic code updates. Mostly features that are useful in distributed systems that must respond to many parallel queries.

In response to the comment by Cleo Saulnier above, Erlang is well-adapted to multi-core programming. Program logic is defined in a functional style, and the interpreter provides the “glue” that is necessary to communicate data between different CPUs, perform load-balancing, etc.

I am also surprised by Cleo’s comment that, “none [of the FP principals] are taught in any school or university.” I know at least two universities, Waterloo and MIT, that offer introductory CS courses in Scheme and provide an overview of FP in the process.

As to the differences, FP does have an execution point while data flow does not. It’s just that it’s very difficult to see because ALL data ALWAYS has an execution point in FP. Because there is a one to one relationship between data and their transformation, you can control execution via its associated data relationships. If one does not know better, they would think there’s no execution and that this is the best you can get. Unfortunately, the way functions are used, it cannot send data and leave it there for another ‘entity’ to do something with it. I call this a side-effect, but there are some that believe otherwise because it only affects an external system. A view I cannot agree with. Yet, this leaving behind of data is the prime requirement for distributed computing. Note that FP is fine for distributed delegation though.

So what is the difference in Map/Reduce? With the data flow mechanism, you can input data at any time from any source. The data flow network cares not where the data comes from. To be pure FP, you cannot do this. You need all the data before you can map it. So that’s why you have lazy lists and monads and all sorts of extensions to make these things fit more closely to the FP paradigm. Some people believe that these things are in fact FP. I do not because you have internal state changes. In any case, no matter what you call it, there are things going on that are no different than imperative or data flow when it comes to communicating with the external world.

As regards (a), things are Not That Bad. Take a look at the language shootout numbers (grain of salt and all that), which show that OCaml, SML, and Haskell are all in the “reasonable” range between C and Java. If you go functional, you pay a small price in performance and a moderate price in coping with the static type system (and, in Haskell, a steep price in learning how to use monads to manage side effects) which yields a large savings in not having to debug crazy runtime errors (memory leaks, use-after-free, null pointers, etc.)

(b) is really a chicken-egg problem which won’t get solved until a big corporation steps up and wills the ecosystem into existence. This may be happening right now with F#, which is a first-class citizen of the .NET kingdom. (Although the monarch of .NET is OOP, so F# may, in the end, gain the ecosystem, but lose its (functional) soul.)

Also, have you ever heard of a language called Prograph. Instead of writing code, a program was specified as a dataflow diagram, with data flowing along directed edges between nodes representing operations. Operations could execute whenever all of their data was available, and execution order was unspecified - the whole thing was inherently parallelizable (provided you had a suitable algorithm), and once you got the hang of it, programmers could be very productive. Sadly, there are no current interpreters/compilers, but back in the day Prograph CPX was a fantastic development environment to work with.

And your comment There seems to be a divide between academic, algorithmically-oriented programming and “real world” programming sparked an idea. I was thinking that the distinction between “real world” and “academic” carries a lot of unnecessary baggage, and despite being somewhat convenient, obscures deeper issues. Perhaps one cloud classify programming into three broad modes (bear with me a moment, please):

1) algorithmic - the raw manipulation of data is mathematical ways
2) conversational - the storage, retrieval, and transmission of data involving only basic manipulation
3) arbitrary - modeling external processes which where never designed to be algorithmic

In my daily work (I build “enterprise” applications, typically for large companies) 90% of what I face is conversational and arbitrary - moving data between systems with essentially straightforward syntax transformations, and following business processes which were never meant to be rational (as an engineer or mathematician understands “rational”).

“Academic” software probably tends to be more algorithmic and conversational, since there is little that is intellectually interesting and rewarding in arbitrary software. Yet many other “real world” programmers also build software which is at its core highly algorithmic, and merely wrapped in arbitrary or conversational wrapper. So Google’s MapReduce would fall into this case, as would Photoshop plugins, industrial optimization software, and so on. This sounds like what your work involves as well.

Anyhow, I may have to take a look at OCaml. It sounds like it might allow you to use FP approach for the algorithmic portions of your code, while using more imperative techniques for the rest.

And to John: I have never said I did not understand FP. There’s nothing in that paper or about FP that is even remotely foreign to me. What I’ve said about FP is that it’s an inconsistant system that cannot interact with external systems without breaking its own rules. For that reason, FP has serious limitations and is useless for the future of multiprocessing. This is the ‘glue’ code that most real life programmers need. FP doesn’t provide it. And it’s simple to see why if you understand the underlying principles… of these, none are taught in any school or university.

For something that is supposed to be simple, the terminology is left open-ended so that credit can be taken when it’s not appropriate to do so. Map/Reduce being the biggest example.

I’m not saying these things to be contentious either. It’s because there are too many programmers attached to a certain PL or programming system. Why is this? I do not care what I use just as long as it works. So I’m pointing out what’s really going on. On my blog, I get too many that think I’m emotionally caught up. I have no idea where this comes from because I dislike all languages equally. I use what works. Show me that it works regardless of terminology and I’ll use it. Otherwise, in /dev/null it goes. Guess where FP is.

The consensus of the FP community is pretty much the opposite: that “pure” FP makes 90% of your work easier (and safer), while making things like I/O much harder. If your project is 90% I/O (and many projects are!), your experience will differ.

There seems to be a divide between academic, algorithmically-oriented programming and “real world” programming, where it seems most development effort is spent writing “glue” between pre-existing systems. The assumption seems to be that this “glue” is always ugly and non-algorithmic, and consistently resists any attempts at generalization and elegance.

I have no idea if this is true and I’m not going to wave my hands and pretend otherwise. But I suspect there will always be a place for C programming (at the systems level) and Perl programming (at the shell level), even as more and more programmers move to higher-level and FP-ish languages.

OK, I’ll bite. First of all, I must note: I am an academic, so my experience is not indicative of software engineering “in the trenches.”

I love FP. I program almost every day in OCaml, a primarily-functional mixed-paradigm language descended from ML. The nice thing about OCaml is it gives you access to the things about FP that make it nice and fun, while giving you recourse to imperative features (mutable variables) and an object system where necessary.

But of course it is exactly its these features that make OCaml non-”functional”, in the sense that Backus is advocating. What he seems primarily concerned with is “equational reasoning” and “referential transparency“: the desire to reason about and manipulate a program definition as if it were an algebraic entity. The only significant language I know of that supports “pure” FP in this sense is Haskell and its industrial adoption is close to (if not precisely) nil.

The main complaints I hear about FP in practice are not that it is impenetrable (it can be, but the combinatory style that Backus uses is discouraged; it is possible to give intermediate values names without introducing mutable variables!), but that:

(1) It is too abstract, in the sense that it can be hard to imagine the performance characteristics of the generated code from looking at the source. E.g., in OCaml, it is important to understand tail recursion if you don’t want your algorithms to crap out on large data structures. In Haskell, due to lazy evaluation, there are subtle ways to make the memory usage of a program explode (and one of those ways, it seems, is to use tail recursion!). In contrast, even in Java, the translation from source code to bytecode is straight-forward enough for the programmer to understand and reason about directly.

(2) Massaging a program through the type system is challenging. For one, the inferring type systems give bizarre and unhelpful error messages. For another, the subtle ways that modules and objects (in OCaml), type classes and monads (in Haskell), and parametric polymorphism (in both) interact is very difficult to learn and master. The payoff is you completely eliminate a broad class of runtime type errors (anything to do with pointers, or downcasting in Java).

The features that Neel listed as having trickled from FP to the mainstream—”garbage collection, type inference, parametric polymorphism (aka Java generics), first-class functions, list comprehensions”—none of these have much or anything to do with functional programming at all! (First-class functions are necessary, but not sufficient, to make a language “functional”.) These are just advanced language features that appeared first in the FP community for exactly the reason Neel cited: FP is where cutting edge language research happens.

P.S. For an even more dramatic example of the migration of PL ideas into practice, see Microsoft’s LINQ language. Its creator spent more than a decade hacking on Haskell. See also here for an article on OCaml’s use in the finance industry.

P.P.S. What’s with the no comment preview? I’m pretty sure this is going to be typo-rific.