Homoiconicity isn’t the point (2012)

Processing parentheses is still parsing. It's kindergarten-level parsing, but it's still parsing. I've written thousands of lines of scheme code preprocessed to eliminate most parenthesis. I'm convinced Lisp self-asphyxiated by fighting a last stand on parentheses, which is so far from the point of Lisp. With modern editor "language server" support and syntax coloring, languages can shape-shift to any appearance they want, separate from meaning. While I love the poetic look of parenthesis-spare Lisp, Bill Joy got…

Fwiw, I think what's important about homoiconicity isn't so much that the language uses "boring" data structures for its (intermediate?) syntax tree, but that the both the syntax itself and the representation of the syntax as an AST is simple and obvious. Haskell has TemplateHaskell, which can be used for macro-like things, but it's substantially less ergonomic, not because Haskell isn't "homoiconic", but because the grammer is actually really complex and non-obvious. There's tons of little things that you don't…

In my opinion, this article puts too much emphasis on reading, and too little emphasis on actually reasoning about programs in homoiconic languages like Prolog and Lisp, and due to this imbalance the conclusion is not sufficiently justified. It is true: Being able to "read without parsing" is definitely nice. But that is only a subset of those advantages that a homoiconic language gives you. An at least equally important advantage is due to the fact that programs in homoiconic…

Here's a duplication of the comment I made on the site. I speak as if I'm speaking directly to the author. --- > it’s possible to read it without parsing. Yes, it's possible to perform lexical analysis without parsing too. > the front end of every interpreter and compiler looks pretty much the same: [diagram] You forgot the step where lexical analysis occurs. This is akin to what Lisp's READ does. Except the output isn't a stream of tokens, it's…