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

[Alan Lovejoy <alovejoy@concentric.net>]

Fergus Henderson wrote:
> 
> Alan Lovejoy <alovejoy@concentric.net> writes:
> 
> >Fergus Henderson wrote:
> >>
> >> 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 gave some specifics below; these would not apply to Smalltalk.
> 
> >>                         - 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).
> 
> Fair enough.
> 
> >>                         - wrong constant name: 4
> >>                         - wrong variable name: 4
> >
> >Were these "wrong" names simply undeclared,
> >or declared but wrongly typed?
> 
> In the case of the wrong constant names, I didn't record
> these distinctions, but my guess is that probably they were
> mostly simply undeclared (and hence would have been
> detected at compile time in Smalltalk).
> 
> In the case of the wrong variable names, it's a little more
> complicated.  In Mercury, variables do not need declarations.
> Most errors involving variables are caught by either singleton
> variable warnings and/or by mode errors (both of these are counted
> in the "others" category below).  Three of these four cases caught by
> type checking involved using an incorrect name that was also the name
> of another variable.  I think they would also have occurred in
> Smalltalk (and would not have been detected until run time).

What do you mean by "using an incorrect name that was also the name of
another variable"?  In general, a Smalltalk variable can only have one
name, and a name can only be bound to one variable. You cannot declare two 
variables with the same name in the same scope. You can, however, redeclare 
a variable in a BlockClosure that overrides a variable declared in an outer 
scope--but you will be warned of this.

So if by "using" you meant "declaring," then this can't happen without
warning.

However, if by "using" you meant "referencing," then such could in fact
occur.  But the data I collected for Smalltalk did not show this sort of
error as occuring with much frequency.  I think this is because Smalltalk
uses global variables far less than is common in other languages, so the
probability that a typo in a variable name will accidentally match some
other declared variable is therefore less.

> The fourth case involved trying to use the same name for two different
> variables.  I'm not sure whether that one would have occurred in Smalltalk.
> I guess it would depend on whether the programmer noticed that there
> was already a declaration for that variable.

As noted above, this can't occur in Smalltalk without warning.  This does
not happen often.  I can't remember the last time I encountered it, and
I write several hundred k-bytes of Smalltalk code every week.

> > 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 doubt if there are any of these sort of errors.
> Mercury has a quite simple type system.
> For example, there is only one integer type in Mercury.

How many Collection types?  Are integers interchangeable with floats,
and complex numbers, and fractions, and...

> Mercury is not C++.

Good!  I'm sure your happy about that :-).

> >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).
> 
> As mentioned above, I think that at least 3 of these 8 errors would
> occur in Smalltalk and not be caught by the compiler.

Except that my data show 2% or less as the rate of occurrence for "type" 
errors **IN SMALLTALK**.  I have been keeping track of this in my own 
work since last May.  I think trying to extrapolate what you measure
in Mercury programming to Smalltalk makes about as much sense as
applying the Smalltalk data to Mercury: interesting, but only an
approximation at best.

> >>                         - argument has wrong type: 7
> >
> >How many of these involved type differences that don't
> >matter in Smalltalk?
> 
> Probably none of them.

Are integers and floats interchangeable in Mercury?  What about Arrays,
Lists and SortedCollections?  Dictionaries implemented using either 
HashTables or BinaryTrees?

> >And how many were caused by the fact
> >that the Algol-style function call syntax makes it so easy
> >to get the arguments wrong?
> 
> Again, probably none of them.

Does Mercury use Algol-style function call syntax?  That is, "f(x, y, z, ...)"?
If so, the fact that Smalltalk will have fewer cases of "wrong argument" due
to its superior function call (message send) syntax is not a debatable point.
It's a fact.

> > So I would estimate that of the 83 type errors, only 1 of them would
> > show up at runtime in a Smalltalk program.
> 
> Well, I think your estimate is wrong.  I would estimate that
> 11 of them would show up at runtime.
>
> This would more than double the total number of runtime errors.

I disagree.  I think your estimate is biased by your lack of experience
using Smalltalk, and by the fact you are trying to extrapolate from
data about programming in Mercury to Smalltalk--a very different language
and programming environment.

> In addition, I estimate that there are probably another 9 errors in
> the "others" category, e.g. uninitialized variable errors, that are
> caught by static analysis in the Mercury compiler but which are unlikely
> to be caught by Smalltalk compilers.  Furthermore, just as there are
> errors that occur only in Mercury, and not in Smalltalk, there are no
> doubt many errors that would occur only in Smalltalk, and not in
> Mercury.  Obviously such errors aren't included in my list...

The Smalltalk compiler warns you of uninitialized temporary variables in
methods. It does not warn you of uninitialized instance variables, but
there is a coding convention that makes preventing such quite trivial:
you initialize all such variables in an object's #initialize method. The
object is sent the message #initialize whenever it is first instantiated
by the class.  Following this convention, it is a) easy to tell whether
a variable has been initialized, and b) therefore, not a frequently-encountered
problem.

> > Other advantages of
> > Smalltalk would probably eliminate several of those 9 run time errors
> > (for example, more abstract code...
> 
> I doubt this.  Mercury code is generally very high-level already, and
> looking at the nature of the errors, it's hard to see how using a
> different language could help avoid all but one of them.

I can't comment on Mercury.  I can say that Smalltalk makes many sorts of
coding errors that are common in other langauges much less likely in the 
first place.

> One of the nine errors was caused by incorrect argument order
> (it wasn't caught by typechecking since the arguments were both the
> same type).  That one might well have been avoided in Smalltalk.

Yes.

> Three were errors in the program's output.
>         - omitting the filename on one of the error messages
>         - enclosing something in double quotes instead of
>           in singe quotes
>         - printing `foo()' rather than `foo' (parentheses
>           should only have been used when there were arguments,
>           but the program printed them even when there were no
>           arguments)

These sound like bugs that would have happened in Smalltalk, too.

> Four were serious semantic errors (logic bugs); these are all too
> complicated to explain concisely, but I can't imagine any programming
> language feature that would avoid them.

A larger library of reusable code (your own, or that of some third party)
might have left less chance for the introduction of bugs that is common
in de novo code.

> One was a performance bug, caused by using an unnecessarily inefficient
> algorithm in the inner loop.

You might have coded this more efficiently to begin with, given a development
environment and language that encourages more rapid development (less time
pressure, a larger library of reusable code, and library code that is more
generic and hence more reusable).

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