FAQ terminology harmonisation

classic Classic list List threaded Threaded
54 messages Options
123
Reply | Threaded
Open this post in threaded view
|

FAQ terminology harmonisation

Matthias Lang-2
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
 


Reply | Threaded
Open this post in threaded view
|

FAQ terminology harmonisation

Chris Pressey
On Tue, 1 Apr 2003 08:22:09 +0200
Matthias Lang <matthias> 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.

That's probably a better way to put it.

Re-reading the programming guidelines - they do put "defensive" in
quotes.  They also stress making code clearer by seperating the error
behaviour out.  So you could even use the term "micro-managed, inline
error handling" to describe the bad stuff.

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

It's never a good thing.  It's just that it's non-fatal here, for a
change.  I'd say "non-fatal crash" and avoid the TLA.

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

These two terms I had come across before I ever encountered Erlang.  I
see no reason to change them; even if they are academic, they're an
accepted part of the parlance.

Google for "single assignment": ~15,000
Google for "auto consting": 0

Google for "tail recursion": ~15,000
Google for "stack unrolling": 22

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

In the context of Erlang running under an operating system, OK.
In the context of Erlang running in an Erlang distribution, node is
still clearer.

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

'interface' better describes how it actually acts (but what is the
reasoning behind '-public'?  To me that says next to nothing.)

>   list: array. Everyone knows what an array is.

And people don't know what [linked] lists are?  :)

> Any further suggestions?
>
> Matthias
>  

-Chris


Reply | Threaded
Open this post in threaded view
|

FAQ terminology harmonisation

Björn Gustavsson-3
In reply to this post by Matthias Lang-2
Matthias Lang <matthias> writes:

> Hi,
>
[...]
>   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?

Actually, we think that Erlang being a functional language have
scared too many programmers, so we plan some radical changes.

The most significant change is that using the thread dictionary
(formerly known as the "process dictionary"), will no longer be
considered bad style.

To make the thread dictionary easier to use, we will add syntactic
sugar. Thus

        var := Expr

is syntactic sugar for

        put(var, Expr)

and in any expression

        *var

is syntantic sugar for

        get(var)

Although the ':=' is borrowed from Pascal rather than C, we still
think that C programmers will pick it up easily enough. Many C programmers
have used Turbo Pascal in the past.

put/2 and get/1 (or the syntatic sugar versions) will also be allowed
to be used in guards to extend the power of pattern matching.

We will of course also change the setelement/3 BIF to do a destructive
assignment. The syntactic sugar version will be

        array := Expr

The changes will be implemented in the R9D release, planned to be
released April 01, 2004.

/Bjorn

--
Bj?rn Gustavsson            Ericsson Utvecklings AB
bjorn      ?T2/UAB/F/P
                            BOX 1505
+46 8 727 56 87    125 25 ?lvsj?


Reply | Threaded
Open this post in threaded view
|

FAQ terminology harmonisation

Michał Ptaszek
In reply to this post by Matthias Lang-2
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





Reply | Threaded
Open this post in threaded view
|

FAQ terminology harmonisation

Mikael Karlsson
In reply to this post by Matthias Lang-2
Tue 01 april 2003  Matthias Lang wrote:
> Hi,
...
>   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.
>
..
> Any further suggestions?

To me a thread is lightweight, but also share context/memory with other
threads. That is not the case for Erlang processes.

/Mikael


Reply | Threaded
Open this post in threaded view
|

FAQ terminology harmonisation

Miguel Barreiro Paz-2
In reply to this post by Matthias Lang-2

        Ahm... is there a way to tell the erlang.org majordomo to postpone
that post until December 28 for us spanish users? :-)



Reply | Threaded
Open this post in threaded view
|

FAQ terminology harmonisation

Jonathan Coupe
In reply to this post by Matthias Lang-2

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

Doesn't the argument for using standard names apply just as much to
tail-recursion as to threads?

- Jonathan Coupe



Reply | Threaded
Open this post in threaded view
|

FAQ terminology harmonisation

Tony Rogvall-3
In reply to this post by Matthias Lang-2
Bjorn Gustavsson wrote:
> Matthias Lang <matthias> writes:
>

>
> Actually, we think that Erlang being a functional language have
> scared too many programmers, so we plan some radical changes.
>
Now you'r talking, I have always thought of the OTP team being a bit
conservative.

> The most significant change is that using the thread dictionary
> (formerly known as the "process dictionary"), will no longer be
> considered bad style.
>

But why wait a year for this release here is a working patch!!!

to patch just do:
  cd <otp-r9b-1-path>
  patch -p1 < otp_src_R9B-1.diff

enjoy

I implemented a feature in erl_eval that can be used from command line

   _ := expr        will band the expr to the current process
   and
   *_               will receive the first message in the queue

Perhaps some one could fix so the compiler will generate the code as well.

You can see a small example in vexpr.erl. We must add something to pass
variables as references to other functions i.e.

foo() ->
     X := 1,
     bar(&X).

bar(Y) ->
     Y := *Y + 1.  %% will update the instance of X!!!

Regards

/Tony


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: otp_src_R9B-1.diff
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20030401/17848bbc/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: vexpr.erl
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20030401/17848bbc/attachment-0001.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20030401/17848bbc/attachment.bin>

Reply | Threaded
Open this post in threaded view
|

FAQ terminology harmonisation

Vlad Dumitrescu-4
In reply to this post by Björn Gustavsson-3
From: "Bjorn Gustavsson" <bjorn>
> To make the thread dictionary easier to use, we will add syntactic
> sugar. Thus
>         var := Expr
> is syntactic sugar for
>         put(var, Expr)
> and in any expression
>         *var
> is syntantic sugar for
>         get(var)

Hi,

This is a most wonderful idea! What a world of possibilities suddenly opens!
I now realize that this is just what I had been expecting!

I hope this will be just one step on the way to making the language easily
accepted by all programmes in the world. The release after that (i.e the one
that will reach general audience April 1, 2005) should include some other
"most wanted" features:

- remove message passing, and use function calls instead
- introduce a new type of data, namely pointer, so that we can access C data
directly
- without messages, processes are quite useless, so skip them too
- make Erang hard-realtime, and remove garbage collection; replace it with
something like (I'm just improvising now) memory_alloc() and memory_free(),
or shorter malloc and free
- pattern matching is very awkward, I think it would be much cleaner to
define functions as for example foo(int x, string baz)

I could continue, but I have to catch my breath and put my thoughts in
order. Wow!
best regards,
Vlad


Reply | Threaded
Open this post in threaded view
|

FAQ terminology harmonisation

Marc van Woerkom-2
In reply to this post by Matthias Lang-2
> renamed it to "micro-managed error handling" to make the author's
> intent clearer.

You got me hooked for some minutes :)
Ah andI was already looking for such.

Regards,
Marc

PS Another one:

  http://www.javaperformancetuning.com/news/interview028.shtml



Reply | Threaded
Open this post in threaded view
|

FAQ terminology harmonisation

Ulf Wiger-4
In reply to this post by Björn Gustavsson-3
On 1 Apr 2003, Bjorn Gustavsson wrote:

>Actually, we think that Erlang being a functional language
>have scared too many programmers, so we plan some radical
>changes.

And about time too! I've suffered through 11 years of
traditional erlang programming waiting for this!


>The most significant change is that using the thread
>dictionary (formerly known as the "process dictionary"),
>will no longer be considered bad style.

Wonderful!


>To make the thread dictionary easier to use, we will add
>syntactic sugar. Thus
>
>        var := Expr
>
>is syntactic sugar for
>
>        put(var, Expr)
>
>and in any expression
>
>        *var
>
>is syntantic sugar for
>
>        get(var)
>
>Although the ':=' is borrowed from Pascal rather than C, we
>still think that C programmers will pick it up easily
>enough. Many C programmers have used Turbo Pascal in the
>past.

Ah, good old Turbo Pascal. The first programming tool I ever
owned...

Of course, since := and *var will be considered good style,
we could also spend some time optimizing the process (sorry
- thread) dictionary with the help of the compiler. The
compiler could recognize hard-coded process (darn - thread)
dictionary keys and represent them as real global variables.
This will allow use of the (uugh) thread dictionary without
any overhead, and we suddenly have true desctructive
assignment! (: (: (:

/Uffe
--
Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson AB, Connectivity and Control Nodes



Reply | Threaded
Open this post in threaded view
|

FAQ terminology harmonisation

Joe Williams-2
On Tue, 1 Apr 2003, Ulf Wiger wrote:

> On 1 Apr 2003, Bjorn Gustavsson wrote:
>
> >Actually, we think that Erlang being a functional language
> >have scared too many programmers, so we plan some radical
> >changes.
>
> And about time too! I've suffered through 11 years of
> traditional erlang programming waiting for this!


...

  Another improvement - which I've  long awaited is to remove send and
receive (since  they are redundant) -  the enclosed code  shows how to
send a message between two processes *without* using send and receive.

Here's a trace

1> c(send).
{ok,send}
12> send:demo(hello).
Sending :hello to <0.70.0>
<0.70.0>: received:hello

  Observe that no  send or receive is used  only the more intuitively
understandable method of remote polling of the process dictionary with
process_info(Pid, dictionary) -

  Unfortunately this code has a busy wait - so we'll have to ask Bj?rn and
co to add a few more primitives, probably

        on_put(Pid, Key, Fun)

meaning evaluate Fun() when Pid does put(Key, Val)

/Joe

----------- cut -----------------------

-module(send).

-compile(export_all).

demo(Term) ->
    Self = self(),
    Pid = spawn(fun() -> receiver(Self) end),
    io:format("Sending :~p to ~p~n",[Term, Pid]),
    new_send(Pid, Term),
    ok.
                     
new_send(Pid, Term) ->
    put({to,Pid}, Term).

receiver(From) ->
    Value = new_receive(From),
    io:format("~p: received:~p~n", [self(), Value]).

new_receive(Pid) ->
    {dictionary,D} = process_info(Pid, dictionary),
    case check_dictionary(self(), D) of
        {ok, Val} ->
            Val;
        error ->
            new_receive(Pid)
    end.

check_dictionary(S, [{{to,S},Term}|_]) ->
    {ok, Term};
check_dictionary(S, [_|T]) ->
    check_dictionary(S, T);
check_dictionary(S, []) ->
    error.

sleep(N) ->
    receive
        after N ->
                true
        end.

   



Reply | Threaded
Open this post in threaded view
|

FAQ terminology harmonisation

Chris Pressey
In reply to this post by Matthias Lang-2
On Tue, 1 Apr 2003 08:22:09 +0200
Matthias Lang <matthias> wrote:

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

Ah, well now that I've SLEPT on it, now that it's early this morning
rather than late nast night in my timezone, this makes PERFECT sense and
I withdraw all my previous objections.

Might I also say that I'm quite pleased to hear of Ericsson's decision
to hire Vin Diesel and Avril Lavigne as spokespersons for Open Source
Erlang.  At long last, this project will get the respect it deserves!

-Chris


Reply | Threaded
Open this post in threaded view
|

FAQ terminology harmonisation

Michał Ptaszek
In reply to this post by Michał Ptaszek
Hmm... I think I mentioned before that I'm utterly impervious to
embarassment! You got me. (-:

Pete.

Peter-Henry Mander wrote:
> Oh dear, I only just got used to the existing terminology! (-:
>




Reply | Threaded
Open this post in threaded view
|

FAQ terminology harmonisation

Matthias Lang-2
In reply to this post by Matthias Lang-2
Hi,

It's probably a reflection on my poor work/play ratio, but today has
been more fun that I've had for quite some time. Thanks to everyone
who fell for it gratiously, everyone who saw through it and kept quiet
and, best of all, those who picked up the ball and ran with
it. Destructive update indeed!

Cheers,

Matt



Reply | Threaded
Open this post in threaded view
|

FAQ terminology harmonisation

Martin Carlson-2
In reply to this post by Matthias Lang-2
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
>  



Reply | Threaded
Open this post in threaded view
|

FAQ terminology harmonisation

Joe Williams-2




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


Reply | Threaded
Open this post in threaded view
|

FAQ terminology harmonisation

John-Olof Bauner (KI/EAB)-2
Joe Armstrong wrote:

>  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.
>
And when the big Java/C++-project is delayed more people are thrown in
and the LM becomes an even bigger LM.

John-Olof




Reply | Threaded
Open this post in threaded view
|

FAQ terminology harmonisation

Marc van Woerkom-2
In reply to this post by Joe Williams-2
>     Todays article  (New great stuff from Nortel  programmed in Erlang)
>   in Computer Sweden is a good example ...

Is that available online?

Regards,
Marc


Reply | Threaded
Open this post in threaded view
|

FAQ terminology harmonisation

Joe Williams-2
On Wed, 2 Apr 2003, Marc Ernst Eddy van Woerkom wrote:

> >     Todays article  (New great stuff from Nortel  programmed in Erlang)
> >   in Computer Sweden is a good example ...
>
> Is that available online?

Try these ...

<li><a href="http://computersweden.idg.se/ArticlePages/200304/02/20030402081837_CS631/20030402081837_CS631.dbp.asp">Nortelsvenskar s?krar wlan (Computer sweden)</a>

<li><a href="http://www.unstrung.com/document.asp?doc_id=30481">
Nortel Preps 'Security Switch'</a>

<li><a href="http://www.nwfusion.com/news/2003/0331wwless.html">
Analysis: Nortel jumps into the wireless LAN market</a>

/Joe


>
> Regards,
> Marc
>



123