Andy Oram, Greg Wilson編 Brian Kerninghan, Jon Bentry, まつもとゆきひろ他著「ビューティフルコード」オライリージャパン 久野禎子,久野靖訳 5

　Andy Oram, Greg Wilson編 Brian Kerninghan, Jon Bentry, まつもとゆきひろ他著「ビューティフルコード」オライリージャパン 久野禎子,久野靖訳 1、２、３、４ から続く。

25章　構文の抽象化：syntax-caseマクロ(ケント・ディヴィグ)

　scheme のマクロ機能である syntax-case の話。scheme は LISP の軽量版みたいなプログラム言語で、手軽に LISP の雰囲気を味わいたい人にはお薦め。言語の要求仕様がコンパクトかつキッチリ決まってる上に、なんたって処理系が手に入りやすく動かしやすいのがいい。

　反面、利用者はやたらと頭よさげな人が多くて、半端な気持ちで質問すると素人にはハナモゲラな文章で回答が帰ってくるのが困り者。私も、この章は、ほとんど意味が分からなかった。

　ここで言うマクロとは、ｃ言語で言う #define みたいなシロモノで、S式からS式を作り出す。ただし単純にシンボルを置き換えるだけじゃ巧くいかない。というのも、マクロの中で(一時的に)使っているシンボルと、マクロを呼び出す側が使っているシンボルが、たまたま一致しちゃうと、悲惨な事になるから。

　これに LISP 独自の構文 quote とかが絡むと、問題は更に複雑に。

26章　労力節約のアーキテクチャ：ネットワークソフトウェアのためのオブジェクト指向フレームワーク(ウィリアム・Ｒ・オッテ、ダグラス・Ｃ・シュミット)

　多様なプラットフォームやプロトコルの違いを、c++ のテンプレート機能で吸収しましょう、という話を、ログ記録サーバを例に語ってゆく。

　とくれば大体想像がつくように、基本的な動作はテンプレートで記述して、プラットフォームごとのAPIの違いはサブクラスで実装する、かなり王道の手法。ただし、こういう手法で「使える」テンプレートを作るには、サブクラスとなり得るプラットフォームのAPIについて、ある程度は分かってないとマズいんだよなあ。

　というのを実感するのが、子プロセスを作るAPIの違い。昔のサーバは、リクエストを受けると子プロセスを fork() して、仕事は子プロセスに任せ、親プロセスは再びリクエストを待つ形が多かった。問題は、子プロセスを fork() した後で起こる。POSIX準拠だと入出力ハンドルもコピーするけど、Windows じゃ子プロセスは入出力ハンドルにアクセス出来ない。

　けど、今だと、プロセスじゃなくてスレッドで処理するんじゃなかろか。いや良く知らないけど。

27章　ビジネスパートナーをRESTfulにまとめ上げる(アンドリュー・パッツァー)

　IBMのオフィス・コンピュータAS/400 で動くRPGで作ったサービス(の一部)を、Java の Servlet＋XML＋Rosettant を使ってWeb 経由で使えるようにする話。ちなみにここで言う RPG は Roll Playing Game でも Ruchnoj Protivotankovyj Granatomjot でもなく、Report Program Generator(→Wikipedia)の事。事務系じゃ便利な言語です。

　Servlet なんで、面倒くさい通信関係は考えなくていい。基本的には XML でリクエストを受け取り、AS/400 のサービスを呼び出し、XML を書き出す、それだけ。つまりは一種の Wrapper ですな。

　今、受注している仕事はハッキリと仕様と利用者が決まってるけど、将来は仕様も利用者も増えるだろう、ってのが前提にある。そういう場合に、「とりあえず骨組みを作っといて、細かい所はコメントだけ書いとく」のは巧い方法。私もよくやった。というか、ある程度の経験のあるプログラマは、みんなやってるんじゃなかろか。

　リクエストの種類、つまり使いたい AS/400 のサービスによって異なるオブジェクトを生成する部分は、意外とベタな switch～case でやってる。プラグインにして、実行時にロードする方法もあるけど、それやると却って管理が難しくなるから、これでいいのかも。

　XML はデータ構造としちゃ柔軟で表現力も大きい反面、プログラムで扱うとなるとパースと生成が面倒くさい。ここじゃパースは XPath、生成は単純に文字列の連結で済ましてる。今なら JSON が楽かも。

28章　美しいデバッグ(アンドレアス・ツェラー)

　gdb の便利ツール、データ表示デバッガ(ddd、data Dislay Debugger)のデバッグから始まる、楽しいデバッグの話。

　「GDB4.16 じゃ巧く動くけど、GDB4.17 じゃ巧く動かないんだ」。このバグ報告が、騒ぎの始まり。まずGDB4.16と4.17の違いを調べようと diff を取ると、8,721箇所以上178,200行。「どこがマイナーリリースじゃい！」と怒ってもしょうがない。

　8721箇所のどれがが原因なのは分かってる。じゃ、どこが原因なのか。修正箇所を１個づつ適用して、GDB をビルドしてテストすれば…と思ったが、複数個所を同時に適用しないとビルドできない場合もある。でもとにかくビルドする方法を考えて自動ビルド＆テストする道具を作り…

　というわけで、ツェラー君のマシンはスクリプトに従って３日間ひたすら gdb をビルドし続けるのでした。

　などの経験から、プログラムの状態を可視化する道具を作ってしまう発想と実行力はさすが。

29章　エッセイのごときプログラム(まつもとゆきひろ)

　プログラム言語 ruby の設計を通し、「どんなプログラム言語が好きか」を語るコラム。

　利用者が覚えやすく、ややこしい処理を簡単に書けて、高速で動き、保守しやすく、かつ拡張しやすいのが良い言語。でも、幾つかの要素は同時に成立しにくい。

　Forth や PostScript の文法は単純で憶え易いけど、使うのはちとシンドい。特に他人が書いたプログラムを読むのは地獄になる。c言語の ++ とかは、ぶっちゃけ構文糖だけど、お陰で読むのも書くのもグッと楽になった。その辺のバランスが、言語を作る人のセンスを問われる所。

　読んでいて気がつくのが、全て使う人の目線で描いている事。例えば「簡潔さ」では、処理系の簡潔さではなく、「同じ処理をいかに簡潔に書けるか」というテーマで語ってたり。

　ちょっとややこしいのが、「保守性」。これは「プログラムのメンテしやすさ」ではなく、新しく ruby を憶えようとする人のとっつきやすさで語っている。既に憶えている言語に似た言語は、とっつき易い。極端に文法が違うと、近寄りがたい。LISP がイマイチ流行らない理由の一つがコレだと思う。

　そこを巧く誤魔化したのが JavaScript。「なんか LISP だよなあ」と思ってたら、やっぱし「1.7 で let を追加」とか言い出したｗ

　もう一つ、ruby の強力な機能が、メタプログラミング機能。perl もそうだけど、クラスやメソッドの一覧など、(現在生きている)処理系が管理している様々な辞書にアクセスできる点。これを巧く使うことで、自動ロードやプラグイン管理が楽になるし、デバッガなどのサポート･ツールも開発しやすくなる。

　今は利用者のコミュニティが積極的に道具を使いやすく育てる事ができる時代。そこまで見越して設計したのなら、なかなか優れた社会的ハックだと思う。

30章　世界につながる手段がボタンだけだったら(アラン・メータ)

「スティーブン･ホーキング教授ができるのはボタンを押すことだけだ」

　ALS（筋萎縮性側索硬化症）を患うスティーブン･ホーキング教授が、便利に使えるエディタ eLocutor を Visual Basic6 で開発する話。

　やはりネックとなるのは、語句を入力する部分。ここで巧く候補リストを工夫し、なるべく操作数を少なくしよう、というのがお話の中心部分。そこで必要なのが単語の補完であり、使うのは単語の出現頻度予測。そのために辞書･キャッシュ･マクロを駆使し、出来る限り使う人の負担を減らそうとしている。

　という事で、単なるユーザ･インタフェースの話だと思ったら、言語学的な話も出てきた。最近は word2vec なんてのもあって、v(東京)－v(日本)＋v(フランス)＝パリ、なんて真似も出来るらしい。

　こういう利用者に密着して開発する話は、「意外な落とし穴」的なネタが楽しくて、このコラムだとマクロの話。

　人気者のホーキング教授、講演する機会も多いんだけど、その際には光の加減で画面が読みにくい場合がある。ってんで、読み上げ機能を追加するついでに、マクロを実装しちゃう。読む限りはマクロと言うよりシナリオ実行に近くて、条件分岐とかはなく、実行と一時停止ぐらいらしい。パワーポイントの自動再生みたいな？

　私はド近眼で、眼鏡なしじゃ生活できない。たまたま眼鏡ってテクノロジーがあるから不自由なく生きていけてる…航空機のパイロットにはなれないけど。そんな風に、テクノロジーの助けがあれば自立できる人は沢山いるわけで、そういう人を巧く支援する技術が出来れば、世界はより豊かになるんだと私は思う。

31章　Emacspeak：完全に音声のみのデスクトップ環境(T.V.ラマン)

　前のコラムと少し関係ある話で、Emacs の音声デスクトップ環境 Emacspeak の話。音声出力サーバは TCL で、Emacspeak 本体は EmacsLisp。

　今はGUI花盛りだけど、視覚障害者にとっちゃ、あまし有り難いシロモノじゃない。でもコンピュータが声を出して読み上げてくれれば、使える。ってんで、音声デスクトップ環境の登場となる。

関係ないけど lynx なんて web ブラウザもあって、これを音声デスクトップと組み合わせると視覚障害者でも web を使えるとか。このブログも、一応 lynx 利用に配慮してます。誰も使ってないみたいだけどｗ　いや便利なのよ lynx、巧く色を変えれば変なサイト見ててもボスにバレないし←をい

　とまれ、単に文字を読むだけじゃ話は終わらなくて。長いテキストを読み始めたら、途中でキャンセルしたい場合だってある。てんで、最初は音声出力サーバに一気にメッセージを送ってたのを、１フレーズづつ送って、キャンセル要求の有無を確認するようにしたり。

　改行の処理も、ちと面倒で。普通の英文テキストなら、改行はただの空白文字。でも pｙthon のプログラムだと、改行は文の区切りになる。こいういった部分は、扱うテキストの種類によって違ってくる。

　やはり面白いのが、音声アイコン。ファイルの保存・ウエブサイトを開く・何かを消すなどの動作を、短い音で知らせる機能。考えてみれば、操作に対し何らかのフィードバックがあるからコンピュータは使いやすいんで、例えばファイルをゴミ箱に入れてもアイコンが残ってたら、不安になるよね。

　ってな事柄を、EmacsLisp で実装していくんだが、ここで活躍するのがアドバイス機能。任意の関数を実行する前・実行後に何かを実行する、または関数本体を置き換える機能。年寄りはMS-DOSの割り込みベクタの書き換えを思い出そう…って、通じにくい例えだな。いわゆる「フック」。今なら JavaScript のイベントリスナが通じるかな？

　なお、先に lynx の話を出したけど、Emacs 上の web ブラウザ w3m もあります。というか、テキスト・ブラウザとしては w3m の方が有名かも。

32章　働くコード(ローラ・ウィンガード、クリストファー・セイワルド)

　DiffMerge という10年以上も使われたソフトウェアを例に、コーディング規約の話。言語はｃ。曰く、以下７か条。

1. 「本のよう」であること
2. 似たものは似て見えるようにすること
3. 字下げを克服すること
4. コードをもつれさせないこと
5. コードにコメントをつけること
6. ごちゃごちゃにしないこと
7. 既存のスタイルに解け込むこと

　「最もバグになる傾向が高いのは、入れ子になった条件文である」は納得。条件文に限らず、入れ子が深いのは危険な兆候だと思う。というか、私のオツムじゃ三重になると理解できない。

　短い変数名を使うってのも同意。どっかで聞いた事があるんだが、構造体やメンバ変数の名前が、単語２個以上だったら、何かマズい事が起きている予兆だとか。キチンと構造化していれば、単語一つで済むはず。それとループの制御変数で i, j, k, l, m, n を使い果たしてるのも、マズい兆候。プログラムが長すぎるって事。

関係ないけど昔、凶悪なプログラムを見た。文字列定数の定義で、一つの空白は space, 連続した二つの空白を spaace, 三つの空白に spaaace と名前をつけていた。凶悪だと思いませんか？

33章　「本」のためにプログラムを書く(ブライアン・ヘイズ)

　この本の最後を飾るに相応しい、美しいコードが拝める章。いやホント、この解決法には感激した。

　問題は、「平面上の３つの点が与えられたとき、その３点が同一直線上にあるか」を調べるプログラム。言語は LISP。といっても、長くてせいぜい７行だし、小難しいマクロなどは使っていないので警戒無用。

　３点の座標が px, py, qx, qy, rx, ry で与えられた時、どんな解法を考えるだろう？　私が考えたのは著者と同じ、２つの点から一次方程式 y=mx+b を導き出し、３点目がこの方程式に当てはまるか否かを調べる方法。でも、この方法には問題がある。仮に点pとｑを選んだとき、px=pyだったら、つまり 方程式が x=b の形の時は、ゼロ除算の例外が起きる。

　実はもう一つ、問題があって。点p と点q が全く同じ座標だと、っこれまた面倒くさい事が起きてしまう。これらを例外事項として、予め条件分岐で除外してもいいけど、なんか美しくない。なんとかならんの？

　ってな悩みをブログに書いたところ、実にエレガントな解が見付かった。「３点でを頂点とした三角形の面積を計算すりゃいいじゃん」。一直線上にあるなら、面積はゼロになる。ってんで、出来たプログラムはたった３行。計算は引き算が４回に乗算２回、それに比較が一回だけ。ホント、感激モノの美しさ。

『ビューティフルコード』日本語版発刊記念対談
久野靖×まつもとゆきひろ「コンピュータサイエンスをなめるな！」

最初、久野さんも変なこと引き受けたなあと思ったけど、感動しました。
　　――まつもとゆきひろ

　ニュースグループ fj.comp とか雑誌 bit の連載とか、懐かしい話で始まる対談。言語仕様の話も面白いけど、大学の授業でプログラミングを教える話も面白い。やっぱり初心者には、早く結果が見える道具がいいよね。Hello, world をどれだけ楽に出せるか、とか。ただ、ソコで楽するのを憶えると、後でｃとかを始めると死ぬんだよなあ。

　授業だと開発環境が整ってるから選択の幅も広いけど、そうでない場合は開発環境の入手･設定から始める必要があって、この辺が LISP系の弱みだと思う。まあ、今なら JavaScript が中身ほとんど LISP だったりするし。

　「初心者ならではの視点」がわかるのも、教える立場の醍醐味。なぜ浮動小数点でお金の計算をしちゃいけないか、とか。でも「アルゴリズムが違うと計算時間が格段に違うことを知って驚いた」ってのは、さすがに。そんなモンなのかなあ。

おわりに

　やっぱり泥臭いコードの話は楽しい。世の中、特に産業界だと、なんか上流工程の方が偉いみたいな雰囲気があって、コードの話は今でも「オタクっぽい」みたく思われちゃうんだよなあ。または API を知ってる人ほど偉い、みたいな。そういうのを、コラムというかエッセイというか、気軽な雰囲気で語る本ってのは、やっぱし貴重だと思う。

　さすがに体系的に学ぶには向かないけど、そこは各章についてる参考文献で補うということで。つか、巻末に参考文献一覧があったら良かったなあ。

【関連記事】

• Andy Oram, Greg Wilson編 Brian Kerninghan, Jon Bentry, まつもとゆきひろ他著「ビューティフルコード」オライリージャパン 久野禎子,久野靖訳 1
• Andy Oram, Greg Wilson編 Brian Kerninghan, Jon Bentry, まつもとゆきひろ他著「ビューティフルコード」オライリージャパン 久野禎子,久野靖訳 2
• Andy Oram, Greg Wilson編 Brian Kerninghan, Jon Bentry, まつもとゆきひろ他著「ビューティフルコード」オライリージャパン 久野禎子,久野靖訳 3
• Andy Oram, Greg Wilson編 Brian Kerninghan, Jon Bentry, まつもとゆきひろ他著「ビューティフルコード」オライリージャパン 久野禎子,久野靖訳 4
• スティーヴン・ベイカー「IBM奇跡の“ワトソン”プロジェクト 人工知能はクイズ王の夢を見る」早川書房 土屋政雄訳 金山博・武田浩一解説
• デイヴィッド・バーリンスキ「史上最大の発明アルゴリズム 現代社会を造りあげた根本原理」早川書房 林大訳
• 書評一覧：科学/技術