現在 wasavi のメジャーバージョンは 0.4 だ。これがいつ増加するかというと、おそらく

• モデルとビューを分離したとき
• シンタックス・ハイライティングを実装したとき
• プラグイン・システムを実装したとき

のそれぞれになると思う。さてこの中でシンタックス・ハイライティングであるが、面白い論があったので勝手に訳出。意訳多数、訳質未保証。

＊　＊　＊

シンタックス・ハイライティング論

君はソフトウェアを開発する際、シンタックス・ハイライティングに頼っているか？　もし頼っているならば、もしかしたら君は自ら「墓穴を掘っている」かもしれない。このポストでは、美しく魅力的なシンタックス・ハイライティングについてその表現形式に焦点を移し、それがコードを見て理解しようとする人々の障壁になっていることを議論しよう。

背景
シンタックス・ハイライティングは、大半の現在的テキストエディタや開発環境では標準的な機能で、その基本概念は、プログラマがキーワード、記号、変数名を簡単に識別できるように、いろいろな構文的要素の見た目の違いを強調することだ。

そもそも、なぜシンタックス・ハイライティングが発明されたのか。プログラマは全てのシンタックスが織り交ぜられたコードを読む際、「”)” は変数名かな、もしかしたらプリプロセッサの命令かな？」などと考えるだろうか？　もちろんそんなわけはない。コンピュータ・プログラムを読むことは大概難しいが、この難しさはそのプログラムの複雑さからくるものだ。シンタックスではない。

読みやすさ
シンタックス・ハイライティングはおそらく、コード読解の過程を加速するために発明された。イエス、その通り。強調されたコードは読みやすいに決まってる。その結果、強調されたコードは色を持つようになった！

うーん、ノーだ。タイポグラフィの基本的な経験則の 1 つに「まとまったテキストを書く際は、1 つの書体を選び、そしてそれを固守せよ」というものがある。派手な色は読者の注目を集めるかもしれないが、しかし必然的にテキストを読みにくいものにしてしまう。テキストの自然な流れは破壊される。破壊されたテキストは、個々の文字を繋ぎ合わせて単語と意味を得るためにより脳を酷使させることになる。認識という視点では、読解の過程から無意識の度合はがわずかに減少し、わずかに意識的になる。つまり、実際にテキストを理解する際の、心の意識的な部分の余裕を減少させる。

文法よりも意味が重要
コードを読む上で最も重要なのは、「理解」することだ。段落をざっと眺めれば、その要点を得られる小説や新聞と違い、ソフトウェアは複雑さで満たされており、細部にいたるまで全てが重要である。必然的に、理解するには時間がかかる。理解するためには、コードを意味のレベルで見る必要がある。

また、開発者は、よく知っているコードからさえ、単なるシンタックス・エラーよりもメモリーリークやセキュリティーホール、非効率なアルゴリズムを発見（そして修正）しようとするだろう。どの道コンパイラによって見つけられるのだから、開発者はシンタックス・エラーを探して時間を無駄にするべきではない。しかし、もしシンタックス・ハイライティングが開発者の思考を、コードが意味するものに対してではなくコードのシンタックスへと偏らせたならば、結局彼らは正にシンタックス・エラー探しを行ってしまうのではないか？

私は開発者達は愚かだと言っているのではない。私達は皆あちこちのいろいろなバグを見逃している──誤りは誰にでもあるものだ。せっかく作るのなら、ミスを助長するよりもミスの発見を助けてくれるツールを作るほうが良いと私は思う。

学習曲線
おそらく、シンタックス・ハイライティングは経験豊かなプログラマ向けのものではない。たぶんズレたピアノ教師が鍵盤に色つきのステッカーを貼るように、初心者にとっての学習曲線をなだらかにする意図でもたらされたのではないだろうか。ピアノ教師がそういうことをするのは、コミュニケーションを円滑にする（「さあ F を鳴らして！」より「さあ黄色い鍵盤を押して！」）ためなのかもしれない。彼らが本当に子供たちが音階名を覚えることなど無理だと思っているかは知らないが、子供たちは結局、音階名を覚えて、その後色つき鍵盤を忘れなければならない。

同じ現象がウィザードというユーザーインターフェースで見られる。高度な操作、例えば画像を扱うプログラムは複雑で、新しいユーザをまごつかせるが、ウィザードのダイアログボックスへ入力しさえすれば、柔軟性を犠牲にしていくつかのステップは省略あるいは自動化される。しかし結局、ユーザーは複雑な機能自体ではなく、ただ単にウィザードの使い方を覚えるだけで、そして特別な柔軟性は失われる。これは学習曲線をまったくなだらかにはしていない。学習していないのだ。

もし君が色のある環境でソフトウェアを書くことを学んだら、おそらく色なしの同じコード、あるいは異なるカラースキームのそれですら、理解にしにくい（あるいは、少なくとも不便だ）と感じるだろう。そう考えるとシンタックス・ハイライティングは教育の行き止まりだ。それは補助輪のついた自転車の乗り方を覚えるようなものだ。覚える過程で得た技術を捨て去るまで、普通の自転車には乗れないだろう。

例外
シンタックス・ハイライティングが実際に役立つケースが 2 つある。1 つめは複数行コメントに関連する。たとえば対話的な検索・置換操作の過程でソースコードファイル中を飛び回り、最後に巨大なコメントアウトブロックの真ん中で終了したら？　君はそれをコードだと思って読み始め、しばらくしてコメント終了のトークンにぶち当たる。そこで君はずっとコメントを読んでいたと気がつくわけだ。このケースでは、全コメントが異なる色で描画されることでミスは防げただろう。

しかしまあ、これは近視眼的な解決法だ。コードをコメントアウトするのは非常に一時的なデバッグ手法であって、コメントアウトされたコードは遅かれ早かれ削除か書き直さないとダメだということに多くの方々は同意する。視界から追い出すためにコメントアウトコードの色を変えるのは、まるでカーペットの下にゴミを隠すようなものなのだ。

2 つめは、主に C 言語に関するケースだ。たまたま「==」の代わりに「=」と書いてしまう、これは特に、長時間腰を据えてコードを凝視し、実際に目で見るまではなかなか発見しにくいバグになる場合がある。この状況のシンタックス・ハイライティングは、コードを意味論の文脈よりもシンタックスのレベルに焦点を当てることで有益になりうる、私が知る限り唯一のケースだ──それが「=」と「==」を異なる色で区別できるならば。やった！　シンタックス・ハイライティングを実装するいい理由だ！　だが……（おそらく君はここで驚いたりはしないと思うが）私が見つけた全てのカラースキームは、「=」と「==」を同じ色で強調している。

まとめ
シンタックス・ハイライティングはコードの読みやすさを改善せず、コードを理解させるのではなくざっと読ませるよう助長してしまう。シンタックス・ハイライティングは実際のバグではなくシンタックス・エラーに注目させ、それは学習の邪魔になる。おそらく、コメントアウトされたコード塊の削除をずるずると先延ばしさせたりもする。そして、現在の実装は「=」と「==」の区別（シンタックス・ハイライティングが有用だった唯一のケース）をしない。

一体誰がこんなひどい機能を発明したんだ？　推測するに、シンタックス・ハイライティングは実装して楽しいクールなアイデアとして始まった。今では、それはセールスポイントになった。人々は、例えそれ以外の機能が豊富だったとしても、シンタックス・ハイライティングをサポートしないエディタには眉をひそめる。これはたとえば半透明のコンソールとか、見ていて楽しいものについて共通する、十分に一般的な現象だ。

私は、例え苦くとも良薬を飲むよう勧める: シンタックス・ハイライティングなしでコードを書く、あるいはただ 2 色（コメントとコード）のみ使うという清貧的アプローチを受け入れる。警告: カラフルな見た目なしでは、君のコードはちょっと醜いかもしれない。しかし少なくとも、君が見ているものが現実のコードなのだ。

「この時、王様は裸でありません。王様はすばらしく色とりどりの道化師の服を着ていたのです」