From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public From: Alan Lovejoy Subject: Re: OO, C++, and something much better! Date: 1997/01/24 Message-ID: <32E9BAAC.29C7@concentric.net> X-Deja-AN: 212080928 references: <32DF458F.4D5C@concentric.net> <32DF94DC.6FF8@watson.ibm.com> <32DFD972.37E4@concentric.net> <5bphq4$5js@mulga.cs.mu.OZ.AU> <32E05FAF.47BA@concentric.net> <5buodl$bci@boursy.news.erols.com> <32E2FEC7.2F7B@concentric.net> <5bvncj$gqg$1@A-abe.resnet.ucsb.edu> <32E47B4B.56D9@concentric.net> <5c4fr0$27j@mulga.cs.mu.OZ.AU> <32E67751.4AFC@parcplace.com> <5caqo5$k5l@mulga.cs.mu.OZ.AU> content-type: text/plain; charset=us-ascii organization: Modulation mime-version: 1.0 newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object x-mailer: Mozilla 2.01Gold (Win95; U) Date: 1997-01-24T00:00:00+00:00 List-Id: Fergus Henderson wrote: > > Eric Clayberg 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 |==============================================|