Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site spuxll.UUCP
Path: utzoo!watmath!clyde!burl!hou3c!hocda!houxm!houxz!vax135!floyd!whuxle!spuxll!ech
From: ech@spuxll.UUCP (Ned Horvath)
Newsgroups: net.lang
Subject: Re: Bugs as mistakes
Message-ID: <496@spuxll.UUCP>
Date: Wed, 13-Jun-84 09:52:57 EDT
Article-I.D.: spuxll.496
Posted: Wed Jun 13 09:52:57 1984
Date-Received: Thu, 14-Jun-84 00:25:37 EDT
References: <443@whuxle.UUCP>
Organization: AT&T Information Systems, South Plainfield NJ
Lines: 22

The definition of "bug" as "embarrassing error" -- be ashamed, and never
admit it was there in the first place! -- is in sharp contrast to the way
Papert treats bugs in teaching people to program in logo (see "Mindstorms").

Papert is rather fond of bugs, for at least two reasons. First, in an imperfect
universe we often learn from our mistakes: trial-and-error is a most
effective learning mechanism when trodding unfamiliar territory.  Second,
bugs often have serendipitous results: a buggy program may not be "wrong,"
it may be a different (and independently interesting!) program.

I can see merit in both viewpoints.  Perhaps it is simplistic to speak of
bugs as a single species.  A more reasonable taxonomy would distinguish
minor problems like typos, problems due to design error, problems due
to failure to research, and Papert's trial-and-error-cuz-there's-nothing-
better variety.

That last class includes experiments to probe the "corners of the envelope"
where the documentation doesn't TELL you what to expect...anybody here
prepared to claim they never introduced a bug because the documentation was
ambiguous or incomplete?

=Ned=