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

[Alan Lovejoy <alovejoy@concentric.net>]

Fergus Henderson wrote:
> 
> Eric Clayberg <clayberg@parcplace.com> writes:
> 
> >Fergus Henderson wrote:
> >> My experience is that errors caught by type checking constitute a LOT
> >> more than 2% of errors.
> >> For a period of time I carefully recorded the cause of every error that
> >> I found while writing a Mercury program.  Of the 155 errors that I
> >> recorded, 73 were error caught by the type checker.
> 
> While reexamining my list, I noticed that I had accidentally
> misclassified one class of errors containing 3 errors, so the number 73
> above should have been 70.  Sorry about that.
> 
> >If anything, I think that reflects poorly on the syntax of whatever
> >language you were using.
> 
> Some (14) of those 70 errors were related to the syntax, but most of
> them were errors such as "wrong number of arguments", "wrong procedure
> name", and so forth, that could occur in just about any language.  Note
> that the number 70 does *not* include errors in the type declarations
> themselves; there were an additional 13 of those.
> 
> Here's a more detailed breakdown.

To which I wish to add some comments and analysis:

>         syntax errors: 16
>         type errors: 83
>                 - errors in type declarations: 13

Doesn't apply to Smalltalk.

>                 - type errors other than errors in type declarations: 70
>                         - syntax related: 14		
May or may not apply to Smalltalk.  Can't
tell without more specifics.  I assume that
this does not apply to Smalltalk, or that
the Smalltalk compiler would catch this sort 
of error just as well as in a statically-typed 
language.

>                         - wrong procedure name: 11

The Smalltalk compiler will complain when you compile
a method that sends a message with no implementors.
So this would only apply to those cases where the
"wrong" name matched that of some other method.
I would assume that all such errors out of 11 would be 
caught by the Smalltalk compiler (about 99% would be
caught overall).

>                         - wrong constant name: 4
>                         - wrong variable name: 4

Were these "wrong" names simply undeclared, 
or declared but wrongly typed?  How many of the
"wrongly typed" ones involved type differences
that don't matter in Smalltalk (ie, long vs. short
numbers, different types of Collection)?  I will ssume that 
1 of these 8 errors would cause a Smalltalk program to 
produce the wrong result or fail (the Smalltalk compiler 
will catch any undeclared references, and about 92% of type 
incompatibilities in C++ are cases that will "just work fine"
at runtime in a Smalltalk program).

>                         - wrong number of arguments: 21
>                         - incorrect argument order: 5

Such errors (argument number/order) are FAR less likely 
in Smalltalk, thanks to Smalltalk's method name syntax.  
When they do occur, they are usually caught by the compiler 
because the incorrect message selector will probably not 
have any implementors.  Assume that all such errors would
be caught by the Smalltalk compiler (about 99% would be 
caught overall).

>                         - argument has wrong type: 7

How many of these involved type differences that don't
matter in Smalltalk? And how many were caused by the fact
that the Algol-style function call syntax makes it so easy
to get the arguments wrong? I'd assume that all of these 7 errors 
would simply not have happened in a Smalltalk program, either
because of the superior function call syntax, or because of
the superior interchangeability of similar object types.
Overall, I'd assume such errors happen about 1% of the time.

>         other errors detected at compile time: 47
>                 - missing `import_module' declarations: 7
>                 - errors in mode declarations: 13
>                 - others: 27
>         errors not detected until run time: 9

So I would estimate that of the 83 type errors, only 1 of them would show up at 
runtime in a Smalltalk program.  And all of them would probably be caught during 
early program testing. Other advantages of Smalltalk would probably eliminate several 
of those 9 run time errors (for example, more abstract code means that less new code
would need to be written to implement the program, and Smalltalk's large library
of classes/methods also reduces the need to write new--more buggy--code).  And if
it's a C++ program we're comparing against, then that introduces a whole menagerie
of possibilities for errors that would not occur in a Smalltalk program (can you
say "dangling pointer"?  I knew you could). 

And of course, the Smalltalk program will be ready for testing sooner, and thus 
you will have the luxury of testing it more thoroughly.

> The "syntax related" errors all relate to a particular aspect of
> Mercury syntax: calling and defining procedures that have implicit side
> effects uses a different syntax than is used for procedures which do
> not have any implicit side effects.  This is clearly an error-prone
> aspect of the syntax, but it enhances readability.
> 
> Of the "syntax errors", 10 were caused by missing or additional commas;
> this class would probably not occur if Mercury syntax used say `;' as
> a statement terminator rather than `,' as a statement separator.

Note how syntax affects the error rate.  The superiority of the Smalltalk
message send (function call) syntax in this regard has not been sufficiently
highlighted in these sorts of discussions, in my opinion.

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|