The Erlang Rationale (PDF)

[AstonJ]

This is a 12 page booklet/pdf from @rvirding, and here’s a post he wrote about it on (from EF):

One reason I wrote this article was to try and correct a very serious error we made when we developed Erlang. We never really tried to describe and document WHY things look like they do in Erlang. So we wrote manuals and books which described the language and how you use it, but nowhere did we write a rationale for Erlang.

One reason for this was that for most of the things in the language, semantics and syntax we (Joe, Mike and myself) had discussed and argued back and forth about and the problems they were trying to solve and how they should be solved that we thought it was self evident and didn’t need describing. Duh! Of course you do it this way, it is self evident that this is the way you do it. Why would do it any other way?

This led to some interesting things and discussions I had with people about Erlang. So I don’t know if you have noticed it or reflected over it and that is that in the concurrency model and error handling is asynchronous. Everything. And this is by design and not by chance. Many people, even experienced programmers and system development, never realised this until I pointed it out to them and then they saw it. “Yes it is isn’t it”.

This led to one interesting change in the language. Originally the BIF link/1 was asynchronous in that if you tried to link to a dead process through its pid then you would an asynchronous noproc exit signal telling you the process didn’t exist. Someone, who was trying to be helpful but hadn’t seen the whole picture, didn’t like this and “fixed” so it sometimes generated the signal and sometimes generated an error. So now it was no longer asynchronous and no longer consistent.

My final point here is that when you designed and implemented something you not only described what it does and how to use it, you should describe WHY it works in the way it does and not in some other way. If nothing else it will help those who use it to better understand it and to use it in a better way.

The_Erlang_Rationale.pdf

Related: Robert’s interview here is worth checking out too - he talks about the Erlang Rationale and quite a bit more

[wallace]

I can’t get access to Google Drive in China. sad~~ Is this article available anywhere else ?

[AstonJ]

I’ve uploaded a copy to the forum for you, please let me know when you’ve downloaded it and I’ll remove it

[wallace]

I have downloaded it, thank you very much !

[wallace]

Wonderful article ! Here are something that impressed me:

The reason why Port is designed as a different term from Pid.

We finally decided to make them a separate data type as we felt that
there could be times when it might be necessary to be able to detect if we were
communicating with a process or a port

And the fact that Erlang has no variable scoping (which I didn’t realize)

One of the things which Erlang inherited from its Prolog beginnings was its variable
scoping, or rather lack of variable scoping.

Actually I like the lacking of variable scoping. I know fun expression and list comprehension can create scope inside function, which make things a little bit non-consistent.

But compared to other languages, who have let, {}, begin...end for creating sub-scoping, Erlang is still much simpler as function is the only way to create a scope.

(I always consider list comprehension as a plugin-feature of a language because they look so different and I rarely use it in my code)

[phild]

@wallace

(I always consider list comprehension as a plugin-feature of a language because they look so different and I rarely use it in my code)

I learned how to use list comprehensions as a side effect of learning how to use the qlc module to simplify Mnesia queries. I then realised I could reapply this knowledge to Python.

[wallace]

Yes ~ List comprehension is indeed convenient and useful, but I just can’t enjoy the idea. I mean, recursion is a beautiful idea, while list comprehension is not. I use qlc when manipulating Mnesia, but I can’t say I like it, it more like there is no better choice so I have to use it.