jb at speed.net
Mon Oct 6 17:27:42 UTC 2003
> 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.
I've read about those, they seem *very* interesting. In Smalltalk, because
of the way that collections and iterations are commonly dealt with, loop
based off by one errors occur rarely in comparison to curly brace land. Of
course, Smalltalk also has array bounds checking so in general you can't
read/write outside of the bounds of an arrayed object. Both of these limit
your exposure to those types of errors significantly. There are other ways
to generate off by one errors of course, but they don't happen as nearly as
often in Smalltalk.
> 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.
Well, I can only point out that the base Smalltalk classes have been around
and used for over 30 years. There's a little cruft in there of course, but I
can honestly say that I never worry about any of the base classes having
bugs. They work as advertised.
I think the crux of the matter is "To catch it as early as possible". You
believe that you can catch it really early. Like before the program is
'running' or has been 'written'. Unfortunately, in Smalltalk the program is
already running even before you begin to write it.
> 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.
I suffer from both lack of imagination and lack of education, so I rarely
know about what a program should 'expect'. I can guess sometimes, but I
rarely have the insight to understand what code I write may be subjected to
far off into the future. I guess it's some kind of temporal blindness.
> >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*.
Goodness gracious me. You've been drinking the Koolaid to long. Maybe I'm
just totally out of it, could you give an example where this would be a
> 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.
I'll leave out both, thank you.
BTW, this is a much simpler discussion then I let on. I'm not against unit
tests, or assertions or whatever. For example, a unit test is great for
exercising network or file interface stuff, things that are very much like a
well defined state machine. What it boils down to is this. I code. I can
only write so many lines of code, keep them around in my head and be
familiar with them. There are all sorts of estimates as to how may lines of
code that actually is, but I know it's a relatively small number.
There are a couple of problems from my perspective. Most of the programs
that I write tend to be less deterministic than something like a network
driver. I don't really know *exactly* what the programs or what you think of
as libraries are really supposed to do until they are almost already done.
So what I need is a lot of flexibility to get over the hump as it were, so I
can get the damn thing running in the first place.
Another problem that I have with the tests and assertion view of the world
is that it takes up a certain part of the 'lines of code' pool. That's fine;
if you're guaranteed of producing 'results' by adding these facilities.
Unfortunately, and it might be because I'm not that great of a programmer,
I'm just as likely to introduce bugs in the tests and assertions as I am to
introduce it into production code. In fact, any testing of significance
becomes a large program in its' own right, with all of the attendant
problems of large programs. The tester then needs to be tested, etc.
If the test were automatically generated that'd be great. However if I have
to write the test, I'm probably not qualified to do it. I 'expect' things
out the code, whereas other people using my code may expect other things
entirely. Unit tests tend to 'preach to the choir', the code passes the
tests that *I* write. In a group programming environment, say more than 4
people, unit tests seem to make a lot more sense.
The unfortunate part about assertions is that they usually get taken out of
production code. Again, in my experience, it's when a program goes out in
the real world and people start beating on it is when problems really start
cropping up. In general, this is because people try to use the program in
ways that I hadn't forseen during design. I've always said that I could just
write programs that didn't have any users, I'd my job would be much easier.
Instead I just write my little programs, and try to find their bugs when
they pop up. In my experience, the actual parts of programs that I really
think about (like things that I would write assertions for) rarely have any
significant problems. It's always the bits that I've glossed over, not
considered important, or just not understood that always bite back.
More information about the Squeak-dev