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

[Joe Armstrong]

Hi Richard,

Error detection and recovery seems to be conspicuously absent from your list.

I often think the way we do errors is the most misunderstood part of Erlang.

If you have a system with large numbers of small processes, having a
few die is no
big deal. All you do is detect these errors *somewhere else* and let
the process that detects the
error perform the corrective action. "Somewhere else" being on a
physically different machine
is the basis for building fault-tolerant systems.

In sequential languages error avoidance is a huge deal - if you have
only one process and
it crashes you are are screwed. Thus in C, avoiding errors is an
enormous deal. The entire
school of "defensive programming" comes from the idea that if you only
have one process
you'd better take enormous steps to make sure it doesn't crash.

Not so in Erlang.

The notion of an error-detection mechanism that works across machine
boundaries is the key
idea in Erlang. link/spawn_link/trap_errors/monitor does the magic stuff.

I think this point should be hammered home early and often.

     "To build a fault-tolerant system you need at least two machines"
     "Let it crash"

/Joe




On Mon, Feb 8, 2010 at 12:14 AM, 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
>
>