FAQ terminology harmonisation

[martin j logan]

On Wed, 2003-04-02 at 03:58, Joe Armstrong wrote:
> 
> 
> 
> 
> 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.
> 
I agree. 


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

This is the place we need to sell the hardest. Erlang needs to shine
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 ...
> 

The thing is, erlang is a wonderful tool for capitalizing on economic
opportunities. Rapid Development, high ROI, low maintenance... The list
goes on. How do we position ourselves/Erlang?? How does Erlang 
capitalize??

>   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, I fully agree with you on this one. 
I think that one way to have more of these would be to sell the "LM".
> 

Cheers,
Martin

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