Date: Sat 8 Oct 1988 15:03-EDT From: AIList Moderator Nick Papadakis Reply-To: AIList@AI.AI.MIT.EDU Us-Mail: MIT LCS, 545 Tech Square, Rm# NE43-504, Cambridge MA 02139 Phone: (617) 253-6524 Subject: AIList Digest V8 #97 To: AIList@AI.AI.MIT.EDU Status: RO AIList Digest Sunday, 9 Oct 1988 Volume 8 : Issue 97 More on ... The Grand Challenge (5 messages) ---------------------------------------------------------------------- Date: 26 Sep 88 2110 PDT From: John McCarthy Subject: re: The Grand Challenge is Foolish [In reply to message sent Mon 26 Sep 1988 23:22-EDT.] I shall have to read the article in Science to see if the Computer Science and Technology Board has behaved as foolishly as it seems. Computer science is science and AI is the part of computer science concerned with achieving goals in certain kinds of complex environments. However, defining the goals of AI in terms of reading a physics book is like defining the goal of plasma physics in terms of making SDI work. It confuses science with engineering. If the Computer Science and Technology Board takes science seriously then they have to get technical - or rather scientific. They might attempt to evaluate the progress in learning algorithms, higher order unification or nonmonotonic reasoning. If John Nagle thinks that "The lesson of the last five years seems to be that throwing money at AI is not enormously productive.", he is also confusing science with engineering. It's like saying that the lesson of the last five years of astronomy has been unproductive. Progress in science is measured in longer periods than that. ------------------------------ Date: 27 Sep 88 15:29:56 GMT From: leverich@rand-unix.arpa (Brian Leverich) Subject: Re: Grand Challenges In article <17736@glacier.STANFORD.EDU> jbn@glacier.UUCP (John B. Nagle) writes: > > The lesson of the last five years seems to be that throwing money at >AI is not enormously productive. Recent "big science" failures notwithstanding, the infusion of money into AI may turn out to have been a more productive investment than we realize. As a case in point, consider expert system technology. It seems doubtful that the technology is currently or soon will be capable of capturing human "expertise" in more than a relative handful of freakishly well-defined domains. That doesn't mean the technology is useless, though. Antiquated COBOL programming replaced or substantially increased the productivity of millions of clerks who used to do the arithmetic necessary to maintain ledgers. There still are millions of clerks out there who perform evaluation activities that can be very well defined but are too complex to cost-effectively program, debug, maintain, and document in COBOL. A safe bet is that over the next decade what shells _really_ do is allow the business data processing community to automate a whole class of clerical activities they haven't been able to handle in the past. Unglamorous as it seems, that single class of applications will really (no hype) save industry billions of dollars. Rather than looking at how well research is satisfying its own goals, when talking about the productivity of research it may make more sense to take a hard-headed "engineering" perspective and ask what can be built after the research that couldn't be built before. -- "Simulate it in ROSS" Brian Leverich | U.S. Snail: 1700 Main St. ARPAnet: leverich@rand-unix | Santa Monica, CA 90406 UUCP/usenet: decvax!randvax!leverich | Ma Bell: (213) 393-0411 X7769 ------------------------------ Date: 30 Sep 88 07:53:30 GMT From: mcvax!ukc!strath-cs!glasgow!gilbert@uunet.uu.net (Gilbert Cockton) Subject: Re: Grand Challenges: Expert System Shells replace COBOL In article <1717@randvax.UUCP> leverich@rand-unix.UUCP (Brian Leverich) writes: >A bet is that over the next decade what shells _really_ do is allow the >business data processing community to automate a whole class of clerical >activities they haven't been able to handle in the past. Unglamorous as >it seems, that single class of applications will really (no hype) save >industry billions of dollars. At last, someone in comp.ai lets it slip what ES shells are really being used for (not a revelation to anyone who follows IKBS usage though). Surveys in the UK (d'Agapeyeff, Ince) show that shells are being used to write small (200 rule) systems that do traditional DP processing which probably is beyond realistic COBOL programming. Furthermore (Ince) they are being programmed by casual computer users with no programming background. Someone asked for the 3 achievements of AI and no one answered. I intended to post my 3 to the net, but got diverted by some metaphysics. I vote ES shells the achievement of the decade for: avoiding CS snobbery and turning out restricted natural language end-user programming languages which the untrained user will pick up and write applications in. Shells may be the first step in bringing some form of programming to the masses (but remember that adventure games got there first with restricted natural language). Note that the big shells (Art, KEE etc) fail the test as they replace CS snobbery with IKBS snobbery. The shells in real use tend to be the PC based ones. Note that the human-computer system here is quite powerful, far more powerful than the no-human system aimed at by the AI zealots. If more people in AI understood the classic human factors task allocation problem, they would be more likely to turn out technologies which do help people to use computers, rather than abortive technologies which try to help computers to abuse people. Thank god this fails. -- Gilbert Cockton, Department of Computing Science, The University, Glasgow gilbert@uk.ac.glasgow.cs !ukc!glasgow!gilbert ------------------------------ Date: 2 Oct 88 16:30:57 GMT From: glacier!jbn@labrea.stanford.edu (John B. Nagle) Subject: Re: Grand Challenges: Expert System Shells replace COBOL This is true. What expert systems have, in practice, turned out to be is simply another form of special-purpose programming system for the development of a specific class of applications. Spreadsheets were the first such form to achieve truly widespread use. One could argue about old report-writer systems such as RPG, but such systems were and are generally used by data processing staff. Spreadsheets are more often set up by people who themselves want to analyze the numbers. Programmable database programs for end users, such as Dbase and its successors, followed. Now we have Apple's Hypercard, again, a simplified programming system for end users. Expert systems shells are tools of the same class. They provide a system in which programs for a limited class of problems can be neatly expressed. As such, they are useful, but not a profound breakthrough. About five years ago, I made the statement that when all is said and done, expert systems will be more important than syntax-directed parsing but less important than relational databases. In retrospect, this seems a valid assessment. If this whole technology had simply been called "rule-based programming", the same results probably would have been obtained, with much less controversy. John Nagle ------------------------------ Date: 2 Oct 88 16:58:31 GMT From: leverich@rand-unix.arpa (Brian Leverich) Subject: Re: Grand Challenges: Expert System Shells replace COBOL In article <1680@crete.cs.glasgow.ac.uk> gilbert@cs.glasgow.ac.uk (Gilbert Cockton) writes: > >I vote ES shells the achievement of the decade for: > > avoiding CS snobbery and turning out restricted natural > language end-user programming languages which the untrained > user will pick up and write applications in. Shells may be > the first step in bringing some form of programming to the > masses (but remember that adventure games got there first > with restricted natural language). > Yup. Now I have a nomination for the nth (probably not second or third, but up there...) most significant _real_ contribution of AI, again in the vein of providing new programming tools: knowledge-based simulation languages. Large simulations have traditionally been exceedingly costly to design, debug, and extend, largely because the Fortran or even Simscript code of the models isn't the least bit isomorphic with the physical system being modeled. Modeling trucks moving brainlessly around on a road network was hard; modeling a multi-mode transportation system where management was using heuristics to pursue cost-minimization and other goals was essentially impossible. Enters the object-oriented message-passing paradigm. All of the sudden individual trucks become "trucks" in the model (rather than rows in a matrix), managers become "managers", and "managers" and "trucks" interact by exchanging English-like messages rather than by changing entries in some arbitrary set of matrices. Design, debug, and extension is much easier. No hype - I've used ROSS (RAND's KBSim tool) to build some 4000+ lines of code simulations. A good bet is that this object-oriented message-passing stuff is going to have a considerable impact upon the simulation community. -- "Simulate it in ROSS" Brian Leverich | U.S. Snail: 1700 Main St. ARPAnet: leverich@rand-unix | Santa Monica, CA 90406 UUCP/usenet: decvax!randvax!leverich | Ma Bell: (213) 393-0411 X7769 ------------------------------ End of AIList Digest ********************