LisperはASTを直に書くのが楽しいという通好みな嘘

「LisperがASTを直に書くのが楽しいというのが理解できない」、「抽象構文木を直接操作するのを有り難がっているのがわからない」などという話は、たまにではありますが定期的に掘り返される話題です。
大体は、コンピュータサイエンス的に教養の高い人からの意見が多いようですが、パーザの研究に重きを置いている方だったり、具象構文の研究をしている方が多いようです。
そういう方々にはLispという存在は何か世の中の発展を阻害する何かに見えたりしているのかもしれません。

LispはASTを直に書いているわけではない

実際のところCSに精通している方々も別にLispだとASTを直に書くとは思っておらず、言葉の綾での表現なのが厄介ですが、Common Lispなども具象構文としてS式で記述しています。

Lispはデータでコードを書いている

では、実際のところLispでは何が特徴的なのかといえば、データでコードを記述するということです。
データでコードを記述する言語は、LispやPrologなどがありますが、データでコードを記述するという捉え方をしている人は、LispやPrologを書いている人でも、そう多くはないようです。

古典的なLispでは、シンボルとリストというデータで、コードを表現します。
Common Lispなどでもそうですが、シンボルは名前付きハッシュテーブルのようなもので、任意のデータを格納できたりして、他の言語のテキストを強く意識した識別子という概念からすると妙な存在です。
Lispの発明者のマッカーシ先生がシンボルをオブジェクトのようなものと考えていたのが大元ですが、究極的にはシンボルでなくても画像でも物理的な物体でもいいわけです。実際、関数オブジェクトの外部表現を画像にしてみせるような環境もあります。

ややこしいのは、近代化に伴い、Common Lispのようにテキスト表現と従来のコードでデータを表現が混在する言語が出てきたということですが、この場合、コードの外部表現でテキストを表現している状態になっています。レキシカル変数などは、テキスト表現であり、シンボルオブジェクトという表現からは乖離していますが、Common Lispの初学者もこのあたりで混乱することが多いようです(ベテランでもそうかもしれない)

コードをデータで表現するということは、実行時環境でもコードが普通に存在可能ということですが、この辺りの性質が高度な対話環境の源泉ともなっています。
テキストをコンパイルして実行環境にロードするというのを継ぎ目なくできるようにすればいい、というアプローチもありますが、継ぎ目をなくすのは結局コードをデータで表現するのに極めて近い状況になりそうな気がしています。

近年のCSでは数学的な方向に邁進していると思われますが、こういう対話性とか実行時の自由度のようなものは、1990年代初頭あたりからプログラミング言語の研究の本筋からは除外され、人間工学とか心理学とかそういう類に分類されるようになったようです。

実際、Schemeなどは、データでコードを表現するという方向性より、一般的なプログラミング言語のテキスト表現(+パーザ)構成にどんどん接近していますが、こういうCSの発展の方向性と軌を一にしているのかもしれません。
見た目はCommon Lispと同じS式ですが、SchemeのマクロがCommon Lispとは全然違ったアプローチであるというのも、CSのトレンドに近い方向性なのでしょう。

Lispの超循環性

Lispでは、コードとデータが同じ場所にあるため、メタな存在の人間が対話的に操作したり、プログラム自体がプログラムを書いたりするというのが自然な考えです。
しかし、どうやら、コードとデータが同じ場所にあることが気持悪かったり、制御不能になったりしそうで怖いという人が多数派のようです。多分Lispを書いている人の中で調査しても多数派でしょう。

創造主と被造物が一緒になることを避けたい二元論派であるのか、はたまた、魔法使いの弟子のような暴走が怖いという感覚なのかは、Lisp派の自分にはわかりませんが、とにかく混ざったら駄目なようです。
自分は混ざった方が面白いのでLispを書きます。