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

[Anthony Molinaro]

Hi Richard,

   I'm not an instructor but am currently almost done reading Erlang
Programming, and read Programming Erlang: Software for a Concurrent
World when it was released.  So given that I've read both, I would
probably recommend Erlang Programming as a course book.  Joe's book
was a great introduction to the language, while Erlang Programming
seems to be much more geared towards building applications for
production systems.   There are often asides which describe the
runtime system (how reductions work, ways to inspect processes,
resource usages, etc), and examples and exercies follow a nice
progression from sequential to concurrent, to process design patterns.
Also, hot code loading, tracing and debugging, and unit testing each
have their own chapters.  Many of these topics are touched on in
Programming Erlang, but the treatment in Erlang Programming is
more in depth.

Regardless both books are great, many thanks to Joe, Francesco and Simon.

Hopefully that helps some,

-Anthony


On Mon, Feb 08, 2010 at 12:14:45PM +1300, Richard O'Keefe 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
> 

-- 
------------------------------------------------------------------------
Anthony Molinaro                           <anthonym@REDACTED>