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

[James O'Connor <joconnor@jmpstart.com>]

Norman H. Cohen wrote:
> 
> Alan Lovejoy wrote:
> 
> > However, dynamic typing results in signficantly faster development time.
> > So as long as the number of typing errors that occur in practice are low
> > enough, dynamic typing is still a net win.  In my experience, the frequency
> > of occurrence of such errors is about 2% of all errors--which is much lower
> > than the break-even point.
> 
> This strikes me as "seat of the pants" guess rather than a solid
> empirical result.  I'll give you the benefit of the doubt and assume
> that your "2% of all errors" figure is based on methodical tracking of
> the projects on which you have worked.  However, before you start to
> speculate about break-even points, you need some numbers about the
> degree to which dynamic typing supposedly speeds up development time,
> and you need some numbers about the amount of time wasted chasing these
> type errors in a debugging session rather than in response to a
> compile-time error message.
> 
> Now the 2% figure may in fact be colored by the fact that you are using
> a weakly typed language.  Users of strongly typed languages take
> advantage of compile-time type checking to encode all sorts of
> distinctions as type distinctions, so that a compiler's certification of
> type consistency greatly increases confidence in a program's overall
> logical consistency.

Not really, it just means the program follows the language rules.  When
I was working in Ada(83) I found that most of the type errors that the
compiler caught were actually not logic errors but syntax errors. 
Usually I would be trying do something that logically I should have been
able to do and that my program required, but because of the typing
rules, I got a compile error.  In other words, the compiler complained
that I had type errors that were created, not by my bad programming
logic, but because I didn't follwo the rules enforced by the compiler. 
All it said was that I had violated the language rules, it didn't say
one whit about whether my program was logically correct. X + (Y* 3) Even
if X and Y and 3 are all the right type, that doesn't do me any good if
the 3 was supposed to be 2.

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

Then you are not properly using dynamic typing :)

	Seriously, I find myself able to build structures in Smalltalk that I
would not be able to build in statically typed langauges, at least not
very easily. Especially anytime I need an object from one class to be
able to transparently substitue for an object from another class.  (Go
to the Design Patterns book and look at the difference between the C++
implementation of a Proxy and the Smalltalk implementation).  I use
Proxies to act as placeholders for objects of classes that I do not even
know until after the Proxy has first been referenced.  I also build a
lot of objects that (for other reasons) are in one hierachy chain but
also have to act like Collections (or Streams, or whetver).  By
providing the methods needed to support the proper collection protocol,
I can use my object in any message send to anybody that expects a
Collection.  You could do this with MI, but I also build objects that
can act in place of many different objects that change at runtime.  I
have an Actor-Role structure where an Actor knows how to delagate
messages to it's various roles, which change at runtime. An actor with a
given role at runtime can be used in any situation that expects that
role.  An actor with many roles can be used in place of any of those
roles. I also am involved in working with Distributed Smalltalk where I
use Shadows to send messages over a wire to objects of classes that are
not even in my environment. (And it only takes one simple Shadow class
to represent any foreign object of any class).

	All of these techniques are very powerful and useful to me.  While you
may be able to emulate them in other languages, the lack of compile-time
typing makes the Smalltalk solutions very easy.  It would take a lot
more than just typing those declarations to do it in a static language
(partially because those declarationbs are not known until runtime).

	And that's (part of) the speed increase in development Alan was talking
about, the ability to build powerful and dynamic frameworks (and use
those frameworks in diverse areanas) that dynamic typing allows that
static typing would make much more difficult to build.

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

That may or may not have been real errors.  Are they errors in your
logic or errors in your obediance to the rules?

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

Dynamic typing makes these errors go away if they were not errors to
begin with :)
I never (strong word...almost never) get errors for accidentally sending
a Rectangle instead of an Integer.  I usually get typing errors for one
of two reasons. Either I'm sending a message to nil (this means that
either I didn't initialize something properly or I was too lasy to heck
the return value from a method). Or a method returns either a good
object or an error object and I'm only up to writing the code for the
good object and haven't put in the check for the error object.  (Like an
Ada program may blow up if you're still testing and haven't written al
the exception handlers yet).  Bottom line is that the (bery few)
'typing-errors' I get in Smalltalk are not really typing errors at all
but are symptomatic of bad program logic in the first place (and,
because of that they usually blow up *very* fast) and are of a nature
that even in a typed language, the programl logic errors would still be
there.


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

	Sure, but that assumes that a stronly-typed language will ship with
less 'logic' errors than a typed one.  A typed language only guarentees
that all the variables (objects) are of the specified type, it doesn't
mean the program meets the requirements.  I actually had an Ada83
program that blew up at runtime precisely because it was strong-typed. 
The designer had put an upper limit on a type, based on real-world
conditions.  That upper limit didn't really mean anything, we didn't
care about what it was.  It just happaned to be a high enough value that
the designer thought would be sufficient.  The designer was wrong, the
real world changed, conditions were different, and the system crashed
because a totally meaningless limit was placed on a value in obediance
to the typing system.  If that had been in Smalltalk, the value would
have rolled over from Integer to LargeInteger and gone right along
without caring (because we didn't care either, and neither did the
use...until it crashed).
	That was when I stopped trusting the typing system. 

> 
> --
> Norman H. Cohen
> mailto:ncohen@watson.ibm.com
> http://www.research.ibm.com/people/n/ncohen

-- 
James O'Connor 

--------------------------------------
joconnor@jmpstart.com
http://www.jmpstart.com
--------------------------------------