FAQ terminology harmonisation

[Chris Pressey]

On Wed, 2 Apr 2003 11:50:51 -0600
Rick Pettit <rpettit@REDACTED> wrote:

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

I think what Martin was trying to say is that when you say that crashing
is a great way to handle errors, what the average C++ guy hears is 'Seg
fault on purpose?  That makes no sense.  These Erlang people are crazy. 
Etc.'

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

Yes.  But IMO Perl's problems go way beyond just having dynamic typing,
as well.

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

Crashed, no.  Failed, yes.

And that, I think, is an important point.  To most people, "crash" is a
dirty word because *they associate it with loss of data*.

But (even before I encountered Erlang) I realized that a crash is, at
least, a clear indication that something has gone wrong.  What is worse
is the insiduous failure... the semantic error in the system that you
don't consciously notice for a long time because it *doesn't* make
anything crash outright.  It just bungs up the works and leaves you with
the feeling that your system is inhabited by gremlins.

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

Catching errors as soon as possible is a good thing (and can help avoid
gremlins too).

I think there's something of a false dilemma here, too - the dynamic
typing advocates usually take the position that strong typing is
stifling (which it is,) while the strong typing advocates usually take
the position that once you have strong typing, you don't need dynamic
typing (which is a very systems-construction-ish approach that doesn't
lend itself well to ad-hoc networks and hot code reloading.)

My thought is that the best system would have both compile-time and
run-time checks.

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

Because runtime linkage typically only happens once during a run of a
program, whereas hot code swapping can happen any number of times with
any number of changes the to code in the interim.

-Chris