Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/17/84 chuqui version 1.7 9/23/84; site daisy.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!sdcrdcf!hplabs!nsc!daisy!david From: david@daisy.UUCP (David Schachter) Newsgroups: net.works Subject: Re: "look for bugs" Message-ID: <45@daisy.UUCP> Date: Sat, 9-Feb-85 01:46:38 EST Article-I.D.: daisy.45 Posted: Sat Feb 9 01:46:38 1985 Date-Received: Wed, 13-Feb-85 01:50:25 EST References: <524@topaz.ARPA> Reply-To: david@daisy.UUCP (David Schachter) Organization: Daisy Systems Corp., Mountain View, Ca Lines: 31 Summary: Why not a programming methodology that emphasizes >>avoidance<< of bugs? Do it right the first time! I use such a methodology but it is entirely manual: the language I use and the programming environment in which I use it doesn't have any automatic support for preventing bugs. Make an analogy: writing a program is similar to talking to a human being. Yet the computer always mis-understands what we say: we have to repeat and repeat, with minor modifications on every repetition to have the computer understand. This is called "debugging". But when talking to a human being, our discourse rarely requires repetition. There is enough redundancy in the language and the communications channel to avoid mis-interpretation most of the time. Perhaps a programming environment that "understands" programming and, more importantly, the application to which the program will be put is needed. Such an environment would be able to deduce what you meant and correct minor errors. Just a small matter of AI programming (Artificial Intelligence.) [That is sarcasm, of course.] Last year, some chaps from M.I.T. presented the Thursday Afternoon Lecture to the R & D staff here at Daisy and discussed a start on such a project. They called it "The Programmer's Apprentice." I wasn't too enamoured of it: it seemed like a smart macro processor more than anything else. But at least it is a start at >>program synthesis<<. Tell the machine >>what<< you want. Let it figure out >>how<< to get it done (what sort routine to use, how to structure the menus, etc.) Do it right the first time! In college, I used a batch PL/I interpreter called PL/C from Cornell. It was reasonably good at correcting simple errors. This saved two re-runs for me, on the average. [This article represents only my opinions, not those of my company.] {N.F.Q.}