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: 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: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: James O'Connor Subject: Re: OO, C++, and something much better! Date: 1997/01/23 Message-ID: <32E7DACB.423@jmpstart.com> X-Deja-AN: 211777242 references: <32DF458F.4D5C@concentric.net> <32DF94DC.6FF8@watson.ibm.com> <32DFD972.37E4@concentric.net> <32E4FC5B.242C@watson.ibm.com> to: ncohen@watson.ibm.com content-type: text/plain; charset=us-ascii organization: JumpStart Systems mime-version: 1.0 reply-to: joconnor@jmpstart.com newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng x-mailer: Mozilla 3.01Gold (Win95; I) Date: 1997-01-23T00:00:00+00:00 List-Id: Norman H. Cohen wrote: > > 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. Not really, it just means the program follows the language rules. When I was working in Ada(83) I found that most of the type errors that the compiler caught were actually not logic errors but syntax errors. Usually I would be trying do something that logically I should have been able to do and that my program required, but because of the typing rules, I got a compile error. In other words, the compiler complained that I had type errors that were created, not by my bad programming logic, but because I didn't follwo the rules enforced by the compiler. All it said was that I had violated the language rules, it didn't say one whit about whether my program was logically correct. X + (Y* 3) Even if X and Y and 3 are all the right type, that doesn't do me any good if the 3 was supposed to be 2. > 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. Then you are not properly using dynamic typing :) Seriously, I find myself able to build structures in Smalltalk that I would not be able to build in statically typed langauges, at least not very easily. Especially anytime I need an object from one class to be able to transparently substitue for an object from another class. (Go to the Design Patterns book and look at the difference between the C++ implementation of a Proxy and the Smalltalk implementation). I use Proxies to act as placeholders for objects of classes that I do not even know until after the Proxy has first been referenced. I also build a lot of objects that (for other reasons) are in one hierachy chain but also have to act like Collections (or Streams, or whetver). By providing the methods needed to support the proper collection protocol, I can use my object in any message send to anybody that expects a Collection. You could do this with MI, but I also build objects that can act in place of many different objects that change at runtime. I have an Actor-Role structure where an Actor knows how to delagate messages to it's various roles, which change at runtime. An actor with a given role at runtime can be used in any situation that expects that role. An actor with many roles can be used in place of any of those roles. I also am involved in working with Distributed Smalltalk where I use Shadows to send messages over a wire to objects of classes that are not even in my environment. (And it only takes one simple Shadow class to represent any foreign object of any class). All of these techniques are very powerful and useful to me. While you may be able to emulate them in other languages, the lack of compile-time typing makes the Smalltalk solutions very easy. It would take a lot more than just typing those declarations to do it in a static language (partially because those declarationbs are not known until runtime). And that's (part of) the speed increase in development Alan was talking about, the ability to build powerful and dynamic frameworks (and use those frameworks in diverse areanas) that dynamic typing allows that static typing would make much more difficult to build. > 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. That may or may not have been real errors. Are they errors in your logic or errors in your obediance to the rules? > 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. Dynamic typing makes these errors go away if they were not errors to begin with :) I never (strong word...almost never) get errors for accidentally sending a Rectangle instead of an Integer. I usually get typing errors for one of two reasons. Either I'm sending a message to nil (this means that either I didn't initialize something properly or I was too lasy to heck the return value from a method). Or a method returns either a good object or an error object and I'm only up to writing the code for the good object and haven't put in the check for the error object. (Like an Ada program may blow up if you're still testing and haven't written al the exception handlers yet). Bottom line is that the (bery few) 'typing-errors' I get in Smalltalk are not really typing errors at all but are symptomatic of bad program logic in the first place (and, because of that they usually blow up *very* fast) and are of a nature that even in a typed language, the programl logic errors would still be there. > 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. > Sure, but that assumes that a stronly-typed language will ship with less 'logic' errors than a typed one. A typed language only guarentees that all the variables (objects) are of the specified type, it doesn't mean the program meets the requirements. I actually had an Ada83 program that blew up at runtime precisely because it was strong-typed. The designer had put an upper limit on a type, based on real-world conditions. That upper limit didn't really mean anything, we didn't care about what it was. It just happaned to be a high enough value that the designer thought would be sufficient. The designer was wrong, the real world changed, conditions were different, and the system crashed because a totally meaningless limit was placed on a value in obediance to the typing system. If that had been in Smalltalk, the value would have rolled over from Integer to LargeInteger and gone right along without caring (because we didn't care either, and neither did the use...until it crashed). That was when I stopped trusting the typing system. > > -- > Norman H. Cohen > mailto:ncohen@watson.ibm.com > http://www.research.ibm.com/people/n/ncohen -- James O'Connor -------------------------------------- joconnor@jmpstart.com http://www.jmpstart.com --------------------------------------