Xref: utzoo comp.lang.c:26813 comp.lang.misc:4416
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucsd!ucsdhub!hp-sdd!ncr-sd!ncrcae!hubcap!billwolf%hazel.cs.clemson.edu
From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 )
Newsgroups: comp.lang.c,comp.lang.misc
Subject: Re: problems/risks ...
Message-ID: <8315@hubcap.clemson.edu>
Date: 11 Mar 90 19:40:13 GMT
References: <14312@cbnewsc.ATT.COM>
Sender: news@hubcap.clemson.edu
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
Lines: 88

From article <14312@cbnewsc.ATT.COM>, by lgm@cbnewsc.ATT.COM (lawrence.g.mayka):
>In article <6421@eos.UUCP> woody@eos.UUCP (Wayne Wood) writes:
>>  i agree.  if we followed everyboy's advice on what was dangerous in a 
>>  programming language, we would all be programming in LISP.
> Well, I'm glad someone finally admitted it!  Let me know if you
> need a list of commercial Common Lisp implementations. :-)

   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:

      ...because Lisp was developed for use within the research 
      community, its objectives were considerably different from
      those of a language such as Ada, which is tuned for applications
      deployment.  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

      ...Lisp has been utilized as a "rapid prototyping" environment
      for investigating the algorithms and user interfaces for many
      "expert systems" being developed... 

      ...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. 

      ...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 do not do global consistency checks on variable
              or function usage
         o they require a choice between "safety" and speed
         o they are not easily ported to a wide variety of
              instruction set architectures.

      ...At least one defense contractor has taken the idea of "Lisp
      as a specification language" to a certain conclusion, and produced
      a system called "InnovAda".  InnovAda is the direct interpretation
      of Zetalisp's Flavors object-oriented programming constructs as a
      specification language for Ada, except that the executable code
      within the bodies of the Flavor definitions must be valid Ada code
      instead of Lisp code.  This specification is then processed by the
      InnovAda translator to produce legal Ada source code by expanding
      the Flavor constructs.  (A system called "Classic Ada" has similarly
      grafted the object-oriented ideas of Smalltalk onto Ada.)  
 
      ...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.

      ...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.

      [Remainder of the paper discusses type inferencing during the
       automatic (but extremely slow) translation of Lisp code into Ada]


      Bill Wolfe, wtwolfe@hubcap.clemson.edu