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.
