[behnamoh]

> "Lisp is better because it is homoiconic"

- Lisp is better because it manipulates the same data that the program code is represented in (car works on a data list, and it works on a code list as well).

- Lisp is better (at least, Common Lisp) because of image-and-REPL-driven development. Good luck finding exactly that level of flexibility in other REPL-ful languages.

- Lisp is better because of hot code reloading and restarts. Only Elixir/Erlang have a similar mechanism.

- Lisp is better because of structural editing (e.g., paredit). No more character-level editing.

I could go on but just wanted to point out that homoiconicity isn't the entire deal with Lisp.

[fuzztester]

>> "Lisp is better because it is homoiconic"

>- Lisp is better because it manipulates the same data that the program code is represented in (car works on a data list, and it works on a code list as well).

Don't those two sentences mean the same?

https://news.ycombinator.com/item?id=43676798

[behnamoh]

Yeah, but I wanted to emphasize that homoiconicity isn't just some superficial "nice thing" to have, it literally is why we can have powerful macros in Lisp.

[PaulHoule]

I went through quite a few stages of grief reading Graham's On Lisp starting with "this is so awesome" to nitpicking details like "he defined everything else but he didn't define nconc" to "if we was using Clojure he wouldn't be having these problems with nconc" to "funny I can write 80%+ of his examples in Python because most of the magic is in first-class functions and macros are a performance optimization except for that last bit about continuations... and Python has async anyway!"

Notably he doesn't do any interesting tree transformations on the code because tree structures in list are just a collection of twisty nameless tuples that all look alike. If you were trying to do nontrivial transformations on code you'd be better off with an AST in a language like Java or Typescript. In the end the dragon book is On Lisp squared or cubed, that is, games people play with macros are a pale shadow of what you can do if you actually understand how compilers work.

[simplify]

I believe it is more superficial than it sounds: https://www.expressionsofchange.org/dont-say-homoiconic/

[kazinator]

Yes. The best example of something that is popular and homoiconic is Bash. Bash keeps your functions in source code form, though comments may be lost, and they get reformatted. You can see the code when you type "set all", and can copy and paste the definitions back into Bash.

In Common Lisp, the homoiconic feature is the ed function which allows you to edit the source code of a function. Support for ed is implementation-defined!

It may be absent (e.g. in a Common Lisp that compiles everything to machine code). A Common Lisp that compiles all forms and doesn't support the ed function isn't homoiconic.