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

[cr@informatik.uni-kiel.de (Claus Reinke)]

In <32E712B2.5060@parcplace.com> Eric Clayberg <clayberg@parcplace.com> writes:

>Graham Hughes wrote:

> > Having a type error propogate to the user is the height of immaturity.

> What about propogating a null pointer exception to the user? Is that
> somehow better? Propogating *any* error to the user could be considered
> the "height of immaturity". 

So the bottom line is: Find errors as early as possible (even avoid
them if you can, but never assume you have succeeded in this attempt)
and let the software help you wherever it can. Using dynamic typing
as the default and static type inference as an additional program
analysis should not harm anyone. Whether it is useful depends on the
type systems in use but there are certainly a lot of things you would
like to know about your SmallTalk programs that are hard to find out
by testing. With static type systems getting better, static typing
can be made the default, resorting to dynamic checks only for the
tasks where this is necessary (IMHO, completely static systems are
not reasonable because of the severe restrictions they impose on the
language).

>  Having worked extensively with several
> statically types languages (C, C++, Fortran, etc.) and now having worked
> commercially with Smalltalk over the last several years, I conclude that
> most "type" errors in statically types languages are due to the
> complicated nature of their syntaxes and the draconian rules of their
> type systems.

Sorry, but you should definitely *not* base your conclusions about
statically typed languages on C,C++,Fortran, etc. (is et-c another
C-variant?-). Try something like Standard ML or Haskell (there are
probably some non-functional alternatives, but I'm working in the
functional programming area). These languages make (what I think is)
a mistake as they exclude programs that cannot be handled by the
static type systems (instead of resorting to dynamic typing for
these), but the type systems themselves (and the languages) are
definitely worth looking at (these type systems are still not the
most powerful ones known, but most other systems haven't yet been
implemented in freely available general purpose languages).

> Smalltalk doesn't have those problems and doesn't lend
> itself to "type" errors of that nature. Almost all "message not
> understood" errors are messages directed to nil (the moral equivalent of
> a null pointer in C). 

What's a (null) pointer?-) In languages with implicit memory management,
there should be no need to (mis-)use pointers directly (well, change that
to: for the majority of programs). And in pure functional languages,
there are no (accesses to) uninitialized variables.

> > Incidentally, if you really care about spreading Smalltalk you might
> > want to attempt to get the FSF to fix their Smalltalk implementation.  I
> > can't fiddle around with Smalltalk anymore because that's the only
> > one I can get for Linux, and it doesn't work.

Somebody once posted a link to Smalltalk/X (the link is still active,
though quite old, and I haven't tried the system..) which lists Linux 1.1.*

http://www.informatik.uni-stuttgart.de/stx/stx.html

> Sorry. I never heard of FSF. If you want to try out a commercial grade
> Smalltalk IDE (which appears not to describe whatever "FSF" product you
> used), 

FSF (Free Software Foundation) is not dedicated to lower standards or 
prices, just to freedom of use (eliminating restrictions on copying,
redistribution, understanding, and modification of computer programs).

http://www.gnu.ai.mit.edu/fsf/fsf.html

Hope this helps,

-- 
Claus Reinke                                University of Kiel
email: cr@informatik.uni-kiel.de            Department of Computer Science
http://www.informatik.uni-kiel.de/~cr/      Preusserstr. 1-9,   24105 Kiel