[ I have removed comp.lang.c, and added comp.lang.lisp, to the newsgroup
list for this discussion. ]
In article <····@hubcap.clemson.edu> ·····························@hubcap.clemson.edu writes:
> Here's a summary of the advantages and disadvantages of Lisp, from
> the article "The Automatic Translation of Lisp Applications into Ada",
> appearing in the Proceedings of the Eighth Annual National Conference
> on Ada Technology:
...
> ...While Lisp maximizes the productivity of the prototyping
> phase of development, it trades off this productivity for
> increases in cost, weight, and size, and decreases in speed,
> safety, and maintainability.
These disadvantages are application- and implementation-dependent
generalizations. The alleged loss of safety and maintainability
is highly debatable, as well as being highly dependent on one's
definitions and criteria.
> ...Lisp development software systems are not appropriate for
> deployment because:
>
> o they are too slow, especially on arithmetic
> o they require extremely large run-time systems
> -- 50 megabytes or more for Lisp Machines
> o they do not offer the sort of real-time response
> mechanisms required for embedded systems
...
> o they require a choice between "safety" and speed
Again, application- and implementation-dependent generalizations.
> o they are not easily ported to a wide variety of
> instruction set architectures.
Simply untrue. Common Lisp is available on all major processor
architectures.
> ...As a result of the decision by the Common Lisp committee
> to delay action on a multiprocessing standard, Common Lisp
> has not failed as a language for real-time control; it was
> never considered for this task. As a result, Lisp cannot
> currently be viewed as an appropriate vehicle for expressing
> real-time constraints or concurrent control in an embedded system.
This of course assumes that one's application requires processes
(in the computer science sense of "an independent thread of
execution"). Some real-time, concurrent-control applications are
more amenable to a finite-state machine approach anyway.
It is indeed sad, however, that the de facto standard Common Lisp
multiprocessing constructs (PROCESS-RUN-FUNCTION and friends) were
not ruled de jure into the ANSI standard.
> ...Many existing Lisp systems attempt to provide both software
> development and applications delivery with the same software.
> Their "solution" to the problem of efficient code for application
> delivery is to perform debugging with the SAFETY parameter set to
> the highest level; when sufficient confidence has been reached with
> the program, more efficiency is gained (at the expense of safety) by
> setting SAFETY to the lowest level. This method of achieving speed
> by increasing the risk of field failure is unacceptable for most
> applications. While the benefits of additional speed are greatly
> appreciated by the customer for a while, the risk of sudden and
> catastrophic failure which can result from the elimination of the
> run-time checks is not worth the increased speed. As expert systems
> find their way into embedded applications such as graceful nuclear
> power plant shutdown and a "pilot's associate", the lowering of
> safety standards in the software is not to be tolerated.
I agree that the "solution" of lowering SAFETY is a basically
unacceptable tradeoff. Common Lisp vendors are challenged to
provide acceptable execution speed *without* a loss of run-time
safety. To some extent the better vendors are meeting the
challenge already, but they must continue to make progress in this
area if they expect to remain competitive.
Lawrence G. Mayka
AT&T Bell Laboratories
···@ihlpf.att.com
Standard disclaimer.