Erlang's Creator Speaks About Its History and Prospects 48
Seal writes "Erlang, originally created at Ericsson in 1986, is a functional programming language which was released as open source around 10 years ago and flourished ever since. In this Q&A, Erlang creator Joe Armstrong talks about its beginnings as a control program for a telephone exchange, its flexibility and its modern day usage in open source programs. 'In the Erlang world we have over twenty years of experience with designing and implementing parallel algorithms. What we lose in sequential processing speed we win back in parallel performance and fault-tolerance,' Armstrong said. He also mentions how multi-core processors pushed the development of Erlang and the advantages of hot swapping."
The power behind CouchDB (Score:5, Interesting)
I notice that CouchDB [apache.org] makes a big deal of its Erlang based core -- essentially "this part is trustworthy and parallelises well because it's in Erlang".
I also notice Joe Armstrong (or more likely a transcriber) is as bad at spelling "lose" as the rest of the internet...
CSP makes parallel programming easy (Score:5, Interesting)
Describing Erlang as a functional language is true, but misleading. It's not a pure functional language, because there is a (mutable) process dictionary. When you call something a functional language, it implies a language modelled on Lambda Calculus. The fact that functional languages do not allow side effects (Erlang does via the process dictionary) means that they are relatively easy to parallelise implicitly. Erlang adds support for the Communicating Sequential Processes (CSP) formalism on top of a mostly-functional core language.
CSP is a very clean and simple model for describing parallel algorithms. The language enforces the restriction that no data may be both shared and mutable. The only mutable object in Erlang is the processes (which has a dictionary and some execution state). Everything else is immutable. This makes it trivially easy to write code that uses a few tens of thousands of Erlang processes (or more). These are implemented as (very) light-weight threads on top of OS threads and can easily scale up to a large number of processors, or even cluster nodes. The asynchronous aspect of the message passing means that it is not very difficult to write code that scales well across a cluster; bandwidth can be an issue, but latency generally isn't in asynchronous code.
Re:CSP makes parallel programming easy (Score:3, Interesting)
the pure functional language Haskell
<nitpick>
Calling Haskell a "pure functional language" is a bit like calling C++ a "pure object-oriented language." There are parts of the Haskell language that allow you to do pure functional programming. But there are parts of the language that allow you to do things like I/O, too.
</nitpick>
Re:CSP makes parallel programming easy (Score:4, Interesting)
The analogy would be to call C a "low level language" even though C++ exists with high level extensions like the template system.
What makes Haskell pure is that stateful code like I/O is handled through a monad so that it doesn't leak out into the rest of the code. The purpose of a computer program is to create a side effect. So every language needs to include some capacity to induce them. What separates pure from impure is whether side effects are scattered throughout the code or isolated.
Programming Erlang (Score:4, Interesting)
I've been (slowly) working my way through Programming Erlang [slashdot.org].
I spend most of my day doing procedural and OOP. Odds are good that I'll never write a single Erlang program after I finish the book. But I guarantee that I'll be using the concepts that I'm learning for the rest of my life.
For the same reason you had to take liberal arts classes in university, everybody should learn a functional language or two.
Re:CSP makes parallel programming easy (Score:3, Interesting)
The purpose of a computer program is to create a side effect.
Back in the good old days, Haskell programs had type String -> String ;-)