Copy Link
Add to Bookmark
Report

AIList Digest Volume 8 Issue 097

eZine's profile picture
Published in 
AIList Digest
 · 15 Nov 2023

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 <JMC@SAIL.Stanford.EDU>
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 <europe>!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
********************

← previous
next →
loading
sending ...
New to Neperos ? Sign Up for free
download Neperos App from Google Play
install Neperos as PWA

Let's discover also

Recent Articles

Recent Comments

Neperos cookies
This website uses cookies to store your preferences and improve the service. Cookies authorization will allow me and / or my partners to process personal data such as browsing behaviour.

By pressing OK you agree to the Terms of Service and acknowledge the Privacy Policy

By pressing REJECT you will be able to continue to use Neperos (like read articles or write comments) but some important cookies will not be set. This may affect certain features and functions of the platform.
OK
REJECT