Susan Ennis
This is the first of what are hoped to be a series of columns devoted to presenting the point of
view of the users of LISP. There are two conditions needed to support a column of this kind.
The first and most important is that real users of LISP exist in the real world. I am not talking
about university types, implementers of large software packages, or researchers in high-priced
think tanks. I am talking about the possibility that there are application programmers
in various companies spread across the breadth of the land (world?) who are turning to LISP
as a viable programming language for applications instead of using FORTRAN, C, Ada, or
even (heaven forbid) COBOL.
The other condition needed to support a column of this kind is that the first issues of it need
to reach the intended audience and potential contributors. If you are not yourself an application
programmer but you know someone who does use LISP, please pass this first effort
along.
At the present time there seem to be more reasons why applications programmers
cannot use LISP than the opposite. There are several reasons for this attitude that I am aware of,
and I would solicit more reasons from the (supposed) audience.
Inadequate definition of concepts
One of the major hindrances to the full use of LISP is the lack of a standard language
that can be understood by the non-initiated. Many times in talking with the
implementers of LISP systems I have been given the answer that "... If you understand the way
that xxxxx is implemented, then you will understand how yyyyy works..." Fill in your favorite
constructs for xxxxx and yyyyy. I do not think that I need to know how a system is implemented
in order to make effective use of the system. Admittedly there have to be mental models of the way
that systems operate. Several interesting articles have been written1
about the use of editors and the mental models that users have of them. It is most
interesting to note that the mental models are often completely wrong -- but that they work.
What I am arguing against is a requirement that the use really understand the implementation.
|
Implementation Base
Another inhibitor to the extensive use of LISP is that the best versions of it have
existed on esoteric hardware. There are versions on PC's and on VAX's and on the CRAY, but
there are no really good versions on IBM machines and most of the commercial systems
are being built on IBM machines (I should mention that there is a very good version of LISP on
the IBM Machine under the VM operating system, but VM is a minor part of the installed IBM base and the version
is incompatible with all other versions of LISP). This situation is improving and versions of LISP
are beginning to appear on more 'normal' hardware.
Speed for Comercial Applications
Another problem is the speed of LISP.
There are still people who have heard horror stories about the speed of the language as it was implemented
ten or so years ago. There is not an awareness of the efficiency of the modern implementations of LISP. If the language
is going to receive wide-spread use then this myth is going to have to be debunked.
Lucid is trying to breach the barrier of user acceptance with their offer to assist in the construction
of prototypes in order to prove that their implementation of LISP is "almost as fast as C." One hopes that they
will be successful.
|
*****************
1
This column shall be distinguished by a complete nbsense of bibliographic references unless overwhelming
public opinion dictates otherwise.
Prev Article
Start of This Article
Next Article
Copyright © 2009, Mary S. Van Deusen
|
