Generics

Phil Hudson phil.hudson at iname.com
Tue Oct 7 22:12:48 UTC 2003


Hi Jim,

>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. 

Must admit that I've been bitten that way once or twice. It's a valid point.

>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.

True again.

>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. 

True too, but that's not the fault of the assertions. Would the program
not have experienced those problems if it had not been instrumented with
assertions? No. Did instrumenting the program with assertions cause those
problems? Again, no.

>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.

I hear that.

>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.

I hear that too.

There's much to be said for the more pragmatic approach you recommend.



More information about the Squeak-dev mailing list