Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!ucbcad!ucbvax!IU.AI.SRI.COM!LAWS
From: LAWS@IU.AI.SRI.COM (Ken Laws)
Newsgroups: comp.ai.digest
Subject: Re: In Defense of FORTRAN
Message-ID: <563129759.0.LAWS@IU.AI.SRI.COM>
Date: Thu, 5-Nov-87 11:55:59 EST
Article-I.D.: IU.563129759.0.LAWS
Posted: Thu Nov  5 11:55:59 1987
Date-Received: Wed, 11-Nov-87 04:44:08 EST
References: <8711051446.AA00712@ht.ai.mit.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 44
Approved: ailist@kl.sri.com

Good points.

I happen to program in C and have built a software environment that
does provide many of the capabilities of LISP.  It has taken me many
years, and I would not recommend that others follow this path.

My real point, though, was that LISP and PROLOG are also at too low
a level.  The Lisp Machine environment, with its 10,000 predefined
functions, is a big factor in the productivity of LISP hackers.  If
similar (or much better!) libraries were available to FORTRAN hackers,
similar productivity would be observed.  LISP does permit many clever
programming techniques, as documented in Abelson and Sussman's book,
but a great deal can be done with the simple conditionals, loops,
and other control structures of a language like FORTRAN.

The AI community is spending too much time reprogramming graph search
algorithms, connected-component extraction, cluster analysis, and
hundreds of other solved problems.  Automated programming isn't coming
to our rescue.  As Fred Brooks has pointed out, algorithm development
is one of the most intricate, convoluted activities ever devised;
software development tools are not going to make the complexities
vanish.  New parallel architectures will tempt us toward brute-force
solutions, ultimately leaving us without solutions.  It's time we
recognize that sharable, documented subroutine libraries are essential
if AI programs are ever to be developed for real-world problems.

Such subroutines, which I envision in an object-oriented style, should
be the language of AI.  Learned papers would discuss improvements to the
primitive routines or sophisticated ways of coordinating them, seldom
both together -- just as an earlier generation separated A* and
garbage collection.  This would make it easier for others to repeat
important work on other computer systems, aiding scientific verification
and tech transfer as well as facilitating creativity.

					-- Ken Laws


[This applies particularly in my own field of computer vision, where many
graduate students and engineers spend years reinventing I/O code, display
drivers, and simple image transformations.  Trivial tasks such as mapping
buffers into display windows cease to be trivial if attempted with any
pretense to generality.  Code is not transportable and even images are
seldom shared.  The situation may not be so bad in mainstream AI research,
although I see evidence that it is.]