FAQ terminology harmonisation

[Rick Pettit]

On Wed, Apr 02, 2003 at 12:33:27PM -0600, Chris Pressey wrote:
> 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.'

Ah, that makes more sense. Though I know loss of data is a concern when anything
crashes.

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

Agreed. Bad example. I try to stay away from Perl for everything but the 
quick-and-dirty scripts these days.

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

Agreed.

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

Agreed. Assertions can be made in these cases to prevent this very dilemma.
Design by contract seems to address this.

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

I think I follow...

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

I fully agree.

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

Well yes, unless the C/C++ application loading the shared object (which in turn
requires runtime linkage) does so over and over again (i.e. loads .so, then 
later unloads and reloads NEW .so, and so on). In this case I don't see the 
difference.

Unless I am missing something here, regardless of type checking the interface
to the [shared object|hot code being loaded] MUST remain the same in BOTH
cases. Of course the code behind the interface can change as much as it wants
to, also in both cases. In this sense I see no difference between Erlang hot
code load and loading/unloading of shared objects.

Am I missing something?

-Rick