[erlang-questions] Why isn't erlang strongly typed?

[Isaac Gouy]

On Thu Oct 23 02:04:47 CEST 2008, Richard O'Keefe wrote:
-snip-

> (I've been building a Smalltalk compiler in my spare time for a
couple
> of times.  It ran its first method yesterday!  Over and over and over
> I've found single inheritance limiting.)

Traits?

http://www.iam.unibe.ch/~scg/Research/Traits/


> Do we have a serious problem with run-time type errors?
> Is a type system the only, or the best, way to deal with them?

afaict the OP's complaint was not about type errors but about the
difficulty of understanding poorly documented 3rd party libraries in
the absence of source code type information.

The question would be more like - is a type system the only, or the
best or a good or a better than nothing, way to support library
exploration and comprehension.



So the following comments are incidental to the OP's complaint:

> One aspect of unit testing frameworks is that if you test each
> function in a module even a few times, you are going to smoke
> out most type errors fairly quickly.  You will also find many
> mistakes that a type system will not catch.

At which point we become interested in the cost of unit testing to
'smoke out most type errors' and wonder if type checking and unit
testing could perhaps be complementary practices.


> A suitable notation, such as Smalltalk/Objective-C split method
> names, can prevent most type errors in the first place.

Let's not forget that, with no type information in the source code,
Smalltalkers adopt the "best practice" of naming methods parameters
like this - aString, anInteger :-)


> Last year I kept a log of the mistakes I was finding in my
> Smalltalk system.  I haven't kept it up this year, because
> I'd learned the main thing I wanted to learn: errors that
> would have been caught by a type checker and not by other
> means were quite rare.

It's not a question of errors that would have been caught by other
means - it's a question of errors that would have been caught by other
means that are actually being used.

And of course it depends what we imagine the type checker can do - can
we catch nil/null references?

A quick look through this fix list for a Smalltalk maintenance release
gave me the impression that 
- 85% are changes to functionality/behaviour/appearance
- ~5% we might expect to have found with static checks
- ~10% we'd have to investigate more before we could say

http://www.cincomsmalltalk.com/blog/blogView?showComments=true&entry=3268381755