LOL(日本語版)読了

面白かった。
全体の1/3ぐらいの最初の方は目新しい点はあまりなかったが、「アナフォラの閉鎖」から「パンドラのマクロ」にかけての辺りが凄かった。
レキシカルな環境を、こんな風に開く事ができるとは、これを読むまでは思ってもなかった。
S式(もしくはS式類似の、データとプログラムコードを同一のものとして扱える書式)の強力さを再認識した。
歴史的な経緯を考慮したり、なるべく自然言語風になるように無駄な努力をしているような、「腐った構文」持ち言語など、とても使ってはいられない。
(haskellのような、言語の強力さを目的とした「腐っていない構文」を持つ言語は一応例外として)

しかし、仕事では「腐った構文」持ち言語を使わなくてはならない。
S式言語ならマクロ定義して三文字ですむところを、何度も何度も複数行足さないといけないというのは、普通に苦痛だ。
それを修正するには、言語処理系自体にパッチを入れるしかないというのも、どうしようもない。
つまり、(少なくともこの点に関しては)「業務効率の改善」はできない。

• • • -

他にLOLを読んでいて考えさせられたのは「簡潔理論」と「二重性理論」のところ。
「簡潔理論」の方はPaul Grahamがよく言ってたり実践してたりするので知っていたが、「二重性理論」の方は知らなかった。
これはインクリメンタル開発(もしくは単に「開発」)で重要だと思うので、定義と二重性理論だけ、記号をちょっと変えて引用しとこう(本書では「B」だったのを「A'」に変更した)。

Lをプログラミング言語、Fをその言語の機能、そしてAとA'をLで書いた任意のプログラムとする。
AからA'への変更に必要な改変作業が、Fを持たないLによって書かれた場合よりも少なくなるのなら、Fは構文の二重性という機能を提供する。

プログラムを構築するのに要する労力は、使われるプログラミング言語が提供する二重構文の総量に反比例する。

ただ、これを「構文の二重性」と呼ぶべきかどうかはかなり疑問に感じる。
本書のケースでは確かに「構文の二重性」ではあるものの、もう少し抽象度を高めて、より一般化できそうな気がするので。
名前の事はともかく、開発サイクルの高速化は、仕事でも非仕事でも重要な関心事なので、今後はもう少しこの辺も意識したい。