4 ms·

Why Lisp? 3 answers

38 points by prakash 18y ago

diN0bot 18y ago
i see "first to do X" as neutral. maybe it's indicative of more innovation and goodness elsewhere, but maybe it's done better in the next iteration or language. "best to do X" is clearly a good, though, which is listed as part of the 1st reason. an important reason not mentioned is library support. for practical reasons many programmers want not just "a good language" but a language where they don't have to re-invent the wheel or forge new territory (of course, that can be satisfying, too, if one has the time). this is likely the case with any language that has been around a while. i don't know if this is the case with lisp. did that reason seem not important enough for the list, or are libraries/frameworks lacking?
- sctb 18y ago
  The topic of libraries comes up frequently when Lisp is mentioned. If a certain task or problem arises that isn't directly related to or considered one of the main problems that you're trying to solve with your program, you would consider the use of a library to accomplish that task. If there is such a library available, go ahead and use it. If there isn't, Lisp programmers can spend a short amount of time implementing only what they need without generalizing the task. This isn't quite re-inventing the wheel since you have a unique set of constraints, and it's certainly not as onerous a task as writing a generalized library. There are those (Edi Weitz for example) who do tend to implement complete libraries, and the Lisp community is of course grateful for that. Libraries and frameworks can be useful, but they also have the effect of levelling the playing field. Lisp empowers the programmer to `discover' a natural solution to their problem in a unique way.
mojuba 18y ago
every language gets parsed, turned into an AST (Abstract Syntax Tree), and then compiled or interpreted This is one of the most widespread misconceptions about compilers. You don't need to build an AST. All books that give this advice originate from academic environment and are completely out of touch with reality. Unfortunately these books can be credited for the terribly bloated compilers that we are using, including Python and Perl.
- jules 18y ago
  Building an AST will make your job MUCH easier if you want to do any kind of transformation/optimization.
  - mojuba 18y ago
    No, it will not make anything easier, except will just bloat the compiler and slow down the whole process. All kinds of optimizations you probably mean are possible at the level of intermediate/pseudo code, and should be done there together with the other optimization techniques. We can look at specific examples if you wish.
    - eru 18y ago
      Depends on your definition of intermediate code, doesn't it?
      - mojuba 18y ago
        Usually a stack-based language, very close to assembly with a lot of simplifications, e.g. no registers. Because of these simplifications, intermediate code is easier to optimize and to generate native code from.
        eru 18y ago
        I'd extend the definition to include things like GRIN code. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.27.3918 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.27.3...
    - ntoshev 18y ago
      Intermediate code will obfuscate code's intent. Why require from the optimizer to reverse-engineer what you meant from a description at a different (lower) level of abstraction?
      - 18y ago
mattknox 18y ago
BTW, as the author I can say this without offending myself: lisp deserves a better article. I wrote this fast, a long time ago. Although I think the equality thing is a really big deal, I have different and better reasons now. (article forthcoming).

38 points by prakash 18y ago

i see "first to do X" as neutral. maybe it's indicative of more innovation and goodness elsewhere, but maybe it's done better in the next iteration or language. "best to do X" is clearly a good, though, which is listed as part of the 1st reason. an important reason not mentioned is library support. for practical reasons many programmers want not just "a good language" but a language where they don't have to re-invent the wheel or forge new territory (of course, that can be satisfying, too, if one has the time). this is likely the case with any language that has been around a while. i don't know if this is the case with lisp. did that reason seem not important enough for the list, or are libraries/frameworks lacking?

sctb 18y ago
The topic of libraries comes up frequently when Lisp is mentioned. If a certain task or problem arises that isn't directly related to or considered one of the main problems that you're trying to solve with your program, you would consider the use of a library to accomplish that task. If there is such a library available, go ahead and use it. If there isn't, Lisp programmers can spend a short amount of time implementing only what they need without generalizing the task. This isn't quite re-inventing the wheel since you have a unique set of constraints, and it's certainly not as onerous a task as writing a generalized library. There are those (Edi Weitz for example) who do tend to implement complete libraries, and the Lisp community is of course grateful for that. Libraries and frameworks can be useful, but they also have the effect of levelling the playing field. Lisp empowers the programmer to `discover' a natural solution to their problem in a unique way.

mojuba 18y ago

every language gets parsed, turned into an AST (Abstract Syntax Tree), and then compiled or interpreted This is one of the most widespread misconceptions about compilers. You don't need to build an AST. All books that give this advice originate from academic environment and are completely out of touch with reality. Unfortunately these books can be credited for the terribly bloated compilers that we are using, including Python and Perl.

jules 18y ago
Building an AST will make your job MUCH easier if you want to do any kind of transformation/optimization.
- mojuba 18y ago
  No, it will not make anything easier, except will just bloat the compiler and slow down the whole process. All kinds of optimizations you probably mean are possible at the level of intermediate/pseudo code, and should be done there together with the other optimization techniques. We can look at specific examples if you wish.
  - eru 18y ago
    Depends on your definition of intermediate code, doesn't it?
    - mojuba 18y ago
      Usually a stack-based language, very close to assembly with a lot of simplifications, e.g. no registers. Because of these simplifications, intermediate code is easier to optimize and to generate native code from.
      - eru 18y ago
        I'd extend the definition to include things like GRIN code. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.27.3918 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.27.3...
  - ntoshev 18y ago
    Intermediate code will obfuscate code's intent. Why require from the optimizer to reverse-engineer what you meant from a description at a different (lower) level of abstraction?
    - 18y ago

mattknox 18y ago

BTW, as the author I can say this without offending myself: lisp deserves a better article. I wrote this fast, a long time ago. Although I think the equality thing is a really big deal, I have different and better reasons now. (article forthcoming).