Textileのダメっぷりで改めて思ったこと

あえて言うまでもないんだけど一応。

生き残っていて、枯れていて、人気があるものと、件の Textile のように、荒れて、人気がなくなっていくものとの間には、実は根本的なたった一つの違いだけが分岐点になっている、と思う。

Markdown、reStructuredText、そしてあるいは Texinfo、\(\TeX\)、\(\LaTeX\)、(g)roff のどれを取ってみても皆、「明示的マークアップ」である。これらに共通しているのは、これらの開発者自身が「お願いされたことだけをする」「頼まれていないことをしない」「頼まれていないことをする場合は逃げ道を用意する」ことの重要性を熟知していることにある。基本的に、これだけだと思う。

仕様に忠実に書かれたとすれば、Creole1.0 はこれに合格している。ただ、ざっと眺めた限り、エスケープ(~)が実装されていないエンジンが溢れているなど、状況は芳しくないらしいが。けど設計者は正しい。実装者がダメなだけ。

Textile は「お願いされていないことをする」「頼まれていないことをする」「頼まれていないことをする場合も逃げ道がない」だけでもう、十分にダメだったのだ。けれども Textile の問題は実際にはそれだけではないと思う。自分が何をしているのか、自分で理解出来ていなかったんじゃないだろうか。これはドキュメントの構造にはっきり現れている。すなわち、「マークアップとは何か」であるとか、「html とはどのようなものなのか」さえもあやふやなまま、「少ない記述量で猛烈タイピング」という一点突破主義を貫こうとしてしまったわけである。これはあれだ、ブラインドタッチで生産性アップ! と同じノリだ。

「ブラインドタッチで生産性アップ!」になるかならないか、で言ったら、そりゃなるよ。「最初からそうしてれば」の話。けど、「今からブラインドタッチに乗り換えて生産性アップ!」と考えるならアホ。頭脳労働にタイピング時間が占める割合なんか大したことないし、タイピング速度が生産性に寄与する程度なんか、微々々々々々々々々々々々々々たるもん。んなこと真剣にやり直すくらいなら、それこそスクリプト言語を学べばいい。あるいは(エディタを含む)開発環境の素晴らしい機能を喰らい尽くすことに時間かけた方がよっぽどいい。

もちろん「お願いされたことだけをする」「頼まれていないことをしない」「頼まれていないことをする場合は逃げ道を用意する」の次に控える分岐があるが、それは当然「曖昧な仕様を避ける」ことである。基本中の基本。実際問題仕様の曖昧さをゼロにするのは難しい。が、まともに考えられたものはどれも、仕様の曖昧さを最小化する努力をしている。Textile は当然この点でも不合格なわけだ。まぁ一つ目がダメなんだもん、こっちだけが正しく出来てるわきゃねーけどな。












ついでなので話をもう一つ。

「それでも Texitle の Pygments lexer を書くことには価値があるのでは?」について。

答えは「ない」なんだけれども、これについては補足が必要だろう。

Pygments のような「シンタックスハイライト」のミッションは、「対象言語の記述を読みやすくすること」である。逆に言えば、「シンタックスハイライトが間違うことほど迷惑なことはない」ということも言える。経験あるだろう。間違ったハイライトは、のっぺらぼーのプレインテキストよりも読みづらく、かえって精神疲労を招く。

すなわち「シンタックスハイライト」の宿命には、「対象言語のバグも忠実に再現しなければならない」ことまで考えなければならないことも含まれるのである。対象言語が処理する通りに解釈しないならば、それは「その言語の方言」を増量することを意味するからだ。

Textile は仕様がアウトなだけでなく、乱立した複数のエンジンがどれもバラバラの振る舞いをしているため、もはやシンタックスハイライトの「正」が存在していない。どれかを基準にすればどれかの「誤」になる。「間違ったハイライト」になるのだ。これはもう、シンタックスハイライトなんか作っても意味なかろう。(やるなら個々のエンジン別に全部バラバラに書くしかない。)

そういうわけでワタシは、「Textile はもはや存在してはならないと言ってもいい」と思っていて、かつ、「これの Pygments lexer は迷惑なので書いちゃダメ」と思ってる、ってことさ。ダメ、つぅか、書いたら感謝されるどころか間違いなく恨まれるわ。だって「ワタシの Textile と違う!」となること必至ですから。