Generics

Phil Hudson phil.hudson at iname.com
Mon Oct 6 13:14:24 UTC 2003


>Of course, I view your whole type "problem" a little differently than the
>curly brace world. 

Type inconsistency is only one of a list of programmer error *classes*
which can and should be caught by assertions in your code. Let's forget
type safety and focus on off-by-one errors - I assume everyone agrees
these do have meaning and do happen in Smalltalk.

>You see, I found out a long time ago that I'm not a very
>good compiler; it seems that machines are much better at it than I am. The
>time that the curly brace crowd spends statically typing (and even more
>entertaining, the invariable circumvention of static typing) is time that I
>would rather spend writing programs that actually do something.
>
>Personally, I think it's ironic that people write programs called compilers
>that force users to 'pre-compile' languages before the compilers actually
>work. As an example, ask a ten year old which one of these are not some sort
>of numbers:
>
> 7   6.3  4/5
>
>Why should I have to (or want to) tell my machine what's obvious at a
>glance? At the same time, it's easy to understand:
>
> 7 + 6.3 + 4/5
>
>[ In Squeak the correct syntax is:
>      7 + 6.3 + (4/5)
>because of operator parsing precedence, but it's still pretty close and
>illustrates the idea.
>]
>
>You'll point out, "That's great, but what happens if the program passed
>something invalid? E.g"
>
> 7 + 6.3 + 'badger'
>
>It's obviously an error. That hopefully would never happen in curly brace
>land. You're right there. The question really comes down to what is the cost
>of catching this error, and where do you catch it?

And I answer: the cost progressively diminishes as you re-use well-
factored, well-instrumented code; the place (or more precisely the time)
to catch it is as early as possible.

> To me it's not a compile
>time error, it's a run time error. This should be dealt with at run time
>with something like an exception or being thrown out to an interactive
>debugger. I'll point out that the number of times that I've actually have
>seen something like this happen in the last five years of daily use is
>extremely small. 

There are a number of possible explanations for this. The first is that
you consistently make few or no non-obvious and non-trivial
implementation errors. I have no problem with that, other than envy :)
Other explanations include luck and handling an error in such a way as to
hide it rather than fix it. However, you have not proved the negative:
that your code would not have had fewer defects if it had been
instrumented with assertions.

>When it did happen, it pointed to much deeper flaws in the
>program that probably could not have been solved by static typing. Problems
>like those usually means something is really messed up; related to program
>logic errors/stupidity, not semantic problems.

This is exactly the argument for using assertions - not necessarily
assertions about type, but assertions about any condition you know or
expect to be true.

>The reason that this  is a disaster in curly brace land is the it crashes
>the program. 

*NO*. It's what you want, expect, need and hope for, it isn't a disaster.
Tough one to grasp at first, very counter-intuitive I admit, but a real
gold-mine for those who try it out (at least in curly brace land). You
want every assertion to crash your app *if and only if it fires*. If you
can't predict, control or explain a condition, then don't assert it (for
instance, my network connection hasn't gone away, or that file is just
where I left it). You should only assert what you can reasonably expect
to control (I have already determined that my user is in neither timezone
x nor y, so I assert that they are in timezone z. I defined the set of
available timezones, after all).

>That doesn't seem like very robust behaviour, though I guess
>you could make the argument that the program isn't correct and needs to
>terminate. That's a hard decision to live with, because there are very few
>'correct' programs. 

There are very few *robust* programs. Assertions do not guarantee
correctness; they detect or prevent defects that you can predict may
occur in your code, based on your own and others' experience.

>The next argument that comes up is that the only way to really make sure
>that programs are 'correct' is by rigorous tests. In Squeakland you'll hear
>a lot about that, usually referred to as 'SUnit'. It seems like a more
>reasonable place to try to catch a party gone out of bounds. Of course, I'm
>not a test guy either ...

As I've said before, I'm not proposing instrumenting your code with
assertions as an alternative to SUnit, but rather as a complement to it.



More information about the Squeak-dev mailing list