Newsgroups: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news4.ner.bbnplanet.net!news3.near.net!paperboy.wellfleet.com!news-feed-1.peachnet.edu!usenet.eel.ufl.edu!news.mathworks.com!news.kei.com!simtel!harbinger.cc.monash.edu.au!aggedor.rmit.EDU.AU!news.unimelb.EDU.AU!cs.mu.OZ.AU!fjh
From: fjh@cs.mu.OZ.AU (Fergus Henderson)
Subject: Re: Why is one OO language more productive than another?
Message-ID: <9524602.2157@mulga.cs.mu.OZ.AU>
Organization: Computer Science, University of Melbourne, Australia
References: <40t027$7j9@hardcopy.ny.jpmorgan.com> <40t7veINNe25@bhars12c.bnr.co.uk> <40tcq2$10fa@tigger.cc.uic.edu> <40vashINNgo8@bhars12c.bnr.co.uk> <9523600.18871@mulga.cs.mu.OZ.AU> <26jg07$031@zoe.pcix.com>
Date: Sat, 2 Sep 1995 16:29:20 GMT
Lines: 83
Xref: glinda.oz.cs.cmu.edu comp.object:38004 comp.lang.eiffel:10749 comp.lang.c++:147738 comp.lang.smalltalk:28031

traymond@pcix.com writes:

>fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
>
>>If you want some numerical evidence, I have some.  For a while I
>>carefully recorded the cause of every error that I encountered while
>>writing a Mercury program.  Of a total of 155 errors (122 errors in
>>the code and 33 errors in declarations), 146 were caught at compile
>>time - only 9 bugs got past the compiler.  Of the errors detected by
>>the compiler, 83 were type errors (73 in the code and 10 in type
>>declarations).  Without strong typing, the number of bugs that I had to
>>track down myself by manual debugging would have increased from 9 to
>>82, i.e.  almost 10-fold.
>
>Sounds good, but there is a lot more to it than that.  Suppose you had
>been using smalltalk instead of C++, now what would happen if a message
>or operation had been performed on one of those 'mistyped' variables?

I wasn't using C++, I was using Mercury.
But let's continue - suppose I had been using a dynamically typed
language like Prolog or Smalltalk rather than Mercury.

>It is possible, and very likely, that with many of them nothing would
>have happened because the way the variable was used was correct, so
>that the message being sent was defined in the receiving object and
>would have worked.  It is just that the declaration was wrong. 

As I noted above, only a small proportion (10 out of 83) of the
type errors were errors in the declarations; the vast majority
(70 out of 83) indicated real errors in the code.

>In other cases you get a 'doesNotUnderstand:' message the first time
>the message is sent, and that is just as easy and fast to fix as
>correcting a declaration.

This agrees with my experience with dynamically typed languages.
Most errors are caught quickly at run-time, and are easy to fix.
However, some errors are not caught quickly - for some of them, even
simple ones, it takes a very long time indeeed.  (For example, I
distinctly remember spending several hours tracing through a Prolog
program I'd written trying to find a bug that eventually turned out to
be due to a single mispelt name.)  So although the median time to fix
errors is small, the mean time is large.  Furthermore, the larger the
program, the longer it takes to locate even simple errors.

>Typing is of most value to the compiler.  If the compiler does not
>need typing then its value is greatly reduced.

I would say the converse: typing is of great value to the programmer,
IMHO, but if the compiler does not enforce it then its value is greatly
reduced. 

Typing is of value to the programmer for two reasons.  Firstly, it
provides very useful documentation, particularly if that documentation
is known to have been proven correct by the compiler.  Secondly, it
means that many errors are caught at compile time.

>The only case where typing catches significant errors during program
>development is where the program logic is wrong and the wrong message
>is being sent to an object. I would contend that the number of
>situations where this occurs is a lot smaller.  I would say that the
>cost of using typing to catch these errors it simply too high.

Although some type errors do indicate errors in the design, the
majority are simple errors in the implementation - passing the wrong
number of arguments, passing arguments in the wrong order, passing the
wrong variable for some particular argument, misspelling names, and so
on.  Although these errors are very simple and easy to fix *once you
have found them*, the cost of finding them through manual debugging can
be very high.  In my case, I think that the extra development time
required for type declarations is amply repaid by the ten-fold
reduction in the number of errors requiring manual debugging. 
(Of course, your mileage may vary; if anyone else has collected any
statistics of this sort, I would be interested in hearing them.)

>The reason I would like some sort of typing in smalltalk is that
>it helps the programmer understand what an existing program is doing.

If you are going to use type declarations for documentation, why not
get the compiler to check their correctness?

-- 
-- 
