Squeak-dev Digest, Vol 22, Issue 20

Andreas Raab andreas.raab at gmx.de
Sat Oct 16 21:50:22 UTC 2004


Andres,

I respect your opinions but please don't put things into my mouth that I 
haven't said or meant. And since this discussion will be going nowhere 
anyway, I'll just make a point about a very specific issue:

> From another point of view: Smalltalk's point was to teach kids, and
> it seems to me it was important to make it late bound.  Therefore I
> don't expect kids to understand the far reaching consequences of the
> static type system you propose.

But you are aware that eToys do have a static type system, are you? It seems 
as if kids don't have that many problems with static type systems as you are 
claiming.

Cheers,
  - Andreas

----- Original Message ----- 
From: "Andres Valloud" <sqrmax at cox.net>
To: "Squeak" <squeak-dev at lists.squeakfoundation.org>
Sent: Saturday, October 16, 2004 2:29 PM
Subject: Re[4]: Squeak-dev Digest, Vol 22, Issue 20


Hello Andreas,

Saturday, October 16, 2004, 12:01:19 PM, you wrote:

AR> Okay, so where precisely did I claim that one would need static types to
AR> write clear code? (for that matter where did I refer to code quality at
AR> all?)

Here is what you answered to:

~~~~~~~
>> There are things about static type checking that I miss when
>> programming in dynamically typed languages, for example warnings about
>> missing methods, indeed there are things that I'm glad to get rid of
>> too.
> How would you detect a missing method in a dynamic system? Aside from
> the trivial case of there being no method at all of the appropriate name
> (which Smalltalks detect already) what would you do?
~~~~~~~

"I miss some things about static type checking"...

"How do you detect a missing method if a selector with the same name already
exists?"

Those are concerns about code quality and especially runtime defects.

I think you proposed "we need static types".  That addressed the
problem of an object implementing a message - if receivers have types
defined staticly, then you can check when you compile a method to see
that all receivers understand the messages being sent.  So I think that
you indeed suggested static types for Squeak, a la Java for example.

Then you also wrote:

> And suddenly, the whole type system becomes a meta-layer for
> expressing some of the relationships between classes throughout the
> system and that can be useful for many different areas.

In my opinion, the relationship between classes in the system should
be clearly expressed in the code itself.  I do not think it should be
specified in the type system you propose.  Doing so would add a layer
of complexity that I think is unnecessary.  I also think it would
make the code less clear to understand.

Your suggestion of static types, in my opinion, affects how clear code can 
be.

AR> And what does this have to do with a single person understanding a
AR> system?

It's yet another thing that has to be understood in order to do
anything.  It does not help.

It should be clear by now that static types like the one you suggest
actually make code much more difficult to change.  How successfully are
we going to share our work with others if what we do is difficult to
change?

I think we have seen enough examples of that already.

AR> Are you claiming that a statically typed system couldn't possibly be
AR> understood by a single person?

The fact that, on average, projects using staticly typed languages
have higher failure rates than those using non-staticly typed
languages should tell us something about what not to do.

>From another point of view: Smalltalk's point was to teach kids, and
it seems to me it was important to make it late bound.  Therefore I
don't expect kids to understand the far reaching consequences of the
static type system you propose.

>> Smalltalk is powerful because it does NOT have many "features".  It
>> should be kept that way.
AR> Well you know my opinion on that, don't you?! ;-)
AR> Smalltalk ~~ Squeak.

I don't want | Squeak - Java | < epsilon, either.

Andres.





More information about the Squeak-dev mailing list