[Top] [All Lists]

Re: [ontolog-forum] History of AI and Commercial Data Processing

To: edbark@xxxxxxxx
Cc: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "John F. Sowa" <sowa@xxxxxxxxxxx>
Date: Sat, 04 Jul 2009 15:24:34 -0400
Message-id: <4A4FAC72.3010509@xxxxxxxxxxx>
Ed,    (01)

Although I have a high regard for LISP, I also recognize the
importance of using design and development tools that are widely
available in the computing mainstream.  That was the primary focus
of the original note in this thread.  Before commenting on your
comments, I'd like to summarize those issues:    (02)

  1. Staying close to the mainstream (whatever its merits or demerits)
     is essential for commercial success.  First IBM and later MSFT
     proved that point abundantly, despite many demerits (some of
     which are obvious and others less so).    (03)

  2. The leaders in AI have always been academics, who made rational
     design decisions from their perspective, but many of those
     decisions violated point #1.  As a result, most of their major
     contributions took a long time to be accepted by the mainstream.
     Furthermore, the people who later commercialized them were
     usually outside of AI.  As a result, the original developers
     and the field of AI as a whole got little credit.    (04)

  3. Syntax is indeed very important.  It has a major impact on
     readability, writability, ease of learning, ease of use,
     error detection and correction, and ultimately programmer
     productivity.  For most users, the single most important
     feature is familiarity:  the C syntax, for example, violates
     a large number of good design principles, but its familiarity
     caused it to become the dominant notation for professional
     programmers.    (05)

I think we can agree on those issues.  The others get into
details whose impact is less obvious because it's hard to
disentangle them from the impact of many other details.    (06)

JFS>> The only software engineers who would be shocked by the idea
 >> [that Java is LISP in C clothing] are those who had never used
 >> LISP (but that would probably include most of them).    (07)

EB> Exactly. ;-)    (08)

I glad that we agree on that point.  But I would claim that
familiarity is the primary reason for the success of C syntax
over LISP syntax.  For programming, I prefer Python syntax to
either of those, but I love the ease of parsing LISP syntax for
writing or specifying a metalevel processor.    (09)

And by the way, despite my defense of LISP, I admit that we
don't use it at VivoMind.  Following are the languages we use:    (010)

  1. For programming graphics and the system interfaces, we use
     Java -- primarily because of its widespread availability
     on all platforms:  Unix-like (which includes Linux and Mac)
     and the legacy (Ugh!) Windoze.  Like IBM, Oracle, and
     other major developers, we do our development on a Unix
     base (Linux or Mac) and port the results to Windoze.    (011)

  2. For complex AI work, we use Prolog.  The version we use,
     which is developed by one of our partners, Paul Tarau,
     is upward compatible with ISO standard Prolog.  But Paul
     has implemented many goodies and extensions in C for all
     the heavy lifting.  Paul also wrote a compiler that can
     translate the Prolog to Java bytecodes to run on the JVM,
     but he can also compile to C for better performance.    (012)

  3. For optimum performance on major portions of the code,
     we use C.  We also used C++, but the result tends to be
     too bloated, and we are rewriting the C++ parts in C.    (013)

  4. For knowledge representation, we use Common Logic,
     especially the CG dialect, which we represent internally
     in a variety of different ways.  But we also accept
     input in any form that anybody gives us.    (014)

  5. For designing, testing, and debugging new algorithms,
     we use Mathematica, which can be called from our Prolog.
     When we're satisfied that the design is correct, we
     hand translate the algorithms to C.    (015)

  6. Our execution platform is based on the Flexible Modular
     Framework (FMF), which is implemented in different
     versions on Java and Prolog.  The FMF is a robust and
     highly flexible framework that can accommodate any
     modules or agents written in any language whatever,
     including any kind of legacy hardware or software
     located anywhere across the Internet.  See    (016)

     http://www.jfsowa.com/pubs/paradigm.pdf    (017)

EB> Offhand, I would bet that very few of these articles [that
 > compare LISP favorably to Java] were written by people who
 > were given the task of studying the field and making the
 > choice of language for a major software product.    (018)

We chose Java over LISP for reasons along the lines of #1 above.
But as I was trying to say in my notes in this thread, all the
advantages that Java provides today could have been obtained
at least 20 years earlier if the whole world had standardized
on LISP as they did on Java.    (019)

But given the sociology and the shortsightedness of *both*
the AI geeks and the commercial pointy-haired bosses, there
was not a prayer of a chance of a snowball in hell that
LISP could have become that standard.    (020)

However, people who have never heard of LISP have been using
it (as embedded in other software).  CorelDraw, for example,
implemented their own version of LISP (essentially McCarthy's
original LISP 1.0 from 1959) for manipulating all the data
structures needed for vector graphics.    (021)

Another example is MS Word, which generates green squiggles
for ungrammatical sentences.  That grammar checker was designed
and implemented by two of my former colleagues from IBM,
George Heidorn and Karen Jensen, who joined Microsoft in 1991.
Their parser has parsed more sentences of English than any
other program on the planet.  In fact, some people who were
working on NL systems, told their users to check the text
on Word and eliminate the green squiggles before running it
through their own system.    (022)

George wrote that parser in C, but he built the critical parts
on top of his own version of LISP 1.0, which he implemented in C.
So anybody who uses Word could be called a LISP user.    (023)

EB> "Lines of code" has no meaning, especially between such
 > radically different syntaxes as Java and LISP...    (024)

I agree to a certain extent, but the principle difference is
not the syntax, but the semantics.  Either LISP or Java could
be written in a syntax that looked like the other language in
about the same number of lines.    (025)

EB> The more interesting question is about programmer productivity...    (026)

I certainly agree.  For beginners, I would recommend Python.
For experts in any language, the syntax is built into their
fingertips.  But I would give the edge to LISP because of its
ease in writing metalevel programs.    (027)

EB> Choosy managers choose Java because...    (028)

The availability of programmers is important.  But the main
reason why we chose Java over LISP is the availability of
the tools on all major platforms.    (029)

However, we are not going to replace Prolog with Java because
the programmer productivity for writing complex code in Prolog
is an order of magnitude higher than for either LISP or Java.    (030)

For writing programs to analyze everybody's credit rating
and to detect possible fraud, Experian uses Prolog.  In fact,
they are so dedicated to Prolog that the bought the company
Prologia -- which was founded by Alain Colmerauer, who
designed and implemented the first version of Prolog.    (031)

EB> And there were those of us who found ways of creating dynamic
 > lists, record structures, trees and lattices in Fortran.    (032)

Of course.  Alain Colmerauer implemented the first version of
Prolog as an interpreter written in FORTRAN.  And George
Heidorn implemented his first parser by an interpreter written
in FORTRAN.  In the olden days, FORTRAN was often used in
the same way as C is today:  a portable assembly language.    (033)

EB> the original LISP did not have even the basic mathematical
 > function library... The early LISP users did not have those
 > concerns, but the Fortran and COBOL users did.    (034)

In the 1950s and '60s, IBM distributed their software as
open source.  The original LISP users were running on IBM
hardware, and they just called the FORTRAN library routines.    (035)

EB> ... The solution, you may recall, was 'cfacil"' -- a LISP
 > library function that called a C-language subroutine.    (036)

I did not use that solution, since I was at IBM, where the
IBM LISP (also called LISP 1.6 + 0.2i -- the latter for the
small imaginary component) was well integrated with all the
other software available on IBM's VM/370 system.  VM/370,
by the way, was an excellent development platform, which
IBM failed to promote because the pointy-haired bosses
called it "counterstrategic" -- i.e. vastly superior to
what was strategic.    (037)

EB> 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.    (038)

I would make a clearer distinction between the implementation
languages and the users' languages.  There are many different
kinds of languages and users:    (039)

  1. For software designers and implementers, I obviously like
     the VivoMind choices above.  But I won't try to force my
     choices on anyone else.    (040)

  2. For the IT professionals, the most technical are the ones
     who develop and extend interfaces to other software.
     Some of them might use the same languages as #1, but most
     of them would need to connect the interfaces to whatever
     their local installations require.  And all of them would
     need to learn and use whatever formats the AI software
     exposes to the other users (points #3 and #4 below).    (041)

  3. For subject matter experts (SMEs), we (at VivoMind) have
     been getting good results with controlled natural languages
     and various kinds of diagrams.  This is an important area,
     which I believe should explored and exploited in greater depth.    (042)

  4. For the end users, the languages and interfaces are mostly
     determined by the application.  I believe that more can be
     done with natural languages (controlled *and* unrestricted).
     But new breakthroughs can come at any time.  Just note how
     rapidly Wii was accepted by game players (and significantly
     by people who never before played computer games).    (043)

John    (044)

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    (045)

<Prev in Thread] Current Thread [Next in Thread>