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.3 required=5.0 tests=BAYES_00, 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: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public From: mbk@inls1.ucsd.edu (Matt Kennel) Subject: Re: OO, C++, and something much better! Date: 1997/01/21 Message-ID: <5c33uf$8ma@news1.ucsd.edu> X-Deja-AN: 211432135 references: <32E47B4B.56D9@concentric.net> followup-to: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object organization: The University of California at San Diego reply-to: %%spam repellent: remove this prefix%%mbk@inls.ucsd.edu newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object Date: 1997-01-21T00:00:00+00:00 List-Id: Alan Lovejoy (alovejoy@concentric.net) wrote: : If I have an axe to grind, it's against the mindless and completely unsupported : claim that static typing is always better than dynamic typing. I have yet : to see any empirical proof presented for this claim other than hearsay and : anecdotes. I can easily match those with with hearsay and anecdotes in support : of dynamic typing. : If anyone has any stronger evidence, I'd like to see it. There is an unjustified absence of empirical evidence with respect to many of these sorts of topics. Thus we can only discuss logical consequences of languages and make guesses about their eventual importance. A 'statically typed' (type-constrained) language provides more assertions about the contents of variables. One consequence of a "fully dynamically typed language" which appears undesriable to many users is that a large fraction of the "library" must often accompany the delivered code. Why? Well if the contesnts of "messages" (method selectors) are mutable run-time data, then any run-time computation might conceivably result in the call of any part of the library. You need the transitive closure of anything which might possibly be called by a legal program. Typically the compiler will have to be excessively conservative for lack of information. A system with more static type constraints can _greatly_ prune this. C++ is a bad example, here. Other languages which know about the global totality of the system (yeah, Eiffel and derivatives like Sather) tend to be even more aggressive about eliding provably unused code. This is feasible because the actual program source contains many more implicit assertions which constrain the program. Static type constraints permit far more aggressive inlining and fast run-time representations which are quite important for high performance calculations. A disadvantage of course is less uniform reflectivity. It's not impossible though. : > >Smalltalk offers many times faster development times--and much greater : > >robustness in the face of changing requirements. That's a strategic : > >advantage, especially in businesses and industries (like securities : > >trading) where time is not just money, but big, big money. : > : > I acknoledge that Smalltalk has some advantages. Speed of development : > seems to be one. : > : > However, I will contest robustness. What about a system that throws a : > runtime error if you try to take the sin of a rectangle can be called : > robust? This sort of thing happens, even often; much better that the : > compiler check it than me, given that I'll probably overlook something : > subtle. : Smalltalk works on the "80/20" rule. That is, it is more cost effective : to take care of the common cases than it is to try to handle every conceivable : case. When typing errors only constitute 2% or less of all errors, it's time : to check the cost of eliminating the final 2% of the problem. The cost is : full polymorphism. IMHO, that's a pretty serious cost. Remember though that what might have turned out to be a type error in a statically typed language might not obviously show up as an equivalent "type error" in smalltalk or et cetera. A goal of a 'statically typed' langauge is to turn many sorts of 'thought errors' into mechanically checkable type errors. In any case, I don't find a large logical advantage to full static typing in initial development, when I still remember what everything is supposed to do. It's when I come back to a component months or years later and try to modify it that the static type system reminds me not to do something really stupid---often times things which I've entirely forgotten. : > If OO is about conceptual separation of code into independent modules, : > why should the modules be concerned about what somebody else gives them? : > Why should they manually check that the object is capable of the : > operations demanded when the compiler can? : This is a non argument. Since someone must check, there is no difference in : principle whether that someone is the compiler or the run-time system. It's : an implemenation difference, not a difference in kind. The difference being that a 'statically typed' langauge provides more assertions to check against. ISE Eiffel is still Eiffel even when you run it in "interpreted development" mode. : Have you looked at Netscape's IFC library? It's obviously similar to the : VisualWorks MVC classes. But oh the kludges they have to use for want of : a #perform: operation! Just how do you do an AspectAdaptor or PluggableAdaptor : in Java? : Used wisely, #perform: is a wonderful thing. But like any powerful tool, : it can be seriously misused. It's no worse than a pointer to function, : or a BlockClosure, though. Well a good static langauge with genericity and closures is better than one without. : -- : Alan L. Lovejoy |==============================================| : Smalltalk Consultant | Beware of Geeks bearing GIFs! | : alovejoy@concentric.net |==============================================|