4 ms·

There is symmetry, but the point of the symmetry is that it's going in a different direction. So a very broad, liberal interpretation could be this: Lisp makes

There is symmetry, but the point of the symmetry is that it's going in a different direction. So a very broad, liberal interpretation could be this: Lisp makes everything data and Haskell makes everything a function (code). I don't know how useful this generalization is, but it's an interesting way to look at it.

gruseom 18y ago
Sorry, but if you say "In Haskell, data=code the way that code=data in Lisp," you're implying a symmetry that isn't there: once you read the article to see what the two language qualities being contrasted are, they turn out not to be shaped anything like each other. I find it hard to imagine what the general case of data=code would even mean. In order for data to be code, some programming language implementation has to understand the data and be able to execute it, in which case the data was already code (or transformable into code) to begin with. Another thing: what the article uses to distinguish Haskell from Lisp -- using functions in a way that looks like a data-structure -- is something I do in Lisp all the time. So this just isn't a distinction. I'm not trying to pick on either Haskell (which I'd love to learn someday and which is obviously not Lisp) or the article (which makes some interesting points). It's just that most of what people say about Lisp in blog posts is kind of uninformed, and drawing this kind of distinction is harder than it seems.
- mightybyte 18y ago
  The fact that the order is switched implies that this isn't an equivalence relation. The word "is" has many English interpretations and doesn't adequately describe what's going on. Logical implication is probably a lot closer here. I might rewrite it as "In Lisp, code -> data. In Haskell, data -> code." This is more about the converse of a statement than the symmetric property of an operator. A statement and its converse do exhibit some symmetry. To understand what this means on the Haskell side, you need to learn about lazy evaluation and thunks.
  - gruseom 18y ago
    I know what lazy evaluation and thunks are. I work with them every day (in Lisp, as a matter of fact). The problem with your statement is it isn't true. One might call it a sloppy overgeneralization, but even the thing it's sloppily overgeneralizing isn't true (as I explained: Lisp programmers use functions to represent data structures all the time).
    - mightybyte 18y ago
      How is it a false statement to say that Lisp allows code to be treated as data by virtue of its simple syntax, and that Haskell treats data as code because of its default to lazy evaluation implemented with thunks? That's all I'm saying. I thought this way of looking at it was an interesting contrast. I find the data structure-function half of the point less interesting.
      - gruseom 18y ago
        Ok! I like your first sentence there. It wasn't at all clear to me that that was your point. I'm not sure if I was being obtuse or you were being obscure or both - normally I'd go back and check, but I don't have time right now.

gruseom 18y ago

Sorry, but if you say "In Haskell, data=code the way that code=data in Lisp," you're implying a symmetry that isn't there: once you read the article to see what the two language qualities being contrasted are, they turn out not to be shaped anything like each other. I find it hard to imagine what the general case of data=code would even mean. In order for data to be code, some programming language implementation has to understand the data and be able to execute it, in which case the data was already code (or transformable into code) to begin with. Another thing: what the article uses to distinguish Haskell from Lisp -- using functions in a way that looks like a data-structure -- is something I do in Lisp all the time. So this just isn't a distinction. I'm not trying to pick on either Haskell (which I'd love to learn someday and which is obviously not Lisp) or the article (which makes some interesting points). It's just that most of what people say about Lisp in blog posts is kind of uninformed, and drawing this kind of distinction is harder than it seems.

mightybyte 18y ago
The fact that the order is switched implies that this isn't an equivalence relation. The word "is" has many English interpretations and doesn't adequately describe what's going on. Logical implication is probably a lot closer here. I might rewrite it as "In Lisp, code -> data. In Haskell, data -> code." This is more about the converse of a statement than the symmetric property of an operator. A statement and its converse do exhibit some symmetry. To understand what this means on the Haskell side, you need to learn about lazy evaluation and thunks.
- gruseom 18y ago
  I know what lazy evaluation and thunks are. I work with them every day (in Lisp, as a matter of fact). The problem with your statement is it isn't true. One might call it a sloppy overgeneralization, but even the thing it's sloppily overgeneralizing isn't true (as I explained: Lisp programmers use functions to represent data structures all the time).
  - mightybyte 18y ago
    How is it a false statement to say that Lisp allows code to be treated as data by virtue of its simple syntax, and that Haskell treats data as code because of its default to lazy evaluation implemented with thunks? That's all I'm saying. I thought this way of looking at it was an interesting contrast. I find the data structure-function half of the point less interesting.
    - gruseom 18y ago
      Ok! I like your first sentence there. It wasn't at all clear to me that that was your point. I'm not sure if I was being obtuse or you were being obscure or both - normally I'd go back and check, but I don't have time right now.