Hmm.. So Prolog is the ghost at the (US programming languages) banquet?|
Internet Business Logic
A Wiki and SOA Endpoint for Executable Open Vocabulary English over SQL and RDF
Online at www.reengineeringllc.com Shared use is free
On Thu, Jul 2, 2009 at 2:03 AM, John F. Sowa <sowa@xxxxxxxxxxx>
EB> I think most software engineers would be shocked by John's
> assertion that Java is "LISP in C clothing".
The only software engineers who would be shocked by that idea
are those who had never used LISP (but that would probably
include most of them).
I suggest that you type the two words 'lisp' and 'java' to Google.
That will give you about 4,120,000 hits. (If you type them in the
order 'java' and 'lisp', you get only 1,370,000 hits.)
Either way, you get a lot of articles that compare both languages,
and most of them show that Lisp is far superior to Java in number
of lines of code, execution speed, etc. See, for example,
Lisp as an alternative to Java by Peter Norvig
Norvig, by the way, is now the Director of Research at Google.
Another article with the same title but by Erann Gat from the
Jet Propulsion Laboratory provides data that compares LISP,
C, C++, and Java:
JFS>> LISP is the result of addressing problems that are far more
>> complex than the ones for which COBOL and FORTRAN were adapted.
EB> LISP was designed with a paradigm suitable for different problems.
Actually, FORTRAN and COBOL were single-paradigm languages, but LISP
from the very beginning was a multi-paradigm language that could
handle an enormous range of very different kinds of problems.
The best way to compare FORTRAN, LISP, and COBOL is to look at the
original data structures supported by the first implementations of
1. FORTRAN was designed to process arrays of numbers with execution
speed comparable to good assembly-language code. The original
FORTRAN compiler on the IBM 704 came quite close.
2. COBOL was designed to process data from files of records,
each of which resembled the layout of a punched card.
3. LISP was designed to handle highly irregular data, of which
regular data (FORTRAN arrays and COBOL records) are simple
special cases. A COBOL record can be represented by a LISP list
and a FORTRAN matrix can be represented by a list of lists.
But neither of the other two languages can support lists and
operations on lists without extreme contortions.
JFS>> In any case, I think the pack is not very far behind. When
>> the products start coming out, they will make hand-writtenEB> I'm not so sure...
>> ontologies like Cyc as obsolete as tables of sines and cosines.
That depends on what you're trying to do. I don't believe that
Cyc's goal is a reasonable one to attempt by any means (hand
coding, fully automated, or semi-automated). The following paper,
which describes an approach that we have implemented in several
successful systems (i.e., paid for by people who wanted something
that works), illustrates a less ambitious and far more useful
goal -- a collection of lower-level microtheories or domain
ontologies without a fully axiomatized upper level:
EB> 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
Those are arguments for explaining why things like Cyc have failed
and why many other proposals to do something else that is as
ambitious as Cyc will also fail. I agree with them. That's why
I would never attempt to do anything like that. There's a better
way. See the paradigm.pdf paper.
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
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 (01)