> let’s say a word means what the people who use it mean by it.
This is how words work, so I don't know why the author says "let's say". There is no "correct" definition of a word; the dictionary which you might consult to obtain such a definition is itself just recording what is the most commonly-used meaning of the word among people who use it most natively.
I make this point not out of pure pedantry, although that may play a part, but also because nobody seems to know what "homoiconicity" actually is — nor does it seem to actually be very important for us to find out! When people cannot agree on what a word means, I think it's reasonable to say that that word doesn't really have a meaning.
Some time ago, I had the opportunity to talk to Matthias Felleisen — the progenitor of the Racket project (a derivative of Scheme, itself a derivative of Lisp). When I asked whether he felt homoiconicity was an important quality of a language, he indicated something to the effect of (heavily paraphrasing) "I don't know what that word means, and you don't know what that word means, but whatever you think it means is not important. It doesn't matter."
Shriram Krishnamurthi, a former student of Felleisen's and one of the original members of the Racket project, can be found to disparage the word whenever he finds it on Twitter. He also consistently refers to it as h11y (that's "H-eleven-Y"), not just to save characters in tweets, but also, I think, because the word itself is not very important. I've seen multiple exchanges where he challenges peoples' attempts at defining the term precisely, and invariably they give up. (One such exchange is visible at [0].)
Another Racketeer, Matthew Flatt, recently started a push to build a new Racket language (now called Rhombus, I think) which abandons s-expressions almost altogether, but without losing any of the benefits of Racket.
If these people, who are all everyday Lispers, and who are widely known and respected in the programming language community, don't have a solid definition of "homoiconicity" and, further, don't think it's worth investing the time to define it... maybe we should stop getting articles like this, and maybe we should instead tell people to abandon their search for the One True Meaning.
(I do want to say that I think this is one of the better articles about the topic that I've read, and the author did a good job. I just think the topic is not as interesting as the author expects their readers to find it.)
Homoiconicity doesn't matter. Nobody can define it very precisely, so no two people will have the exact same definitions in their head when discussing it, so any talk regarding it will be necessarily lossy (or, in the worst case, completely non-productive). If the literal representation of your language happens to evoke some imagery in your mind of the secret machinations of the underlying forms or something, that's great! But I don't think it's worth pursuing this quality specifically. What syntax works this way for you may not work well for others, or vice versa.
I think that, instead, it is better to focus on more specific goals. Maybe your language is very tree-oriented, so you make it easy to represent trees directly. Something like that. But the specific goal of "homoiconicity" — whatever that means to you — is perhaps not worthwhile, nor should we be seeking to define it. We should leave it by the wayside and move on!
I believe words and the concept they represent are important, Homoiconicity is very very important, but the concept is something subjective that you get after working years on it.
After programming for a long time in other languages, I had the intuition of wanting something like lisp, but I could not express those ideas with exactitude. They were diffuse, not clearly defined ideas.
Then after having a master teach me lisp I got it. I also had the intuition of lisp limitations too and started working around those limitations and getting to know in specific terms what those limitations are, and the most important thing, working on solving it.
You have people around the internet with very little programming experience discussing all day about concepts they hardly understand, because they have not programmed a lot to really grasp it.
This is like discussing the sex of Angels.
A lot of the problems that exist have lots to do with the limitation on the input technology of computers.
Creating anything takes millions of time more energy and work that just thinking about it.
I could think about computers talking to me and me talking with the computer. It takes lots of work(years) to actually do it.
I could dream about the computer writing code for me, but it can take decades of actual work to do it.
Spending your time just talking is so easy compared to actually going the distance working around it.
Why is homoiconicity "very very important"? Nobody seems able to say.
> You have people around the internet with very little programming experience discussing all day about concepts they hardly understand, because they have not programmed a lot to really grasp it.
The people I quoted were all principal developers of arguably the most successful Lisp derivative in the past few decades. The annual Scheme Workshop is almost entirely Racket these days. I doubt you are in a place to claim that "they have not programmed a lot to really grasp [homoiconicity]". So I'm confused what your point is here.
That said, I think “very very advantageous” would be more correct.
If your language is a sprawling inconsistent mess of non-essential complexity, what chance of the systems built with that language being any better? And what chance of the language itself growing and evolving in future?
Complexity kills progress. Forward movement finally grinds to a halt under its own impossible weight; at which point some genius will pronounce “Let’s abandon all that and start over completely afresh”, only to make the exact same foundational mistakes as the last time. Rinse-and-repeat ad nauseum for the illusion of progress without actually ever progressing anywhere. And so it goes.
The only way to a maintain sustainable growth is to eliminate all non-essential complexity constantly and ruthlessly. You can either climb that ladder and discover where it goes, or forever sit on its bottom rung playing with yourself.
You never defined what it is that you mean by "homoiconicity", nor did you motivate why homoiconicity specifically is important or advantageous. You made, essentially, two points:
- homoiconicity is "very very advantageous"
- excessive, non-essential complexity will hinder progress eventually
You did not argue that homoiconicity defeats complexity in any way, and you can't make such an argument without first defining what exactly you mean by "homoiconicity".
Like I said, this has only proven my point: people like to argue in favor of homoiconicity without defining it sufficiently. Until someone comes up with an unambiguous definition that exactly fits all of their preconceived notions about the word, the word itself is absolutely useless.
For further clarity: I was never arguing against any of the features that people often mean when they say "homoiconicity is important". Rather, I was arguing that the word "homoiconicity" is unimportant because nobody knows what it means. I have yet to find a truly great definition of the term that encompasses exactly all those languages people tend to feel are homoiconic and none of those that people feel aren't.
The first Lisp syntax idea was to use s-expressions only for data and use a kind of algebraic notation for the code part. Thus programs would use s-expressions, where such data would be written. But that was the syntax on paper. The actual Lisp implementation was interpreting and compiling s-expression code&data. Developers had to hand translate the original syntax into s-expressions. Lisp developers found that very useful and attempts to replace it never had much success for actual Lisp users. At the same time it was always a hurdle for new users or people who would learn Lisp in some university or school setting. In books from the 60s one can read the same complaints about parentheses, etc., like we still hear today.
Later several times there were large and small scale attempts to abandon the s-expression syntax or to develop new languages with all the advantages of Lisp, but not its syntax. The "Lisp 2" project was a huge effort into that direction and failed. Logo was another. ML similar (which was successful and spawned a bunch of new languages). Apple Dylan was another one. Plus many others. Racket now starts the next attempt to get rid of s-expressions. Scheme R6RS was early going into the direction, by offering a fixed syntax definitions for much of the language.
For Lisp the base idea is that programs are not text, but basic data made out of lists, symbols, and a bunch of other data types. The input to the EVALuator is such a data structure. Additionally there are procedures like READ and PRINT, which can translate data from and to textual representations.
So the idea is: code is data. Plus: code has mostly a direct textual representation in the form of nested s-expressions.
The Racket project is more concerned with reaching a larger audience for computer science education, and not so much about sticking to these basic Lisp principles. Their problem is that the s-expression syntax and the code is data idea is difficult for students and of little use, since most popular programming languages work differently (Python, Java, JavaScript, ...).
As a Lisp user I don't care about their educational problem and like the simple code as data idea and what follows from that.
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.
> 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.
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.
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.
> 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.
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.
> This is how words work, so I don't know why the author says "let's say".
I say that specifically because this word was coined in 1965 by Calvin Mooers
with a particular specific definition; I'm saying that even though it's a (relative)
neologism, the word has already shifted in meaning.
> maybe we should stop getting articles like this, and maybe we should instead
> tell people to abandon their search for the One True Meaning
I actually agree... the article (and the previous one) are mostly consequences
of starting out in the belief that homoiconicity is something to strive for, and
then failing to understand what homoiconicity would really be -- but
discovering the things to strive for in the process.
> I say that specifically because this word was coined in 1965 by Calvin Mooers with a particular specific definition; I'm saying that even though it's a (relative) neologism, the word has already shifted in meaning.
Mm what I meant to get at was that you give a definition of "meaning", which is that "a word means what the people who use it mean by it", and your use of the phrase "let's say" makes it sound like this is a charitable admission on your part. And my point is that this is what it means for a word to "mean" something — it's entirely based on what people who use it mean by it, so the way you say "let's say" was rubbing me the wrong way, so to speak.
> I actually agree... the article (and the previous one) are mostly consequences of starting out in the belief that homoiconicity is something to strive for, and then failing to understand what homoiconicity would really be -- but discovering the things to strive for in the process.
I did not take the time to read the previous article, but I regret that now. I will go back and read it. :)
I don't think I did a good enough job saying that I think this is among the best articles on homoiconicity that I've read! I meant for my lament to be more general and not specifically directed at you, but more just at those people striving for homoiconicity without a clear idea of what that means. I think, rereading parts of this article again now, we're more aligned than I had previously though. I'm sorry for not realizing that earlier!
Words only have meaning due to community consensus. Yes, we have dictionaries to record what the consensus is (or, more accurately, what the consensus was at a particular point in time), but the dictionary cannot predict semantic drift, nor can it adapt with sufficient speed in the modern era of light-speed communication.
The dictionary only works because most people who use a given word already use it consistently with how the dictionary describes it. It is not the case that most people learn the word "dog" from the dictionary; the dictionary's definition is "correct" because it aligns with the way people already use the word. If Merriam-Webster published a revised definition stating that a dog is "a large, four-legged creature with wings which breathes fire", people would immediately agree that the dictionary is wrong. It only reflects words as they are used, not words as they must be used. (The Merriam-Webster official Twitter account is adamant in promoting this view of dictionaries, for what it's worth.)
This is how words work, so I don't know why the author says "let's say". There is no "correct" definition of a word; the dictionary which you might consult to obtain such a definition is itself just recording what is the most commonly-used meaning of the word among people who use it most natively.
I make this point not out of pure pedantry, although that may play a part, but also because nobody seems to know what "homoiconicity" actually is — nor does it seem to actually be very important for us to find out! When people cannot agree on what a word means, I think it's reasonable to say that that word doesn't really have a meaning.
Some time ago, I had the opportunity to talk to Matthias Felleisen — the progenitor of the Racket project (a derivative of Scheme, itself a derivative of Lisp). When I asked whether he felt homoiconicity was an important quality of a language, he indicated something to the effect of (heavily paraphrasing) "I don't know what that word means, and you don't know what that word means, but whatever you think it means is not important. It doesn't matter."
Shriram Krishnamurthi, a former student of Felleisen's and one of the original members of the Racket project, can be found to disparage the word whenever he finds it on Twitter. He also consistently refers to it as h11y (that's "H-eleven-Y"), not just to save characters in tweets, but also, I think, because the word itself is not very important. I've seen multiple exchanges where he challenges peoples' attempts at defining the term precisely, and invariably they give up. (One such exchange is visible at [0].)
Another Racketeer, Matthew Flatt, recently started a push to build a new Racket language (now called Rhombus, I think) which abandons s-expressions almost altogether, but without losing any of the benefits of Racket.
If these people, who are all everyday Lispers, and who are widely known and respected in the programming language community, don't have a solid definition of "homoiconicity" and, further, don't think it's worth investing the time to define it... maybe we should stop getting articles like this, and maybe we should instead tell people to abandon their search for the One True Meaning.
(I do want to say that I think this is one of the better articles about the topic that I've read, and the author did a good job. I just think the topic is not as interesting as the author expects their readers to find it.)
Homoiconicity doesn't matter. Nobody can define it very precisely, so no two people will have the exact same definitions in their head when discussing it, so any talk regarding it will be necessarily lossy (or, in the worst case, completely non-productive). If the literal representation of your language happens to evoke some imagery in your mind of the secret machinations of the underlying forms or something, that's great! But I don't think it's worth pursuing this quality specifically. What syntax works this way for you may not work well for others, or vice versa.
I think that, instead, it is better to focus on more specific goals. Maybe your language is very tree-oriented, so you make it easy to represent trees directly. Something like that. But the specific goal of "homoiconicity" — whatever that means to you — is perhaps not worthwhile, nor should we be seeking to define it. We should leave it by the wayside and move on!
[0] https://twitter.com/ShriramKMurthi/status/104694495053182976...