
In Lisp, all code is data.  In Haskell, all data is code. - mightybyte
http://enfranchisedmind.com/blog/2009/01/15/random-thoughts-on-haskell/
======
gruseom
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.

~~~
mightybyte
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
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
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
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
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
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.

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

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

