FAQ terminology harmonisation

[Rick Pettit]

On Wed, Apr 02, 2003 at 02:47:40PM -0600, martin j logan wrote:
>
> Perhaps I can clarify my little ==<other types of people>== bit here. 
> 
> When explaining how things are done in Erlang is is often said that "you
> should not explicitly handle errors just let the process crash". When a
> person used to programming in C or C++ hears that they often think
> crash/segfault that can't ever be good. Stating that "letting a process
> crash in lieu of handling an error explicitly" is a good thing is not
> the best way to present the supervision feature of OTP/Erlang to
> non-erlangers. 

Agreed. Chris cleared this silly misunderstanding up for me.

> We talk about spawning processes very casually when explaining Erlang. I
> know the look that I get when I say "This app is comprised of thousands
> of processes". To most people familiar with concurrency at the UNIX OS
> level or any number of threading schemes this sounds preposterous. Even
> after explanation most don't believe it until they have worked with it.
> Most will not get that opportunity as they will right you off after
> hearing about your 20000 processes:)   

Right, but again there is only *1* OS process, with many threads of execution
within it.  20000 UNIX processes DOES sound preposterous!

> > Most languages would argue that you _should_ be defensive (ex. checking for
> > NULL, catching exceptions, etc.)  Not sure this one is clear.
> 
> It is common in Erlang code to explicitly handle errors only on
> untrusted interfaces. This is not the case in most other languages and
> sounds rather radical/unrealistic to the uninitiated. 

Agreed. I suppose it is interesting to point out that if a C/C++ application
was _also_ comprised of individual processes which _could_ crash then a similar
approach could be taken.  That is, checking for NULL and catching exceptions
would NOT have to happen on internal code, only at the border.

The difference here is that of restarting a light-weight thread within the OTP
node vs. an entire UNIX process. Don't see any other big differences between
letting an OTP process (not on the border) to blow up vs. letting a C/C++
application referencing NULL pointer blow up.

In both cases, if the overall system is coded to cope with such process deaths
than it doesn't really matter, aside from the performance hit restarting a 
UNIX process vs. a very light-weight Erlang one.

> > > 4. Dynamic typing combined with "don't be defensive" ==Most static
> > > typing theory junkies== just can't work.
> 
> After saying that you should not be defensive your labeled a radical if
> you then follow it with "...and its all dynamically typed" you will be
> walked to the door and asked never to come back. We know after
> programming Erlang that judicious coding practice and all of Erlangs
> pluses allow very correct fault tolerant code to be written. Most people
> do not believe this until they see it.  

Though I do not disagree that judicious coding practice coupled with the many 
wonderful features of Erlang can lead to a large body of correct/fault-tolerant
code, I have my doubts about that codes reusability.

I can hear the anti-OO guys out there are already, and I agree that such OO
concepts as inheritance are not all they are cracked up to be in practice (i.e.
usually a good inheritance tree comes about as the result of refactoring an
existing system, since it may not have been clear at design time how the tree
should be layed out). A big difference is reusing functions/objects internally
that ARE defensively coded.

Put another way, most all my objects ARE defensive, and might as well be placed
"on the border". Since this is true, I can reuse an internal object on the
border without worrying about crashes. I can make calls to it from anywhere
and know that it is well behaved.

The same is NOT true with an Erlang module that is coded to crash on bad data
since it is not meant for border use. It would be a big mistake to use such
a module in a border case, and thus it is important as an Erlang/OTP developer
to make crystal clear the distinction.

Of course the code is much smaller when it is not defensively coded throughout
the application, no argument there. But when both sides (i.e. C/C++ and
Erlang OTP) are coded that way, what is the difference?

I suppose defensively coding EVERYTHING is a bit silly and unnecessary, but
this is not a strengh/weakness of Erlang/OTP, merely a coding practice that
can be (or not be) applied to any language.

> I hope this is more clear now.

Much.  Thank you.

-Rick