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