In Lisp, all code is data. In Haskell, all data is code. | Hacker News Reader

In Lisp, all code is data. In Haskell, all data is code.

enfranchisedmind.com

5 pointsmightybyte9 comments

I was intrigued by the symmetry implied in the title, so I read the article. But there isn't any symmetry. All he means by "all data is code" is that, in Haskell, some things that look like data structures are really functions. That isn't anything like what code=data means in Lisp. Luckily, there are a few other interesting things in the article.

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.

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.

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.

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).

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.

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.

"Java is big like west Texas is big."..... is an interesting analogy used in the article.

I don't know anything about Haskell, but this article makes it sound far more attractive to me than it has in the past.

Reply on news.ycombinator.com