FAQ terminology harmonisation

[Joe Armstrong]

On 1 Apr 2003, martin j logan wrote:

> 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. 

  I think  you're both right and wrong  here - it depends  who you are
selling.

  The sales pitch has to be two dimensional, i.e.

	Problem X Person

  To start with the problem domain  has to be suitable for Erlang - so
I spend  a great deal  of time listening  to what peoples  problem are
before recommending Erlang - often I recommend C - or even visual basic.

  You have to ask the question:  What is Erlang good at? - the answer
is not  *everything* - the answer  is that it is  good at distribution
and fault-tolerant stuff - it's  not good at sequential "poking around
in memory" stuff ...

  Then there  is the person - the  augment directed to a  "suit" or "a
unix guy" or "a java person" are just not the same.

  "suits" need special treatment ... (two sub-categories of suit are
VC (venture capitalist) and "LM" Line management

  If  I'm selling  to "VC"  I always  use the  "MAKE MORE  MONEY FAST"
argument - I present them with good hard evidence that Erlang projects
have a higher chance of succeeding than non-Erlang projects.

  "VC" are  more likely to  take risks, so  they like this  argument -
though they will press hard on details.

  The main objection of the "LM" is that "Erlang in not Java/C++" - if
they allow  Erlang they  are often  taking a big  personal risk  - they
actual stand to gain if they have large development teams and everything
takes a  long time  - their pay  = LengthOfTimeOFPROJECT X  #people in
project - so Erlang is a no no here.

  Selling to programmers is different - getting the "Early adopters is
easy" they *like* new stuff - it's the mainstream that's the problem -
they want "lots  of stuff for free" - they think  "Oh dear, their's no
GUI -  so I can't  use Erlang" -  the early adopters think  "Oh great,
their's no GUI - I'll write one myself ..."

  Arguments  have  to be  *careful*  matched  against  the Problem  X
Mindset of the  person you are trying to sell Erlang  to - if anything
the trend  is towards economic  rather than technical  arguments which
indicates a movement towards the main stream ...

  What does bite  are "statement by other people"  - press releases by
Nortel and  Ericsson where they say  "Erlang is great"  have much more
credibility  than anything  we  can say.  Unfortunately big  companies
don't usually  make a big deal  of "the technology  inside" (apart from
Intel) - since non of their customers actually care what's inside.

  Todays article  (New great stuff from Nortel  programmed in Erlang)
in Computer Sweden is a good example ...

  I still think the best method is "success stories" ...

  /Joe

 
> 
> 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
> >   
>