4 ms·

As someone who's never used Lisp before, what's the difference between Lisp and Haskell? I keep hearing old stories about the virtues of Lisp, but it doesn't se

As someone who's never used Lisp before, what's the difference between Lisp and Haskell? I keep hearing old stories about the virtues of Lisp, but it doesn't seem like anyone uses it anymore. Has it just been replaced by newer functional languages?

SamReidHughes 16y ago
Lisp is strictly evaluated, homoiconic, dynamically typed, and dynamic? It's hard for two languages to be more different than Lisp and Haskell, the only thing they have in common is their distance from the origin.
chris_j 16y ago
The main difference between Lisp and other languages (including Haskell) is that Lisp is homoiconic. That is, a Lisp program is represented as a list, a data structure that can itself be manipulated by a Lisp program. This means that a Lisp program can contain macros that can generate Lisp code at compile time (or even at runtime). This might sound dangerous, especially if you have seen C macros or C++ templates being abused, and it is. It also turns out to be rather powerful; you can use macros to implement at lot of things that in other languages can only be implemented by the compiler writer. One popular example is looping constructs: if your Lisp doesn't have a for-loop then you can implement it as a macro. This is how for is implemented in Clojure, my personal favourite Lisp. What about functional languages? Well, Lisp has been around for so long that it pioneered a lot of programming concepts. One of these is functional programming. Later, many purer functional languages took functional programming a lot further, Haskell being a great example. There are many flavours of Lisp today and some, such as Clojure and Scheme, aim to be fairly pure functional languages (and Haskell is the purest functional language that I can think of), whereas others, such as Common Lisp, are less so. Functional programming is only one thing that Lisp has going for it, of course. As I mentioned, Lisp pioneered a lot of concepts which we take for granted today. This essay by pg gives a summary of what made Lisp different and is well worth reading, along with other pg essays on the subject of Lisp: http://www.paulgraham.com/diff.html http://www.paulgraham.com/diff.html
- chris_j 16y ago
  PS - I mentioned that for loops are implemented as a macro in Clojure. I should have said list comprehensions. Have a look at the clojure source here and search for "(defmacro for" to see what I mean. It's awesome to think that, if this hadn't already been in the language, you could have written it yourself. https://github.com/richhickey/clojure/blob/master/src/clj/clojure/core.clj https://github.com/richhickey/clojure/blob/master/src/clj/cl...
- kenjackson 16y ago
  That is, a Lisp program is represented as a list, a data structure that can itself be manipulated by a Lisp program. This means that a Lisp program can contain macros that can generate Lisp code at compile time (or even at runtime). The latter (about Lisp macros) is actually orthogonal to it be homoiconic. What it does mean is that parsing, manipulating, and generating Lisp code is just like generating any other Lisp data structure. But there is nothing stopping non homoiconic languages from adding first-class macros (macros that are written in the language itself).
  - Zak 16y ago
    But there is nothing stopping non homoiconic languages from adding first-class macros This is true, and Nemerle is an example of a language with this feature. That said, it's harder to write macros in non-homoiconic languages. One can write Lisp macros by starting with the desired output and inserting quote and unquote where appropriate. Generating a syntax tree in other languages requires mentally translating them to something like Lisp.
  - papaf 16y ago
    But there is nothing stopping non homoiconic languages from adding first-class macros (macros that are written in the language itself). That is true in theory. However, I struggled with camlp5 [1] for hours to achieve something that could be done trivially with a lisp macro. I'm certain its because the I was having to do much more than rewrite a datastructure. Interestingly, it was this very experience that moved me back to lisp. [1] http://martin.jambon.free.fr/extend-ocaml-syntax.html http://martin.jambon.free.fr/extend-ocaml-syntax.html

SamReidHughes 16y ago

Lisp is strictly evaluated, homoiconic, dynamically typed, and dynamic? It's hard for two languages to be more different than Lisp and Haskell, the only thing they have in common is their distance from the origin.

chris_j 16y ago

The main difference between Lisp and other languages (including Haskell) is that Lisp is homoiconic. That is, a Lisp program is represented as a list, a data structure that can itself be manipulated by a Lisp program. This means that a Lisp program can contain macros that can generate Lisp code at compile time (or even at runtime). This might sound dangerous, especially if you have seen C macros or C++ templates being abused, and it is. It also turns out to be rather powerful; you can use macros to implement at lot of things that in other languages can only be implemented by the compiler writer. One popular example is looping constructs: if your Lisp doesn't have a for-loop then you can implement it as a macro. This is how for is implemented in Clojure, my personal favourite Lisp. What about functional languages? Well, Lisp has been around for so long that it pioneered a lot of programming concepts. One of these is functional programming. Later, many purer functional languages took functional programming a lot further, Haskell being a great example. There are many flavours of Lisp today and some, such as Clojure and Scheme, aim to be fairly pure functional languages (and Haskell is the purest functional language that I can think of), whereas others, such as Common Lisp, are less so. Functional programming is only one thing that Lisp has going for it, of course. As I mentioned, Lisp pioneered a lot of concepts which we take for granted today. This essay by pg gives a summary of what made Lisp different and is well worth reading, along with other pg essays on the subject of Lisp: http://www.paulgraham.com/diff.html http://www.paulgraham.com/diff.html

chris_j 16y ago
PS - I mentioned that for loops are implemented as a macro in Clojure. I should have said list comprehensions. Have a look at the clojure source here and search for "(defmacro for" to see what I mean. It's awesome to think that, if this hadn't already been in the language, you could have written it yourself. https://github.com/richhickey/clojure/blob/master/src/clj/clojure/core.clj https://github.com/richhickey/clojure/blob/master/src/clj/cl...
kenjackson 16y ago
That is, a Lisp program is represented as a list, a data structure that can itself be manipulated by a Lisp program. This means that a Lisp program can contain macros that can generate Lisp code at compile time (or even at runtime). The latter (about Lisp macros) is actually orthogonal to it be homoiconic. What it does mean is that parsing, manipulating, and generating Lisp code is just like generating any other Lisp data structure. But there is nothing stopping non homoiconic languages from adding first-class macros (macros that are written in the language itself).
- Zak 16y ago
  But there is nothing stopping non homoiconic languages from adding first-class macros This is true, and Nemerle is an example of a language with this feature. That said, it's harder to write macros in non-homoiconic languages. One can write Lisp macros by starting with the desired output and inserting quote and unquote where appropriate. Generating a syntax tree in other languages requires mentally translating them to something like Lisp.
- papaf 16y ago
  But there is nothing stopping non homoiconic languages from adding first-class macros (macros that are written in the language itself). That is true in theory. However, I struggled with camlp5 [1] for hours to achieve something that could be done trivially with a lisp macro. I'm certain its because the I was having to do much more than rewrite a datastructure. Interestingly, it was this very experience that moved me back to lisp. [1] http://martin.jambon.free.fr/extend-ocaml-syntax.html http://martin.jambon.free.fr/extend-ocaml-syntax.html