Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!iuvax!cica!tut.cis.ohio-state.edu!cs.utexas.edu!samsung!uunet!zephyr.ens.tek.com!tektronix!sequent!mntgfx!plogan From: plogan@mentor.com (Patrick Logan) Newsgroups: comp.lang.misc Subject: LISP & Ada (was: Re: problems/risks ...) Message-ID: <1990Mar14.180100.29899@mentor.com> Date: 14 Mar 90 18:01:00 GMT References: <14312@cbnewsc.ATT.COM> <8315@hubcap.clemson.edu> Organization: engr Lines: 169 In-reply-to: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu's message of 11 Mar 90 19:40:13 GMT 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 |