ech@spuxll.UUCP (Ned Horvath) (06/13/84)
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=