John F. Sowa wrote: (01)
> 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). (02)
Exactly. ;-) (03)
> 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. (04)
Offhand, I would bet that very few of these articles were written by
people who were given the task of studying the field and making the
choice of language for a major software product. (05)
"Lines of code" has no meaning, especially between such radically
different syntaxes as Java and LISP. We can argue about the relative
efficiencies of JVMs, LISP machines and LISP compilers, and it would be
equally meaningless, unless there is a radical difference in performance
of the same algorithm on the same platform. (06)
The more interesting question is about "programmer productivity":
- if you give two journeyman programmers the same algorithm set to
write, what is the length of time to correct running code?
- if you give two different journeyman programmers the task of
modifying the algorithms written by the first pair to add a feature,
what is the length of time to correct running code? (07)
(Of course, finding two journeyman LISP programmers might be difficult,
because all surviving LISP programmers are experts. One of my
colleagues of 1975 described LISP as a "write-only language". His boss
immediately countered that, since all LISP programs that work are
perfect, one never needs to read them. ;-)) (08)
Choosy managers choose Java because
- the pool of journeyman programmers is much larger,
- disciplined development environments are commonly taught with the
language, and
- there is a lot more off-the-shelf library tooling they can use.
Overall, that means lower cost of implementation and maintenance, even
when LISP may technically be the better tool for the job. (09)
> 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. (010)
What you mean is that the single paradigm of LISP is more general.
Adding prog variables and procedural crap to LISP created the second
paradigm the hard way. (011)
> The best way to compare FORTRAN, LISP, and COBOL is to look at the
> original data structures supported by the first implementations of
> those languages:
>
> 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. (012)
Yes. That was John Backus' objective. And it is worth noting that
crunching numbers was the primary activity of 1950s computers and the
large computers of 1960-65. (013)
> 2. COBOL was designed to process data from files of records,
> each of which resembled the layout of a punched card. (014)
That is, were organizations of mixed information content divided into
hierarchical structures with fixed size information units. COBOL also
supported multiple different record structures in the same file,
multiple input sources and multiple output files. For COBOL and its
early database derivatives, the big issue was organizing and accessing
bodies of information, with generally very simple actual data processes. (015)
> 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. (016)
Absolutely. But there are very few mathematical or engineering problems
that involve arbitrary list structures, and the same is true of business
data processing. And there were those of us who found ways of creating
dynamic lists, record structures, trees and lattices in Fortran. A
number of Ops Research algorithms need them. (When all you have is a
hammer...) (017)
OTOH, the original LISP did not have even the basic mathematical
function library (the first reliable one was in MacLisp) and it had
essentially one input source and one output. As late as 1980, it was
difficult to get LISP programs to read data from mag tape or disk
(unless they were written by the same LISP library) or to read any data
that wasn't character codes. The solution, you may recall, was
'cfacil"' -- a LISP library function that called a C-language subroutine. (018)
The early LISP users did not have those concerns, but the Fortran and
COBOL users did. So I think you are comparing apples and bamboo here.
Each of these languages was designed to a purpose, and each was a better
tool for that purpose than the others. (019)
This started with John's characterizing LISP as an "AI language". I
will agree that LISP was better designed to support the kinds of
programs/algorithms that were "AI" of 1960-1980, or at least better than
languages like Fortran and COBOL and PL/I and Basic and the 101 Algol
derivatives. But unlike Prolog, for example, there is no intrinsic AI
feature of LISP, unless it be dynamic programming. That was my point. (020)
And since 1980, we have seen a lot more rules languages and FOL
languages and description logic languages and hybrids like F-logic, and
more use of good old Prolog. All these languages have tooling support
that actually does some kind of automated reasoning. That is what I
think of as "AI languages" now. (021)
The question is: What is the next generation? (022)
And John (unsurprisingly) went there: (023)
> 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:
>
> http://www.jfsowa.com/pubs/paradigm.pdf (024)
Thanks! (025)
-Ed (026)
--
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 (027)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (028)
_________________________________________________________________
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 (029)
|