Re: OO, C++, and something much better!

[bobduff@world.std.com (Robert A Duff)]

In article <5c4ab5$134$1@goanna.cs.rmit.EDU.AU>,
Richard A. O'Keefe <ok@goanna.cs.rmit.EDU.AU> wrote:
>I have seen this argument the other way around:
>in a language with strong *dynamic* checking, the run time system
>catches all the errors that actually happen, while a static checker
>misses a lot of them.

Well, it's not clear whether this thread is about "static vs. dynamic
type checking", or "Smalltalk vs. C++".  As has been pointed out,
Smalltalk doesn't do a very good job of dynamic checking (e.g. no checks
on parameter passing or assignment), and C++ doesn't do a very good job
of static checking (e.g. no easy way to define distinct integer types),
not to mention that the C++ type system (and the Ada type system) is
less flexible than in needs to be.

>Surely the answer is not to be dogmatic either way, but to accept that
> - no amount of static checking is ever going to eliminate the need
>   for _all_ dynamic checking
> - dynamic checking has a run time cost; other things being equal it
>   is better to move it to compile time
> - dynamic checking has a life cycle cost; other things being equal
>   it is better to catch errors with a compiler than with testing
> - static checking limits expressiveness to what the language designer
>   believed was feasible (the Ada 95 type system really is very limited,
>   why TYPE isn't even a type!)
> - static checking has a life cycle cost; it _may_ pay off during a
>   prototyping phase, for example.

Wow!  Somebody with a reasonably broad view, rather than a "my language
is perfect" attitude!  (I mean, I agree with the above.)

>>In other words: I'd feel really embarrassed if the user ever saw a  
>>"message not understood" error.
>
>Don't worry, I see enough "core dumped" messages on one system and
>pretty pictures of bombs on another, and my friends see "GPF" often
>enough, that we'd forgive you...

Indeed.

Of course, all of these kinds of run-time failures should cause
embarrassment.  I'm amazed by some comments in this thread that seem to
imagine the end-user fooling about in the (admittedly nice) Smalltalk
debugger.  And comments that seem to confuse the detection/prevention of
bugs with the tracking-down and fixing thereof.

>>IMHO, bugs that can be found automatically should be found automatically.  
>
>Not all languages are used by software engineers.  For example, I am
>currently working with a language called R, based on S.  It's an
>interactive programming language for statistics and graphics.  S is well
>regarded by its users,  If it required declarations, they wouldn't use it.

Hmm.  I have mixed feelings about that statement.  Since I know nothing
about R or S, I'm willing to believe that the R language has an entirely
appropriate set of static and dynamic rules, for this type of
"application".  But I'm not so sure that "well regarded by its users" is
exactly the right criterion.  I mean, this borders on the attitude that
too many programmers have, which seems to be that a language is good if
it's fun to program in.  I've got nothing against having fun (I like
programming a lot), but surely the ultimate goal is to produce good
software.  As you can see from this thread, Smalltalk is well-regarded
by many of its users, and Ada is well-regarded by many of its users, and
the same for C -- isn't there some sort of objective reality, that goes
beyond what programmers think they like?

>>So, dynamic typing has the disadvantage that it makes a set of compile- 
>>time checks impossible.
>
>This is simply false.  ...

Hmm.  In the Smalltalk context, it seems that adding compile-time checks
requires modifying the language, so that there's some way to
(optionally) declare the type/interface expected for each parameter and
variable.  I mean, type-inference is all well and good, but there's got
to be some (preferably fairly localized) information to start inferring
from.

- Bob