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=