Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
doc:package:why_lisp [2015/05/08 16:22] – gkazhoya | doc:package:why_lisp [2015/05/08 16:53] (current) – gkazhoya | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Why Lisp? ====== | ====== Why Lisp? ====== | ||
+ | |||
+ | ==== Advantages ==== | ||
There is a number of reasons why Common Lisp was chosen as the language for CRAM. | There is a number of reasons why Common Lisp was chosen as the language for CRAM. | ||
Line 9: | Line 11: | ||
In Lisp, code is represented using standard data types (it is, basically, a List). Thus, code can be assigned to a variable, it can be generated at run-time, i.e., code that was generated on the fly can be executed straight away, using the powerful macros mechanism custom code can also be generated at compile time, and as any other data object code can also be easily modified by other code. That enables for automatic generation and transformation of robot plans. | In Lisp, code is represented using standard data types (it is, basically, a List). Thus, code can be assigned to a variable, it can be generated at run-time, i.e., code that was generated on the fly can be executed straight away, using the powerful macros mechanism custom code can also be generated at compile time, and as any other data object code can also be easily modified by other code. That enables for automatic generation and transformation of robot plans. | ||
- | == Symbols | + | == Symbol |
- | Symbol is a built-in type in Lisp. In conventional programming languages symbolic data would usually be represented either as strings or enumerations, | + | Symbol is a built-in type in Lisp. In conventional programming languages symbolic data would usually be represented either as strings or enumerations, |
== Rapid prototyping == | == Rapid prototyping == | ||
- | Historically Lisp was an interpreted language. Although the implementation | + | Historically Lisp was an interpreted language. Although the compiler |
== Expressiveness == | == Expressiveness == | ||
- | The last but not the least reason for choosing Common Lisp is that it is a very powerful and flexible language and is exciting | + | The last but not the least reason for choosing Common Lisp is that it is a very powerful and flexible language and is fun to program with. In addition to supporting functional programming, |
- | === 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:// | + | 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:// |
- | === Disadvantages of using Lisp === | + | ==== Disadvantages of using Lisp ==== |
The choice of a programming language is, of course, always a trade-off of the advantages and disadvantages of using a certain language for a certain problem. Lisp for CRAM is not an exception. | The choice of a programming language is, of course, always a trade-off of the advantages and disadvantages of using a certain language for a certain problem. Lisp for CRAM is not an exception. | ||
Line 28: | 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, | + | 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, |