John, (01)
Yes, we have very different ways of saying things, and very different
emphasis, I think. (02)
you wrote: (03)
> LISP is the result of addressing problems that are far more complex
> than the ones for which COBOL and FORTRAN were well adapted. (04)
LISP was designed with a paradigm suitable for different problems. (05)
COBOL was designed to be readable by business persons, particularly
those in financial operations. And I agree that most of those problems
were simple in concept. But it is that class of problem, and the COBOL
"record" approach to solution, that gave rise to database technologies. (06)
FORTRAN was designed to do engineering mathematics, and many such
problems are not "simpler" than AI problems. The trick is in converting
the real-world problems to problems that can be solved by numerical
approximations to the calculus. FORTRAN was also widely used for
Operations Research methods in the 1960s and 70s. (A group I worked
with used it to solve shortest-path problems and relaxation problems.)
Around 1960, FORTRAN replaced assembly language as the dominant language
for the image analysis community. And FORTRAN was the basis for
SIMSCRIPT -- the American rival for Simula -- as an early discrete
simulation language. (And while I would never claim that it was the
best tool for the job, I used Fortran for my first major programming
application -- an expert system: a program for assigning matches in a
chess tournament using the Swiss system, for the U.S. Intercollegiate
Chess Championship of 1963.) (07)
My view of programming has always been that you design an algorithm for
solving the problem at hand. Then you determine a rendering of that
algorithm into the language available. Some languages make some
algorithms easier to phrase. But, as long as the language has functions
and some complex information structures, you can create a "service
language" (a function library) that makes phrasing the algorithms
workable. With differences in pomp and circumstance, that is what good
LISP programmers do, and it is the heart of "object-oriented programming". (08)
> Without AI research, LISP would not have been invented, (09)
I suspect that is true. But that same era gave us IPL5 and SNOBOL and
other languages with non-Algol paradigms. And all of those were about
something we would now call AI. (010)
> but by the mid 1990s,
> the state of the art had progressed to where LISP in C clothing
> (i.e., Java) became a very successful language. (011)
For a change, I won't disagree with this at all. ;-) OTOH, I think most
software engineers would be shocked by John's assertion that Java is
"LISP in C clothing". (012)
John's contention echoes my observation above -- that the "semantic
distance" between LISP and OOPLs is not that great, although the
languages have radically different terminologies and grammars. The
unifying concept is "applicative programming". Java is an inherently
procedural language that is designed to allow programmers to create an
applicative function language and to write applicative statements. LISP
is an inherently applicative language. (013)
The observation I would make is that not all AI is primarily applicative
programming. There are whole segments of AI that are all about
probabilities and statistical algorithms, and in those areas, Java is
barely adequate and LISP is poor. (And that is because the languages
designed to support such algorithms were Fortran and later C; and the
high quality function libraries are written in and for those languages.) (014)
> ...
> Yes, I believe that the technology for extracting information
> from texts in an automated or semi-automated way is rapidly
> developing. I believe that our little company has some leading
> edge products, and we're trying to stay ahead of the pack.
>
> In any case, I think the pack is not very far behind. When
> the products start coming out, they will make hand-written
> ontologies like Cyc as obsolete as tables of sines and cosines. (015)
I'm not so sure. Even assuming the extraction is reliable, and
self-testing, the problem is to find text that was written with the same
kind of discipline and attention to consistency that has been lavished
on carefully crafted ontologies. Scientists tend to write that way,
because it is part of their discipline to make no claim broader than
what is supported by the evidence and analysis. But in many other
trades, including many engineering disciplines, insight and
generalization is the hallmark of the respected texts, even though the
authors acknowledge that there are many exceptions. The idea is to
cover 90% of the cases with a few useful concepts, promoting an
understanding of the domain that isn't confused by a wealth of details.
And the best texts identify the warning signs for exceptional cases as
well. But for ontologies, there is no For90% x qualifier (except in
fuzzy logic). (016)
A colleague pointed out to me that biologists are uncomfortable saying
things like "every X is a Y". They prefer to say, "an X is considered
to be a Y". What they mean is: "Every X has all the properties of Ys
that we know about or care about. But it is possible that we will
discover some obscure common property of Ys that Xs don't have, or that
the biophysical way in which X actually exhibits some property is very
different from most Ys." That is the scientist's discipline. It is a
problem for those who take an epistemological view of ontologies. It is
much less a problem if we consider ontologies to be knowledge engineered
to some purpose(s) at some time. Upon reflection, many respected texts
constitute knowledge engineered to a purpose (and time). And as such,
they are just as good as any other carefully crafted ontology. (017)
-Ed (018)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 (019)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (020)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (021)
|