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

[fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson)]

Alan Lovejoy <alovejoy@concentric.net> writes:

>Fergus Henderson wrote:
>> 
>> 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"?
[...]
>However, if by "using" you meant "referencing,"

Yes, that's what I meant.

>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'm sure the frequency of different error categories may
vary quite a bit from programmer to programmer, as well
as from language to language.  Perhaps you make different
sorts of mistakes than I do.

>I think this is because Smalltalk
>uses global variables far less than is common in other languages,

That explanantion is almost certainly wrong.  I strongly suspect that
global variables are used even less in Mercury than in Smalltalk,
because Mercury, being a pure functional/logic language, does not
provide any language support for them.

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

I would be *extremely* surprised if that is really true.  Smalltalk
implementations may well warn about occurrences that have overlapping
scopes, but I can't imagine a Smalltalk compiler issuing a warning
if a variable is declared once and then the code tries to use it
for two different (and incompatible) purposes.

>This does not happen often.

You're right.  That was only one of the 155 errors I encountered.

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

... used in the program in question? 
Four: list, set, map, and varset.

I don't think that 

>Are integers interchangeable with floats,
>and complex numbers, and fractions, and...

No, but the program in question didn't use any floats,
complex numbers, or fractions.

>Except that my data show 2% or less as the rate of occurrence for "type" 
>errors **IN SMALLTALK**.

Since Smalltalk doesn't detect type errors automatically, then there
may well be a significant number of type errors in your Smalltalk
programs which you have not yet detected (but which your customers
may find ;-).

Also, it is possible that you may be misclassifying some errors as
non-type errors even though they would have been caught by static type
checking.

If you have some detailed records for Smalltalk, then perhaps you
could post them and we can give them the same sort of examination.

>> >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, ...)"?

Yes.

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

Do you mean fewer cases getting past the compiler,
or fewer cases at all?

I think most of these cases were due to changes in one part of the
source code not being reflected in other parts.  I don't think
Smalltalk syntax is going to help in such cases.

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

The four bugs were all in very application-specific code that I can't
imagine being in any library of reusable code.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.