This content has moved to pzel.name

Bits of Erlang, alpha release

An experiment in Socratic education

education tutorial erlang

Long ago in 2015, at LambdaCon in Bologna, I gave a hands-on workshop titled An Introduction to Erlang/OTP. It was, in truth, a largely improvised code-jam around four fundamental Erlang concepts:

  1. Concurrency
  2. Process isolation
  3. Message passing
  4. Error propagation

I extracted these four from Joe Armstrong's PhD thesis, as I felt they were the most salient characteristics of the language and platform.

The code-jam idea seemed sound, and promised some engagement from a live audience, so I gave it one more go at the Erlang Solutions office in Krakow, when we received a visit from a CS Student organization from Holland. They seemed to like it.

The follow-up plan was to publish the code-jam and tutorial for the benefit of the original workshop attendees, the students, and anyone interested in Erlang, but a laptop change or two resulted in all the code getting lost.

I decided against recording a screencast, sharing the belief that the future of education is plain text. The Socratic approach taken by the authors of the Little Schemer series of books seemed like a good compromise between interactivity and static textuality.

After two years of messing around, I'm releasing what I have. I humbly ask for constructive feedback and suggestions.

Click here for the tutorial:
Bits of Erlang, chapter 1: Concurrency

Open questions

I'm simply releasing what I have so far, but many questions remain:

  1. Is plain Erlang shell syntax the way to go? The whole F = fun F() -> dance, along with single-use variables, and the need to quit and reopen the shell, makes the exercise rather painful in the long run.

  2. If we go with compiled Erlang modules, we'll have to explain the boilerplate: -export()s, c()ompiling code, and having to edit the code in a separate environment from the shell itself. This is how I did the live-coding.

  3. We could just go with Elixir, but then we face the problem of having to include module definitions everywhere, which obfuscates the essentials. There may be an elegant way of handling this.

  4. Should the whole thing be slower-paced? There is basically no explanation of Erlang syntax.. Perhaps a chapter 0, introducing syntax and basic data structures (lists, tuples, atoms, numbers) is in order?

If you have any thoughts on these or other concerns, please reach out to me via email.