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.3 required=5.0 tests=BAYES_00,INVALID_MSGID 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: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: Re: OO, C++, and something much better! Date: 1997/01/24 Message-ID: #1/1 X-Deja-AN: 212176858 sender: news@organon.com (news) references: organization: Organon Motives, Inc. newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng Date: 1997-01-24T00:00:00+00:00 List-Id: In article <32E6862D.608B@parcplace.com> Eric Clayberg writes: > Norman H. Cohen wrote: > >[...] > > 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 Well, the evidence you list here is not convincing. I mean C? Fortran? or even C++? These are not particularly strongly typed. Though they are statically typed. The first two are definitely not as strongly typed as ST. But, you can easily get the errors that are mentioned above by NC in ST. They just come out differently. Shrug. I tend to think that catching them earlier is better. Also, the structure imposed is better for long term maintenance and new maintainers (those who did not write the stuff). As Alan has pointed out, the ST answer to this is the "ease/speed with which you can change" something. Yes, but that does not seem sufficient - to me. Clearly it is for others. > > 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. Norman clearly has a point. But it is just as clear that it is not obvious when something like a "50 times" factor is involved. Or whether it is a case of "50 times nothing is still nothing" (small programs) and so would be irrelevant anyway. OTOH, debuggers are not relevant for fielded software and besides debuggers for statically typed languages have become pretty sophisticated as well, so "debugger sophistication" is not relevant either. > 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), Makes some sense. > 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), That's nice, but should be irrelevant to the customer. So, I don't see how this could _objectively_ have anything to do with why they like it - they never see the syntax (or at least they shouldn't have to!) > 3) it is extremely reliable in practice (the language features of > Smalltalk help eliminate whole classes of errors common in languages > like C++), Nobody's talking about C++ here. Or for that matter even Java. Try Ada or Eiffel. How many commercial jet liners are running their systems with ST? Of course there is a tradeoff - this kind of reliability does not come from "getting _something_ quickly up and 'running'". OTOH it is quite believable that "wallstreeters" deem time to use, worth the reliability risk. This is often true when you are "playing percentages". > 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. That's great too. But this is equally true of strong statically typed languages, both "extremely easy to debug" and available free downloadable versions. Actually some of these (GNAT for example) are high quality industrial strength implementations. /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com