Teaching Erlang as part of a paper -- advice sought
Mon Feb 8 00:14:45 CET 2010
This year I am in the happy position of teaching a paper on
concurrent programming. I propose to start by teaching Erlang,
as being by far the simplest concurrent programming language I
know (except possibly Occam, but while the restrictions in
Occam are _motivated_, they are still quite painful, and make
the language harder to use).
However, I've never actually _taught_ Erlang before.
These are 4th year students with Java and C. Last year in a
class at the same level one group did an assignment in Erlang
without needing to be taught.
Has anyone tried more than one Erlang book? What works well?
I propose to explain Erlang as
- take a minimal programming language (which means
pretty much lambda calculus)
- add a few simple data structures (integers, floats,
lists, tuples, atoms)
- add pattern matching
- add minimal support for concurrency
(processes and process IDs, !, receive)
- add support for large scale programming (modules)
- add support for practical programming (testing, debugging,
monitoring, most of which I don't plan to cover)
- add support for distribution
(nodes, unreliable messaging, timeouts, &c)
- add support for persistent data (might/might not mention)
but I'm really only interested in Erlang as a means to an end.
What I am *really* interested in is "how do we design and build
reliable concurrent systems". My use of Erlang for this paper is
purely pragmatic. I have considered and dismissed C (although
POSIX threads will make an appearance near the end, perhaps I
should call this "C THreads, Unsafe Libraries, and Hazardous
Undertakings" programming (:-)), C++, Cilk, OpenMP (although I
think I do have to mention it), Ada (lots going for it including
SPARK/Ada, but I'd have to spend more time teaching Ada than Erlang),
Limbo, Go, Concurrent ML, Haskell, Occam, various Scheme dialects,
Java, and C# amongst others. I believe Erlang will get them writing
working concurrent code sooner than any of the others.
Here there is a dispute between me and one of the other lecturers
in the department, who will not be involved in this paper, at least
not this year. I want the students to start learning about
concurrent programming in a language in which data races (at least
data races not involving external resources) are simply impossible.
He thinks they should (a) learn what a data race looks like the hard
way early on and (b) learn not be be afraid of data races, because
the low level locking code on x86-64 Linux apparently has a benign
"How do we design and build reliable concurrent systems" is obviously
an opportunity to exploit some of the hard thinking that went into
Erlang/OTP and teach the "behaviours", although the first "design
pattern" I want to teach is acyclic networks of pipes. The question is
"how do we look at a problem and see the concurrency there", and if
anyone has any recommendations I'd be very pleased to get them.
A *huge* thank you to Joe Armstrong and the Erlang/OTP team for
all their work.
More information about the erlang-questions