FAQ terminology harmonisation

[Rick Pettit]

On Tue, Apr 01, 2003 at 12:38:31PM -0600, martin j logan wrote:
> 
> 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.

Don't say it that way. Segfaults are NOT done on purpose (i.e. no C/C++
programmer that I know of _wants_ his code to segfault, whereas in Erlang you
may intend for your process to die and be reborn.  Not a clear analogy.

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

Don't say it that one.  Entire node is *1* UNIX process running a thread per
OTP process. That doesn't sound nearly as slow.

> 3. don't be defensive ==Most other languages== sloppy incomplete error
> checking 

Most languages would argue that you _should_ be defensive (ex. checking for
NULL, catching exceptions, etc.)  Not sure this one is clear.

> 4. Dynamic typing combined with "don't be defensive" ==Most static
> typing theory junkies== just can't work.

Not sure how to address this one. I have worked too much with C++ and not enough
with Erlang to make a good call on this. Static typing has helped me a great
deal with my C++ code. Working in languages like Perl in the past (intern days)
without strict type checking I managed to get myself into trouble as the code
got really big and I failed to [re]factor it into manageable units (especially
since Perl insists on there being "more than one way" to do anything). Is the
same not true with Erlang/OTP?

Has anyone ever written an OTP application that crashed as the result of
passing the wrong type into a function or by misspelling a variable? Of course
with test-first methodology such a crash should not occur in production, but
still I can't help but wonder what is so wrong with such a silly mistake being
caught at compile time (since the misspelling, for example, would have been
caught by a lack of declaration of the typo, and the bad function call would
have also been caught). Though test-first methodology and rich test suites
will/should catch such mistakes, wouldn't it be better to have a compiler catch
such mistakes? Is it that much more work to declare a variable before using it?

I personally am a big fan of Perl and the "strict" pragma. Omitting the "use"
of this allows one to whip up a quick-and-dirty script in a hurry without
declaring variables. By "use"ing it, you can catch all sorts of silly typos in
larger scripts that would otherwise have to be chased down during testing.

Could someone explain why static typing is considered so "bad" or "unnecessary"?
I think I could be sold on this (I _do_ consider myself to be open-minded), I 
just need to hear the right argument.

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

Shoot down C/C++ junkies here by discussing shared objects and runtime linkage.
Is that not a similar creature? Not sure why one would be so much scarier than
the other.

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

This argument is not so bad, though it would need to be followed up by (at 
least) a brief explanation of supervision trees in OTP.

Just my 2 cents ;-)

-Rick

P.S. Sorry if I come across as argumentative. For the record I actually DO
     agree with Martin on quite a lot of his ideas, and I AM sold on Erlang/OTP.