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

[traymond@craftedsmalltalk.com]

In <32ED2930.3B92@watson.ibm.com>, "Norman H. Cohen" <ncohen@watson.ibm.com> writes:
>traymond@craftedsmalltalk.com wrote:
>I presume you are using the word "procedural" to mean "not object
>oriented".  However, there is nothing in the example above that suggests
>this.  Perhaps it is the presence of a built-in array type that looks
>unSmalltalk-like to you.  Fine, replace the two integer types with two
>classes called producerID and consumerID, make Producers an object
>belonging to some collection class with an extract method that takes a
>producerID object, and make Consumers an object belonging to some
>collection class with an extract method that takes a consumerID object. 
>My argument remains the same:  It is easy to inadvertently send an
>extract message with a producerID argument to Consumers or an extract
>message with a consumerID argument to Producers.  The incorrect call
>might occur only on some obscure path that testing fails to exercise. 
>Strong typing allows such errors to be caught at compile time.

Agreed, it does.  But, it costs more to do so.  One reason
there is a lower incidence of type errors in smalltalk programs
is that it uses named parameters.  I know that ADA has named parameters
but last time I looked they were not required.  Named parameters are
required in smalltalk for anything other than unary messages and binary 
operators.

The point that most of the smalltalk programmers are trying to make here,
is not that strong typing will not do a better job of catching type
errors earlier than one would in smalltalk, but that because of
other features in smalltalk the incidence of type errors is
much lower and the additional benefit of strong typing would not
be worth the reduction in flexibility.  Furthermore, many of us
realize that smalltalk would benefit by having type-inference
tools to advise us of potential errors.  But, we would use these
as lint-like analysis tools.

One point that I don't think has been brought out well enough
is that smalltalk is incrementally compiled.  So, whenever
I compose a method it is compiled.  Frequently, the state
of my instance variables description is incomplete and
sometimes my method description is incomplete but I can
still compile the method.  Strong typing makes it very
difficult to do this.  Instead, I would have to resort
to using a file based editor and then do the compilation
after my description was sufficiently complete.  I should
also add the value of having an incomplete description in
the environment is that I can use the smalltalk browser and
cross-referencing tools to remind me what I have called things
and what I am doing with them.  If I use a file editor for
this I have scroll up and down, search back and forth, use
grep to find something in a different file, and etc...

Again, it is not that we think strong typing has no benefit,
but we think that with smalltalk and its environment the benefit
of enforced strong typing is not worth the cost.

===========================================================
Terry Raymond       Smalltalk Professional Debug Package
Crafted Smalltalk   *Breakpoints* and *Watchpoints* for
19 Tilley Ave.                  VW and ENVY/Developer 
Newport, RI  02840
(401) 846-6573      traymond@craftedsmalltalk.com
http://www.craftedsmalltalk.com
===========================================================