Erlang is a full blown “pure” functional programming language strongly oriented towards concurrent programming.

Apart from the powerful and very expressive clause-oriented syntactic constructs used to define functions, Erlang retains nothing from the declarative aspects usually associated with the family of logic programming languages ; there is no backtacking mechanism, nor unification operator.

Indeed, Erlang native and powerful “match” operator is best described as a “binding” operator (tree-binding) that Lisp lovers have long known as the “let” construct.

There is no set, setq, or equivalent, and therefore no assignment operator per se : once bound, the value of an Erlang variable cannot be changed.

Along with message passing, this is precisely what makes Erlang so safe and easy to use for concurrent programming (ok, once the programmer has forgotten about idiosyncratic iterative constructs and acquainted himself with the more robust functional approach) : no shared memory, no shared state, and therefore no need for lock or semaphone.

Sort of parallel programming made easy !

As emphasized by Douglas, despite its roots in Telecom, Erlang should be seen as a general programming language and a platform of choice for today’s concurrent programming.

My feeling is that wide and successful Erlang adoption lies first of all in helping developpers to realize how easy the shift from iterative programming (OO or not) to functional programming.

Franck PORCHER, Ph.D.
fporcher@smartech.pf

In term of efficiency, you do have lock as a process cannot deal with the following message until it has finished with the previous one. You lose time as well in process switching and because each process has first to find to which information the message it received applies to.

However, one shouldn’t confuse a good runtime with the language built on top of it. The latter is mostly syntax and for skilled programmers, syntax is just religion ;-) Furthermore, one can build many different languages on top of the same runtime, which also can enable interoperation of the different languages’ data structures, and please the expert programmers who are particular about the syntax they use. The nonexpert programmers (who are primarily domain experts and not hackers) shouldn’t have to care about the syntax — they only want to “get things done” and are willing to endure any arcane and annoying syntax in order to have libraries that let them solve their problems with a minimum of coding time. (Perl, COBOL, APL, …)

Building a good runtime is hard and not as attractive for marketing as making a new language, hence it’s not done very much. Often the groups that do make an investment in a runtime do it to solve internal problems (e.g., “How do we support the current ecosystem of multiple development languages, while sharing common system and debugging facilities?”) which shouldn’t be visible to ordinary programmers. However, the really interesting features for parallelism and concurrency (e.g., load balancing, parallel garbage collection, reliability, debug traces, software transactional memory) are all in the runtime.

I was co-author on a functional programming language (called “Flo”) for a company called Floating-Point Systems in the mid-80′s and co-author on the CRAFT Fortran extensions for Cray Research in the mid-90′s. Both languages were designed with the HPC community in mind, both had the full support of the companies involved, both had many person-years of effort behind them, and both were received enthusiastically by their community, at least for a while. Neither language lasted more than a few years and reasons cited for their demise were never technical merit.

Another functional programming language, Sisal, also experienced a similar fate. Many years of effort were poured into its implementation, a community at Lawrence Livermore National Lab used the language (at least apparently) with enthusiasm. High Performance Fortran (HPF) also rose and fell, as have many others.

Having a high-quality language, compiler and runtime environment with all the necessary tools for support, at least in each of these cases seemed to be a necessary condition but by itself it was not sufficient. It also had to somehow be accessible over a wide range of architectures and a long enough period of time to develop the programming skills necessary for wide-spread adoption. It needed to be taught in Universities and it needed to be perceived as something that would be around for a long enough time that substantial SW development in that language would not be perceived as money wasted.

I’m not saying this to dismiss Erlang – quite the opposite. I don’t know whether Erlang is the answer to our parallel programming needs or not, but I do know intimately the requirements of parallel programming and the merits of functional languages and Erlang sounds like it has potential.

If we assume that Erlang is the right combination of features and implementation, my question would be how do we make sure it doesn’t fail for some of these non-technical reasons? How do we make it happen? “Build it and they will come” is just wishful thinking.

When C came out it played in a different space than Fortran, but as it gained popularity eventually it needed to play nicely with Fortran. C++ was inherently compatible with C from the start. Java can interoperate with C/C++ and (even) Fortran.

There is a huge mass of existing software that, frankly, the community cannot afford to rewrite just because the language is different. Much of the software is potentially compatible, at least in concept, with functional programming ideals. For example, there are many algebraic functions such as SQRT, SIN, COS and such, that could be interlaced with Erlang relatively easily. On the other hand, much of the existing software deals with access to hardware and hardware inherently manages state, which is more of a problem for functional languages.

However this junction is managed, it seems clear that Erlang cannot simply live in its own world. Somehow it needs to play nicely in the sandbox with other software. Maybe it does already, I don’t know. Could someone who knows Erlang comment on this? (Dr. Eadline?)

Douglas Pase, PhD
douglas@pase.us

http://www.erlang.org/doc/apps/mnesia/index.html