Re: OO, C++, and something much better!

[mbk@inls1.ucsd.edu (Matt Kennel)]

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 |==============================================|