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

[Alan Lovejoy <alovejoy@concentric.net>]

Graham Hughes wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> Looks like it's time for someone to play Devil's Advocate...
> 
> Alan Lovejoy <alovejoy@concentric.net> writes:
> 
> >But replace "PL/I" with "any statically-typed language," and then you
> >can see the truth: "because any statically-typed language sucks, is
> >why."  (Actually, statically-typed langauges have a useful niche, but
> >that niche does not encompass all of programming).
> 
> Depends on your point of view, I suppose.  The thing that makes me most
> unhappy about Smalltalk, Python, Perl, and the whole gamut of
> dynamically typed OO languages is just that--they are dynamically typed.
> 
> I prefer static typing.  It's largely a matter of interface design and
> subtyping; inheritance as code reuse is fine and dandy, but I prefer to
> program to interface specs.  Something like the Ada package system is
> close to ideal for me, where clearly defined operations on clearly
> defined types are possible (although I don't use Ada much for esthetic
> reasons).
> 
> Subtyping allows me to reuse this code willy-nilly; stronger, it means I
> don't introduce new bugs elsewhere because I'm passing a rectangle
> instead of an integer, and some module deep down was expecting the
> addition to go as planned.
> 
> The enforcability of this concept is what I like about static typing and
> dislike about dynamic typing.  Dynamic typing and languages have their
> places, but I'd prefer to be able to guarantee that the assumptions I
> made about a type are verifiable.
> 
> In Smalltalk, passing a Rectangle where the system expects an Integer
> results in a runtime error (depending on a number of circumstances, of
> course).  This means I won't stumble over the bug until I, or more
> likely, my user, stumbles across this set of circumstances.  Why allow
> for these types of bugs when they can be eliminated or at least reduced?

There is a tradeoff between static typing and dynamic typing.  I sometimes
program in statically-typed languages--because of the performance differences
that strongly affect some (but not most) algorithms.

I don't experience typing errors often enough to feel any need for the crutch
of static typing--at least, not in Smalltalk.  I wouldn't dream of using dynamic
typing in any non-OO language.  I suspect those who have used LISP but not CLOS
or Smalltalk may be negatively influenced towards dyanamic typing by the 
experience.  Not having used Python, I can't comment on that.  (I've been
meaning to give it a try for a while now, but I haven't gotten around to
it yet).

> >Ever heard of StrongTalk?  It's Smalltalk with static typing.  It was
> >a failure in the marketplace.  I conclude that static typing succeeds
> >when marketed to those who believe in static typing, and that dynamic
> >typing succeeds when marketed to those who belieive in dynamic typing.
> >And dynamic typing also succeeds when marketed to people who want the
> >fastest development times, and have no religious axe to grind over the
> >issue.
> 
> I conclude that _you_ have an axe to grind.  I also conclude that one
> failure is not a statistically valid sample.  I can claim that fully
> 100% of my development team prefers static typing, because _I_ am my
> development team.  Come back with something done by a statistician
> (although finding an honest statistician is often like finding an honest
> lawyer... :-); isolated cases prove nothing.

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.

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

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

> >Not in Java.  Java won't let you send any message that the compiler doesn't
> >know will be valid.  And there is no equivalant of #perform: (which sends
> >a message chosen at run time).
> 
> And #perform: is a good thing?  I can achieve a similar operation in C++
> (not Java, though) with pointer-to-member-functions in a map<> or an
> array or something, and it's even typesafe, so I don't have to worry
> (too much) about some perverted piece of code messing with my mind.

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.
 
> ...
> 
> Unlike yourself, I have no qualms about others using dynamic typing.
> Please, go ahead; if the advantages of it outweigh the disadvantages for
> your projects, by all means use Smalltalk.  I use Python, a dynamically
> typed OO language, for much of my scripting because it's far easier to
> get a prototype working.  For larger projects, particularly ones that I
> cannot hold entirely inside my head, I prefer a statically typed
> language for the reasons above.
> 
> But don't you _dare_ try to enforce your preferences upon me.

I was defending Smalltalk and dynamic typing, not trying to force anyone to
use those if they don't care to.  Sorry if it seemed otherwise.

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|