[erlang-questions] Teaching Erlang as part of a paper -- advice sought

[Fred Hebert]

I have found many of the lessons from the 1996 book (Concurrent Programmin
in ERLANG, by Armstrong, Virding, Wikström and Williams) to be pretty good
to teach the fundamentals of some concurrent and distributed computing. If I
recall correctly, the concurrent part showed how to use the basic Erlang
stuff (mailboxes, spawning processes, etc.).  It showed inter-process
communication through FSMs, the client-server model, etc.

The chapter about Distributed  Programming Techinques (ch. 11, p.258)
basically showed how to implement the rpc module, how to broadcast message,
lets the user implement the  'global' module, process groups (with leader
election), promises, how to attain basic redundancy with many nodes, basic
load distribution, etc.

The following chapter (Distributed Data, p.184) discusses how to handle
concurrency and data race conditions by using timestamps, clocks,
transactions, and so on.

I'm certainly not a professional of distributed computing nor a teacher. I
also know time is probably short if you do need to show the language to the
students (it took me a few months to write my guide on the very basics of
sequential Erlang). However, these parts of the book really showed what I
could consider core issues when building applications on top of a concurrent
or distributed system. Maybe showing students how a few of the standard
library modules are implemented would be something useful. It did seem to
work well in the book.

On Sun, Feb 7, 2010 at 6:14 PM, Richard O'Keefe <ok@REDACTED> wrote:

> 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
> data race.
>
> "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.
>
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>