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: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,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 From: Eric Clayberg Subject: Re: OO, C++, and something much better! Date: 1997/01/22 Message-ID: <32E6862D.608B@parcplace.com>#1/1 X-Deja-AN: 211552897 references: <32DF458F.4D5C@concentric.net> <32DF94DC.6FF8@watson.ibm.com> <32DFD972.37E4@concentric.net> <32E4FC5B.242C@watson.ibm.com> content-type: text/plain; charset=us-ascii organization: ParcPlace-Digitalk, Inc. mime-version: 1.0 reply-to: clayberg@parcplace.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; U) Date: 1997-01-22T00:00:00+00:00 List-Id: Norman H. Cohen wrote: > 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. Not true. In a language like Smalltalk, those "errors" as you call them are not hidden; they never existed to begin with. Having worked extensively with several statically types languages (C, C++, Fortran, etc.) and now having worked commercially with Smalltalk over the last several years, I conclude that most "type" errors in statically types languages are due to the complicated nature of their syntaxes and the draconian rules of their type systems. Smalltalk doesn't have those problems and doesn't lend itself to "type" errors of that nature. Almost all "message not understood" errors are messages directed to nil (the moral equivalent of a null pointer in C). > 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. I don't follow that logic at all. I think you are multiplying apples and oranges together to get pears. The dubuggers commonly available with most Smalltalk systems make finding and fixing bugs a trivial process - certainly no harder than writing the code in the first place. > 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. It's funny that you should mention securities industry. Quite a few Wall Street investment banks use Smalltalk for their securities trading systems. Having been involved with several securities-related Smalltalk projects in the past, I can tell you some of the reasons why Smalltalk is so popular there: 1) it provides much faster time to market (very important in the securities industry), 2) it has a simple, logical and consistent language syntax (developers can concentrate of the problem at hand and not the vagaries of the syntax), 3) it is extremely reliable in practice (the language features of Smalltalk help eliminate whole classes of errors common in languages like C++), and 4) it is extremely easy to debug when an error does occur. If you doubt that any of these are true, then you should try it out yourself. You can download Smalltalk Express (a fully functional, 16-bit WIndows Smalltalk IDE) for free from http://www.objectshare.com. -Eric