4 ms·

I have a different view: Everyone knows what homoiconicity is supposed to mean, however, it is not actually a feasible thing to achieve completely and so peopl

I have a different view: Everyone knows what homoiconicity is supposed to mean, however, it is not actually a feasible thing to achieve completely and so people use the word approximately.. In my mind I transform "lisp is homoiconic" into "lisp is more homoiconic than most other languages" that is to say, they are closer to achieving this impossible idea. Really you could let go of this particular "fancy word" (after all it's not like it's the only needlessly complex programming language theory jargon...) and just call it "syntax consistency" or something along those lines. I sympathize with your stance, precision is important, but people generally don't treat words with any respect so it's somewhat of a futile endeavor.

galaxyLogic 6y ago
That makes me think of "pure languages". Some languages are "pure" because they have no side effects? Yes maybe but which practical programming languages have no side-effects? So similarly as you state about homo-iconicity some languages are simply purer than others.
- DonaldPShimoda 6y ago
  The use of "pure" in this case isn't to say "better", but rather to do with a mathematical viewpoint. In math, if I say "x = 3" and then "y = x + 2", it is true that "y = 5" and nothing else (assuming our regular understanding of addition is given). In programming, it might also have come to pass that some data was output to the console, and some logging took place, and maybe an HTTP request or two were carried out in the interest of making that evaluation. These are not "pure" mathematics; side-effects are impure because they are not accounted for directly in the semantics. Purity is not on a scale. Either a language is pure, or it isn't. Nobody made any claim that purity is something to strive for in a language. Haskell has it because it was designed specifically to be a language where academics could carry out their "What if?" fantasies (which is catalogued in "A History of Haskell", a paper from HOPL III (2007)). I will say that purity is useful in most practical programming — just not at the top level. The more purity you have in your code (by which I mean, the fewer side-effects that are not evident in the type system), the easier it is to make changes to your code and to use it with abandon. The more side effects you have, the harder it is to restructure code and reason about how things work. So within the implementation of a particular application, there might be regions of purity and then (encompassing) regions of impurity. But a given function is either pure or impure — no gradient to it at all.
  - tome 6y ago
    > Purity is not on a scale. Either a language is pure, or it isn't. This is not quite right. "Purity" mean that with respect to some unspecified by fine-grained semantics various pairs of programs are equivalent. For example, in the denotational semantics of Haskell the following are equivalent let x1 = rhs x2 = rhs in body and let x = rhs x1 = x x2 = x in body But they are not equivalent under the operational semantics. The former allocates two closures, the latter one. The "scale" of purity then is measured by how fine-grained the semantics is. Haskell is pure at the "scale" of denotational semantics, but not at the scale of operational semantics.
    - DonaldPShimoda 6y ago
      Ooh I had not heard "purity" defined this way previously in such explicit detail, but it makes perfect sense and I really really like it. Thank you so much for giving me better words for this going forward! Edit: I think, though, that my point kind of still stands in that, with respect to a specific level of semantic detail, a language is either pure or it isn't. Further, I think it isn't useful to compare Language A at Semantic Level 3 to Language B at Semantic Level 1 to compare purity; you're generally going to be sticking to one level of semantic detail at a time, and within that lens all languages will either be pure or impure. Right? Hmm maybe I need to think on this more.
DonaldPShimoda 6y ago
> they are closer to achieving this impossible idea. But what is the impossible idea? What is homoiconicity? Can you give a succinct definition that is consistent with your usage? I don't meant this to sound so antagonistic, but I've seen multiple times where people try to argue in favor of it and come up short when pressed for details. Unfortunately, I do not think I am sufficiently skilled to carry the debate forward. I really recommend looking through Shriram's Twitter exchange to see some of his rebuttals on the topic.

galaxyLogic 6y ago

That makes me think of "pure languages". Some languages are "pure" because they have no side effects? Yes maybe but which practical programming languages have no side-effects? So similarly as you state about homo-iconicity some languages are simply purer than others.

DonaldPShimoda 6y ago
The use of "pure" in this case isn't to say "better", but rather to do with a mathematical viewpoint. In math, if I say "x = 3" and then "y = x + 2", it is true that "y = 5" and nothing else (assuming our regular understanding of addition is given). In programming, it might also have come to pass that some data was output to the console, and some logging took place, and maybe an HTTP request or two were carried out in the interest of making that evaluation. These are not "pure" mathematics; side-effects are impure because they are not accounted for directly in the semantics. Purity is not on a scale. Either a language is pure, or it isn't. Nobody made any claim that purity is something to strive for in a language. Haskell has it because it was designed specifically to be a language where academics could carry out their "What if?" fantasies (which is catalogued in "A History of Haskell", a paper from HOPL III (2007)). I will say that purity is useful in most practical programming — just not at the top level. The more purity you have in your code (by which I mean, the fewer side-effects that are not evident in the type system), the easier it is to make changes to your code and to use it with abandon. The more side effects you have, the harder it is to restructure code and reason about how things work. So within the implementation of a particular application, there might be regions of purity and then (encompassing) regions of impurity. But a given function is either pure or impure — no gradient to it at all.
- tome 6y ago
  > Purity is not on a scale. Either a language is pure, or it isn't. This is not quite right. "Purity" mean that with respect to some unspecified by fine-grained semantics various pairs of programs are equivalent. For example, in the denotational semantics of Haskell the following are equivalent let x1 = rhs x2 = rhs in body and let x = rhs x1 = x x2 = x in body But they are not equivalent under the operational semantics. The former allocates two closures, the latter one. The "scale" of purity then is measured by how fine-grained the semantics is. Haskell is pure at the "scale" of denotational semantics, but not at the scale of operational semantics.
  - DonaldPShimoda 6y ago
    Ooh I had not heard "purity" defined this way previously in such explicit detail, but it makes perfect sense and I really really like it. Thank you so much for giving me better words for this going forward! Edit: I think, though, that my point kind of still stands in that, with respect to a specific level of semantic detail, a language is either pure or it isn't. Further, I think it isn't useful to compare Language A at Semantic Level 3 to Language B at Semantic Level 1 to compare purity; you're generally going to be sticking to one level of semantic detail at a time, and within that lens all languages will either be pure or impure. Right? Hmm maybe I need to think on this more.

DonaldPShimoda 6y ago

> they are closer to achieving this impossible idea. But what is the impossible idea? What is homoiconicity? Can you give a succinct definition that is consistent with your usage? I don't meant this to sound so antagonistic, but I've seen multiple times where people try to argue in favor of it and come up short when pressed for details. Unfortunately, I do not think I am sufficiently skilled to carry the debate forward. I really recommend looking through Shriram's Twitter exchange to see some of his rebuttals on the topic.