FAQ terminology harmonisation

[Peter-Henry Mander]

Oh dear, I only just got used to the existing terminology! (-:



Matthias Lang wrote:
> Hi,
> 
> Recently, there was some confusion on the list about the meaning of
> "Defensive Programming" in the context of Erlang. For most
> programmers, defensive programming is a good thing, yet in the Erlang
> programming guidelines it is considered a bad thing. Therefore I've
> renamed it to "micro-managed error handling" to make the author's
> intent clearer. While doing that, I also tackled a number of similar
> problems:
> 
>   crash: again, in most languages crashing is bad whereas in Erlang it
>          confusingly enough becomes a good thing. The FAQ now refers
> 	 to such events as "inter-process exceptions (IPEs)"

... or just call them exceptions, IPE is just another TLA, and besides, 
should it not be called "inter-thread exceptions" according to what follows?

>   single-assignment: is a very academic term for what most people
>          would call "const" variables. I have coined the replacement
> 	 term "auto-consting".

... or just const, C++ programmers can relate to this concept. 
Single-assignment may be an academic term, but it is an exact description.

>   tail-recursion: very powerful feature. Ridiculously academic name.
>          Now called stack-unrolling.

I agree, stack unrolling describes what is going on here. If only other 
languages did this, it would make things a lot more legible. It's not 
difficult to do or understand after all!

>   process: thread. An process is very lightweight. The rest of the
>         world refers to lightweight processes as threads. So does the
> 	Erlang FAQ from now on.

See above about "inter-process exceptions (tm)"

>   node: process. An Erlang node is always an OS process. So we may as
>          well call a spade a spade. "process" now means "erlang node".

Hmm... I feel the term "node" is less generic than "process" which is 
used/abused everywhere, and reusing an existing term for a different 
meaning can only be confusing.

>   behaviour: interface. In R9B-2, the directive '-public(gen_server).'
>          is a synonym for '-behaviour'. In R10, the -behaviour
> 	 directive will elicit a warning. By R11 an error.
> 
>   list: array. Everyone knows what an array is. 

Yes, but a list is not an array. For one, Erlang lists don't encourage 
the use of indexes. And arrays don't lend themselves to [Head|Tail] 
manipulation in any other language I know. I would personally stick to 
"list".


> Any further suggestions?
> 
> Matthias