🚀 go-pugleaf

In article <14160@life.ai.mit.edu> tmb@ai.mit.edu writes:

>I wouldn't be quite so harsh. Static type checking is very good
>at eliminating a large fraction of those mistakes that people
>commonly make. 

There seems to be a discrepancy between reporters on this issue that is    
language dependent.

Type errors seem to be a big source of errors in C but seem to appear rarely	in Smalltalk programs.  At least this is true in my own experiences and 
others that I have talked to agree.  In Smalltalk the most common errors seem
to be object state problems.

I think that there is a reason for this, and it has to do with the purity of
object orientation extending down to the implementation/realization level.
In most 'normal' programming languages, a type error occurs when you present
a string of bits to a piece of code that expects to interpret that string of
bits in a particular way (short integer, float, char *, class foo), and
the bits aren't actually the right type of bits.

In a pure object oriented implementation, you just can't give the wrong string
of bits to a piece of code, the method dispatching sees to that.

I'm actually a little bit surprised that people put so much faith in compile
time type checking systems that they are willing to accept an implementation
that allows type errors that escape the compiler to cause wild branches and
other unsavory acts, and then demand that such stuff is required for
"industrial strength".

I haven't seen a strong typing system yet that doesn't require you to 
(hopefully carefully) circumvent it at times, or that is absolutely bullet
proof even without circumvention (array bounds checking, overflows etc.).
It takes real confidence to work in dangerous environments without safety
equipment.  Or maybe it's a less desirable quality than confidence!

Rick DeNatale