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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no 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: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: "Norman H. Cohen" Subject: Re: OO, C++, and something much better! Date: 1997/01/21 Message-ID: <32E4FC5B.242C@watson.ibm.com>#1/1 X-Deja-AN: 211321340 references: <32DF458F.4D5C@concentric.net> <32DF94DC.6FF8@watson.ibm.com> <32DFD972.37E4@concentric.net> content-type: text/plain; charset=us-ascii organization: IBM Thomas J. Watson Research Center mime-version: 1.0 reply-to: ncohen@watson.ibm.com newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng x-mailer: Mozilla 3.0 (Win95; I) Date: 1997-01-21T00:00:00+00:00 List-Id: Alan Lovejoy wrote: > However, dynamic typing results in signficantly faster development time. > So as long as the number of typing errors that occur in practice are low > enough, dynamic typing is still a net win. In my experience, the frequency > of occurrence of such errors is about 2% of all errors--which is much lower > than the break-even point. This strikes me as "seat of the pants" guess rather than a solid empirical result. I'll give you the benefit of the doubt and assume that your "2% of all errors" figure is based on methodical tracking of the projects on which you have worked. However, before you start to speculate about break-even points, you need some numbers about the degree to which dynamic typing supposedly speeds up development time, and you need some numbers about the amount of time wasted chasing these type errors in a debugging session rather than in response to a compile-time error message. Now the 2% figure may in fact be colored by the fact that you are using a weakly typed language. Users of strongly typed languages take advantage of compile-time type checking to encode all sorts of distinctions as type distinctions, so that a compiler's certification of type consistency greatly increases confidence in a program's overall logical consistency. Having worked with both dynmically and statically typed languages, my (unquantified) experience is that dynamic typing speeds up program development about as much as touch typing. :-) That is, it reduces data entry time because you don't have to type all those declarations. Of course this is a minuscule fraction of program development time. Once a program has been keyed in, strong typing results in a flurry of compile-time errors that must be addressed before the program will run. Of course dynamic typing does not make these errors go away, it just hides them so that you have to find them yourself instead of having them pinpointed for you by a compile-time error message. In my experience, a line containing a stupid mistake that would have been caught by decent compile-time checks can easily take 50 times as long to develop (counting the time to debug a line as part of that line's development time) as a line without such an error. In that case, even if we accept the 2% figure, static typing is still a win. Development time is of interest, of course, not in its own right, but because of its impact on project value and cost to the customer. The cost of a less timely deployment of a program must be weighed against the cost of an error that arises for the first time in the field, because the programming language did not allow the error to be caught at compile time and the run-time testing was incomplete. If you are lucky, the software merely fails, and the customer reverts to contingency procedures while programmers working overtime rush a patch out to the customer. If you are unlucky, the program appears to work correctly, but provides an incorrect result that causes your customer to lose tens of millions of dollars on an absurd securities trade. -- Norman H. Cohen mailto:ncohen@watson.ibm.com http://www.research.ibm.com/people/n/ncohen