plogan@mentor.com (Patrick Logan) (03/15/90)
In article <8315@hubcap.clemson.edu>
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
(William Thomas Wolfe, 2847 ) writes (excerpts only):
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:
...In particular, the original objectives of Lisp were:
o ease of algorithm prototyping
o concise programs (no declarations)
o powerful data and control structures
o very general constructs
o rich programming environments
o incremental development
o fast compilation
o ease of debugging
These are all desirable things to have in the language and environment
used to develop any software product. If someone doesn't think so,
please tell me why.
...Lisp has been utilized as a "rapid prototyping" environment
for investigating the algorithms and user interfaces for many
"expert systems" being developed...
My understanding of the history of LISP is that the desire for
prototyping productivity over execution speed of end product prompted
programmers to develop the above characteristics. But if they could
also be applied to creating "well engineered" software, would anyone
not want to apply them?
...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.
Does the article show, or can anyone show, what the costs are for both
methods and what the trade offs are? What is the difference between
"weight" and "size"? This sounds like rhetoric, not that I'm unaware
of the traditional performance problems with LISP.
But there has been a lot of work done in the 80's on the performance
of LISP on popular hardware. There has also been a lot of work done on
improving the LISP dialects, especially Scheme but also CommonLISP.
Many arguments over LISP are based on misconceptions or dated
information.
Yes, there are differences between Ada and LISP (Scheme, CL). LISP
usually doesn't allow the programmer as much control over specific
uses of memory. The thread running now about "unboxed" floats in LISP
and Smalltalk like languages is a good example. I'm happy to see
people like Paul Wilson addressing the issue.
There are still a large set of programs that can be developed and delivered
in LISP that are not expert systems or AI at all.
...Lisp development software systems are not appropriate for
deployment because:
o they are too slow, especially on arithmetic
See above. Also there were a couple of MIT reports on MacLISP from the
early 70's on how this is not true in some cases. Guy Steele wrote one
that was preceded by Kent Pittman (corret name? correct spelling?).
Some T reports and theses also talk about this.
Also, and this can be backed up only by hearsay from someone with some
Ada compiler experience, I've heard that Ada compilers still have a
long way to go *and* that the "allowed optimizations" section of the
reference is very limiting. Remember, this is hearsay and not based on
first hand knowledge! I don't want to intentionally spread falsehoods.
One example I heard of was initializing a large number of variables to
the same constant expression sometimes requires evaluation for each
initialization.
o they require extremely large run-time systems
-- 50 megabytes or more for Lisp Machines
What about Chez Scheme from Cadence Research? It requires 0.5 MB per
process, according to their literature. Granted, as the program gets
larger, so do the run time memory requirements, but this is true for
any language. If the program has all the functionality of a LISP
machine then it will require much more memory.
o they do not offer the sort of real-time response
mechanisms required for embedded systems
Not "as is" at this time, I guess. But a practical option is a real
time language written in LISP that uses a LISP development
environment. The end result could be a "safe" and fast program for
running in the true delivery environment. Is there such a thing now?
o they do not do global consistency checks on variable
or function usage
Not in the same way or as thoroughly as Ada. How does ML help in this
matter? It's not inconceivable to add this to a LISP like language.
o they require a choice between "safety" and speed
In some cases, yes. Hardware helps a lot, LISP machines being the best
example, but SPARC being another. I understand all the realities about
popular hardware, but here you see a penalty being paid by the
customer that wants or needs hardware that doesn't support more
powerful hardware.
An argument is sometimes made that LISP like languages, environments,
and hardware only aid the programmer and not the customer. Not true, I
say, since the cost of traditional development and delivery can
include slower development turn-around, leading to delays in product
shipment and reduced or lower quality functionality.
o they are not easily ported to a wide variety of
instruction set architectures.
Not as true these days with Scheme and CommonLISP.
...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.
There is a lot happening with multiprocessing LISPs. I don't know
what's happening with standardization though.
...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 have trouble trusting *any* software system in life threatening
situations. Sometimes I'm given no choice, I guess. Maybe I'd feel a
little better knowing the developers spent an awful lot of time
creating a great number of reliable simulations. That would be greatly
facilitated with a LISP like environment tailored for safety.
Bill Wolfe, wtwolfe@hubcap.clemson.edu
--
Patrick Logan uunet!mntgfx!plogan |
Mentor Graphics Corporation |
Beaverton, Oregon 97005-7191 |