If I understand correctly the content of Functional Programming in Erlang is accessible for another two weeks, after that it is only available for those who have paid for an upgrade.
The three weeks of Concurrent Programming in Erlang will cover:
- Processes in Erlang
- Fault Tolerance in Erlang
- A “little bit” of OTP
Now in my estimation Functional Programming in Erlang should have benefitted any Elixir developer wishing to improve their handle on functional programming principles, in particular:
- Effective use of pattern matching (i.e. not just here and there - but everywhere)
- Effective use of body and tail recursion.
- Effective use of higher order functions, especially foldl/foldr, map, filter and related
The Erlang shouldn’t be a hurdle to anyone using the basics of Elixir - it may not feel as “nice” to some but to me Erlang has a very practical, “get stuff done” feel about it.
However don’t be fooled by the “5 hours per week for 3 weeks”. Doing that, you might as well be flipping through a magazine for all the good it does. You have to be prepared to do the exercises and assignments to get the maximum benefit and that is going to take a significant amount of time and effort.
Now there were repeated complaints that the exercises were not based on “real world examples” - but the exercises were chosen to maximize the density of problem solving opportunities for application of pattern matching, recursion and higher order functions. “Real world examples” would likely make the course even longer without necessarily covering more ground.
Granted, while I didn’t find the subject matter of the various exercises all that engaging, the functional programming problem solving going into the final “rock, paper, scissors” strategies implementation exercise ultimately was quite engaging.
To close off here are some choice quotes from Erlang Master Class 1: Video 8 - Discussion:
FRANCESCO CESARINI: And the six months, it’s not a learning curve. It’s more of an unlearning curve. So unlearning the object-oriented way of doing things.
FRANCESCO CESARINI :
-
The first hurdle is pattern matching.
-
The second hurdle is understanding recursion and the whole concept of tail recursion versus non-tail recursion.
-
And the third kind of hurdle is thinking concurrently.
JOE ARMSTRONG: And both of you, what do you think the best way to learn Erlang is?
SIMON THOMPSON: Practice. Practice. … You don’t learn to swim by reading a book about swimming. … things become easier the more you do them.
JOE ARMSTRONG: So once you’ve learnt Haskell, up to monads and things like that, it looks very much like Erlang. You just move the brackets around a bit. You take the brackets out, actually, and you move the commas, there’s less syntactic noise.
FRANCESCO CESARINI: I found Haskell and Erlang, at least when taught in university, is very complementary of each other as well. And my opinion is that any student taking a computer science degree should learn both.
FRANCESCO CESARINI: I mean, we use Erlang as the glue to handle the whole orchestration. And then we use Python, C, Julia. No not at all. It is actually language intended to act as a hub towards other languages. And Interfacer could be protocols. There could be a RESTful APIs or other programming languages. It’s ideal for that.
JOE ARMSTRONG: When I teach it, the students start asking where’s the debugger? And I say, well, there isn’t a debugger. Or there is a debugger, but no Erlang programmers use it. And they say, well, why’s that? And I say, well, because you don’t have variables that are changing under your feet that it’s difficult to reason about it. Once they’ve got a value, they’ve got the value forever, and they acquire it in one place, and therefore, you don’t need to track it.
FRANCESCO CESARINI: I would judge where not to use Erlang, I think two very distinct cases are, for example, number crunching, and your graphical interfaces, the libraries, are appalling.
JOE ARMSTRONG: So if you had to choose one strong point for Erlang, what would you say was its unique strong point?
FRANCESCO CESARINI: Massive concurrency. Orchestration. The fact that your systems behave in a predictable way under extreme heavy load, extreme heavy load under an extended period, or under extremely high peak load as well. You won’t get any degradation of throughput in your system.
