Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
doc:package:why_lisp [2015/05/08 16:47] gkazhoyadoc:package:why_lisp [2015/05/08 16:53] (current) gkazhoya
Line 21: Line 21:
  
 ==== Efficiency concerns ==== ==== Efficiency concerns ====
-In terms of efficiency Lisp is generally faster than many languages, such as Python or Ruby, but, slower than, for example, C++ or Java 6 (based on the benchmarks from http://shootout.alioth.debian.org/ by the time of writing). However, CRAM runs on a robot in real-time and the robot usually has enough time to think about its future actions while performing current actions: physical execution of actions is in most cases slower than the computation. In addition, SBCL has many possibilities to improve code using the optimization declarations when really needed.+In terms of efficiency Lisp is generally faster than many languages, such as Python or Ruby, but, slower than, for example, C++ or Java 6 (based on the benchmarks from http://shootout.alioth.debian.org/ by the time of writing). However, CRAM runs on a robot in real-time and the robot usually has enough time to think about its future actions while performing current actions: physical execution of actions is in most cases slower than the computation, so efficiency is not a major concern in CRAM. In addition, SBCL has many possibilities to improve code using the optimization declarations when really needed.
  
  
Line 30: Line 30:
 One of the major problems with Lisp is that it is not widely accepted in the computer scientists community. Due to its functional programming nature it is really hard to get into for people that are used to the traditional imperative programming way of thinking. In the recent years though functional programming seems to finally be finding acceptance in the wider masses, so there is a good perspective also for Lisp. One of the major problems with Lisp is that it is not widely accepted in the computer scientists community. Due to its functional programming nature it is really hard to get into for people that are used to the traditional imperative programming way of thinking. In the recent years though functional programming seems to finally be finding acceptance in the wider masses, so there is a good perspective also for Lisp.
  
-Despite the SBCL compiler being an industrial strength product, as a language, Common Lisp was not designed with industry in mind. Its dynamic typing system, loose encapsulation, allowing for side-effects and the fact that it gives the programmer so much freedom and does not put many restrictions on the programming style, results in Lisp sacrificing robustness and security for expressiveness and ease of rapid programming. Generally, Common Lisp is more suitable for rapid prototyping and testing research approaches than for writing an industrial application. However, please note that CRAM does not claim to be an industrial library and is in fact a research tool.+Despite the SBCL compiler being an industrial strength product, as a language, Common Lisp was not designed with industry in mind. Its dynamic typing system, loose encapsulation, allowing for side-effects and the fact that it gives the programmer so much freedom and does not put many restrictions on the programming style, results in Lisp sacrificing robustness and security for expressiveness and ease of use. Generally, Common Lisp is more suitable for rapid prototyping and testing research approaches than for writing an industrial application. However, please note that CRAM does not claim to be an industrial library and is in fact a research tool.