There is definitely something quite Lispy about responding to the question "What is Lisp?" with the word "homoiconicity" and then waiting for the person who asked to figure out what that actually means.

The problem I had with "code is data" or "homoiconicity" is that they didn't really help me to code in Lisp. Although they were obviously big, mouth-watering hints that something is there! :) From an operative point of view, I think "chainable action perimeters" delivers more.

Also, both "code is data" and "homoiconicity" are notions that ends up showing concretely in macros. And the conflict with the notion of "chainable action perimeters" is twofold but always harmful to properly operate as a programmer.

First, we don't deal directly with the true results of macros, which are codes. We let the evaluator compute theses codes internally and it then automatically chains with a call to... itself!

So yes, it can be said one can teach the evaluator new tricks but the infrastructure enabling that and justifying the expressions "code is data" and "homoiconicity" feels a bit too much like a three-card trick to me. The fact what seems the best advice on how to use macros is to not use them when functions would do appears to be, I think, another thumbs-up for the expression "chainable action perimeters".