FAQ terminology harmonisation

[martin j logan]

All, 
    This thread has yielded quite a discussion. I must admit that I
became quite sick reading Bjorns email proposing pointer syntax and
destructive assignment, I did not catch the joke until I read further -
scary.  While some of the suggestions about "nice-ing up" Erlang
terminology might not sit well with most people on this list, I think
the idea of making Erlang terminology intelligible and accessible to
managers and the like is an issue that needs to be addressed. I know
that all of the people on this list love the language the way it is and
would like to see it spread. I also know what it is like to try to sell
a C/C++ shop's management, and engineers for that matter, on something
new like Erlang. This task is made more difficult when things like,
letting processes crash being a good thing, are mentioned. It is
difficult for them to wrap their minds, addled by years of C/C++
programming:) around "not being defensive, just letting it crash, and
spawn 20 thousand processes". This difficulty is compounded with those
phrases are thrown in the mix with dynamic typing, run time code reload,
and location transparency. Most of the time people look at you like you
have been smoking something! Am I wrong here??? I don't think that we
should compromise the basic foundations of the language. Erlang is
functional, concurrent, a process is a process, a list is a list, and a
node is a erlang virtual machine:) I just think that we should not be
shy away from well chosen euphemisms - they should an important part of
every would-be Erlang salesman's life. 

Here is how the other ninety nine and one half sees it:

1. Crashing is a great way to handle errors ==C++== seg faults on
purpose.

2. 20000 processes ==average UNIX guy== real slow

3. don't be defensive ==Most other languages== sloppy incomplete error
checking 
 
4. Dynamic typing combined with "don't be defensive" ==Most static
typing theory junkies== just can't work.

5. Run time code reload on top of all of this gets you disbelieving
looks and you are dismissed as being a crackpot:)

This is not the way to sell something. I am not suggesting that we
compromise what Erlang is, that would be a worse mistake than being bad
sales people. I am saying that we get used to saying things in a more
marketing friendly way. 

Example:

Erlang allows the programmer easily generate exceptions when a process
gets into a bad state, these exceptions can be simply used to "reset the
state of a process" instead of crashing the application.

ok = demo:do() 

allows state to be reset if demo:do were to return 'error'. The process
is then immediately ready to do work again. This makes programming
customers applications much easier and the apps themselves much more
robust. The beauty is that it is all built in, saving you development
time and headache - more ROI. 

Just an idea maybe over the top - a bit:) but I think that saying things
in a "nice" way needs to be contemplated. 

My 2 cents,
Martin 

   
 
On Tue, 2003-04-01 at 00:22, 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)"
> 
>   single-assignment: is a very academic term for what most people
>          would call "const" variables. I have coined the replacement
> 	 term "auto-consting".
> 
>   tail-recursion: very powerful feature. Ridiculously academic name.
>          Now called stack-unrolling.
> 
>   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.
> 
>   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".
> 
>   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. 
> 
> Any further suggestions?
> 
> Matthias
>