さてそういえば今日は閏日ですね。例の２０００年問題、というのは本質的に汎用機の問題だったわけですけども、パソコンでも、うるう日判定を間違う可能性がないわけではなかった、ということをご記憶でしょうか？

うるう日のルールというと、

1. 1. 西暦年が 4 で割り切れたら閏年 (+)
2. 2. 西暦年が 100 で割り切れたら平年 (-)
3. 3. 西暦年が 400 で割り切れたら閏年 (+)

というものでした。プログラマ的には「より詳細な条件に当てはまるたびにフラグを反転する...」という感じで実装するのがいいかな。勿論、ＯＳライブラリのレベルでのカレンダーは、正しいルールを知っていますけど、「ちょっとした処理」をしたいケースで自分で「うるう判定」しているケースがあると、

1. 1. え、うるう年って４年に一回でしょ！ → 知識不足ですがセーフ！
2. 2. そういえば世紀の変わり目の年はうるう年じゃないはず...→ 知識が半端でアウト！
3. 3. そうでも 400 年に１回はうるう年。→ 正確な知識でセーフ。

....という逆説的な結果に終わったわけで、いちおう騒ぎにはなりましたが、それほど「凄い」ことにはならなかったわけです。勿論問題を起こさなかったプログラムのほとんどは 1. で、3. は少ない....でしょうね（ライブラリを使っているケース以外ですとね。かなり皮肉ですけどね）。

ではクイズ。今年（2008年）は、地球が太陽の周りを１回転する間に、何回自転するでしょうか？？　あるいは、「今年」何回自転するでしょうか？

答え：勿論イジワルなひっかけ問題です。「今年」の定義は、ホントは見せかけのトラップに過ぎません。まあ、「今年」の開始と終了をどこで定義するか（閏年の１年を366日とするか、平年と同じで 365.2425日とし、それを切り捨てて 365日とするか）は、どっちで解釈してもいいんじゃないか、とも思います。ホントのトラップはですね、

太陽を１回転する間、その公転の効果によって、１回分余計に自転する必要が出ます。つまり、平年３６５日の間、言い換えると地球上の人間が「３６５日」を経験する間、地球は３６６回自転します。地球の自転の周期は２３時間５６分しかなくて、この４分の誤差が１年間積もって、１回分の自転になります。

ということです。ちょっと「２０００年のうるう年」と話が似てませんか？

たまにはお気楽で直接コンピュータとは関わらないシュミな話でも。

土曜日に友人のイベントに行きましたが、そこで発見したのが知る人ぞ知る「MOOK きのこ」です。思わずそこにあった最新３冊を購入。噂には聞いてましたが、面白い雑誌です.....あ、これ「きのこをめぐるカルチャーマガジン」というキャッチフレーズで、日本キノコ協会という「きのこ愛好家サークル」が出している一種の同人誌です。とはいえ、アマチュアマニアの雑誌というと、話題は専門的で狭い...んじゃないかと思うところですが、「MOOK きのこ」は「とにかくきのこが扱われていれば何でもＯＫ！」なかなりアバウトな編集方針（とそれを受け入れて平然としているキノコという存在の凄さ）のもと、実に多彩な「きのことそれに関連する全カルチャー」の雑誌になっています。

勿論ナチュラリスト系のキノコの美麗な写真もあれば、キノコをかわいく使った手作りクラフトの作り方、キノコを画題にした絵画、あるいはキノコをおいしく食べる食べ方、あるいは「キノコ妖怪」のイラストだ、キノコの切手コレクション、ベニテングタケと伝説の幻覚剤ソーマとの関連、キノコに関連するお菓子の紹介、毒キノコ中毒事件の事件史....とホントにありとあらゆるキノコの話が載った雑誌なのです。

執筆者にもナニゲに有名人が参加してたりもします。料理コーナーは奥村彪生氏ですし、切手コレクターは写真評論家の飯沢耕太郎氏、キノコグッズのコレクターはゴンチチのチチ松村氏...といった具合にメジャーなのかマイナーなのかよく判らないようなラインナップです。

しかもデザインがコーナーによっててんでバラバラなので、ちょっと読んでいて感覚がクラクラするようなところもあります....ほんとキノコの毒にあたったのかな。で、よく考えてみると、この雑誌、

いろいろな人が書き込む掲示板みたいな雑誌

というのが一番当たっているようにも思います。感覚が強くネット的なんですね。有名人もいますが、フツーの人もいます。指向性もバラバラですが、なんとなくの全体的統一感（勿論キノコ、という枠組みがあるおかげです）もあります。アングラといえばアングラですが、「他人が読む」ツボはきっちり押さえているので、楽しんで読めますし....と感覚をクラクラさせながら楽しみました！

MOOKきのこは、ひとりひとりはかぎりなく非力で半端なアマチュアが協力しあい、それぞれの持ち味を発揮してめくるめくきのこの世界を表現し、それらの多面的な活動を文化・芸術運動として記録・定着させていこうと呼びかけて誕生しました。会員は日本キノコ協会同人と年間購読会員からなり、きのこ同様、全くの横ならびの自由で平等な編集方針をとっています。

とあとがきにあります。こういうスタイルは意図的に選択した確信犯なのですね。ちょっと一読の価値があります。関西では取り扱い書店が多いですが、ジュンク堂ならどこでも扱うようですし、東京なら八重洲ブックセンター、紀伊国屋新宿本店、青山ブックセンターなどでも扱うようです。オススメですよ！

ちなみに今日の夕食はカキとアスパラとシイタケのシチューにしました。やっぱりこういうの読むとねえ....タイトルは「きのこ趣味世界の振興に貢献した、今は亡き内田正宏さんの造語だそうです」（第１２号巻頭より）。食べるキノコを堅苦しく呼べば「食菌」ですよ！

待ちかねてました。昨日 Armstrong の「プログラミング Erlang」が出てました！

で、とりあえず一通り斜め読みで目を通したあたりです....去年年末に出ていた「Erlang 入門」と比較すると、定価は２倍ですが、内容は５倍（あるいはそれ以上）のものがあります。ひょっとして今年の台風の目、かな？

たとえば、まつもとゆきひろ氏も「Rubyはもはや当たり前。「次」とは言えない／次にくるトレンドは「関数型」と「並列」 ／両方を押さえたErlangが本命。歴史も信頼性もあり、知名度上昇中」として、Erlang を推薦していたりします。ここで開発者自身の解説本が出る...というのは、ツボを得てますね！

しかも、この Armstrong 氏、いかにもハッカーっぽいユーモアのある文体がいいです（訳文もツボを押さえていて読みやすい）。たとえば、技術的にポイントとなる章の前に、「ポイントを押さえた非技術的な紹介」を入れていたりします。その中から Erlang 最大のポイント「並行処理」を紹介すると、

人間なら誰でも並行処理を理解している。

我々の脳には生まれつき、並行処理が強く刻み込まれている。刺激に対して人間は脳の扁桃体と呼ばれる部分を使ってとても素早く反応する。

この世界は並列だ。

実世界のものと同様に振舞うプログラムを書きたいなら、プログラムは平行構造になるだろう。だから並行プログラミング言語でプログラムしたほうがよい。しかし、実世界のアプリケーションを逐次プログラミング言語で書くことは多い。そのために物事が無用に難しくなってしまったいる。平行アプリケーションを欠くために設計された言語を使おう。そうすれば並行処理の開発はずっと楽になる。

ホント、この文は Erlang 最大の宣伝文句じゃないかな、と思います。しかも、Erlang は「単に並行処理ができる」というだけの言語ではないのです。

1. 1. サーバの動作を監視するスーパーバイザを簡単に作れて、
2. 2. サーバを停止せずに、サーバをバージョンアップできる...という魔法（ホットスワップ）が使える！
3. 3. で、それが「できる」というだけではなくて、Ericsson での社内実績がきっちりある OTP というプラットフォームがある。OTP に対してコールバックモジュールを付け加えるだけ（かなり簡単！）で、任意のサービスを提供するサーバを作ることができてしまう！
4. 4. OTP にはデータベース Mnesia が付属していて、分散処理に対応し Erlang オブジェクトをそのまま保存できる安全なＤＢがタダで手に入る。
5. 5. 勿論アプリに必要なライブラリは一通り完備。

というくらいなものです。Erlang(OTP) とプロトコルを理解すれば、すぐに実戦に投入できる（任意の）サーバが作れちゃう....というくらいに、ものすごいものなのですね。それこそホビー用途だったとしても、「買い！」な言語ですが、きっちりと実績もあるようなスグレものだそうです！ この「プログラミング Erlang」では OTP, Mnesia の解説もちゃんと載っていて、自分で試すことができます。

で....Google と言えば？

それは mapreduce だ！

という方はあまりいない...（苦笑）でしょうけど、Google 検索ロジックのキモのアルゴリズムが mapreduce というものです。これ要するに「関数型言語を使って、スケーラブルにした索引エンジン」です。ですから Erlang と同じコンセプトのわけで、最後にこの mapreduce を Erlang で実装したサンプルが載っていたりします。ホントこれだけでも充分にお買い得な本...と思わないですか？

あ、勿論その他の Erlang の「面白い特徴」はもうすでに以前のエントリに書いてますし、他のブログ・ページ（まつもと氏、Erlang Tips , Erlang Land）にも結構ありますから、そちらをご覧ください。とりあえず今回は「本のレビュー」です。

日々のプログラミングの雑感です。

やはり仕事のプログラミングですと、他の方が書かれたプログラムを修正して....というのが、大きなウェイトを占めるのは当然です。このとき、いつも私が気になること、というとか「私がいつも気をつけて実践している、複雑さを低減する有効な手段なんだけども、あまり他の人が理解していない」と見受けられることについて書きましょうか。

その基準、というようなものは、単純にこのコトバで表せます。

ゲッタは、外部から見える副作用を持つべきではない

ということです。この原則を私が理解し受け入れたのは、やはり Meyer の「オブジェクト指向入門」での主張がきっかけです。Meyer が作った言語 Eiffel は Pascal(Ada)ベースですから、

値を返す function（関数）← Java だとゲッタはこれ

と、

値を返さない procedure（手続） ← Java での典型はセッタ

をキッチリ構文上区別します。でしかも、「値を返す関数」では、「副作用がないこと」、言い換えると「オブジェクトの状態を変更しないこと」を強く推奨しています。ここでは「外部から見える」という限定が付くわけでして、勿論こういうかたちでの副作用はＯＫです。

1. 1. そのオブジェクトのライフサイクルの中で「一度だけ」しか実行されない初期化の呼び出し（たとえばいくつかあるゲッタで最初に呼ばれたものが、全体の初期化をするとか）。
2. 2. 参照を最適化するために、今まで取得されたデータをキャッシュする。

この２つのタイプの副作用は、外部からは完全に隔離されています。「副作用があったか」どうかは、外部的な振る舞いには一切の影響がありません。こういうのはＯＫなのです。

....仕事でよくトラブルの根源になるのは、やはり「副作用のあるゲッタしかない（しかも引数付きとか）」ケースで、「副作用がないつもり」でそれを呼び出して、想定外の結果を得ることがあるわけです。特に、引数付きで副作用のあるゲッタというと、これは単純に「引数付きのセッタ」と「引数がなく副作用もないゲッタ」に分離できるケースがほとんどなのです。

もし、「動作に必要なプロパティが全部揃ったこと」を前提として、何かの内部オブジェクトを構築する必要があるのならば、それはコンストラクタ引数でそういう制約（そのケースではセッタ自体コンストラクタ引数に解消すべきです。そうできるケースでは Immutable ＆ FlyWeight の恩恵が受けれるかもしれません）を与えるか、たとえば activateOptions() のような名前の無引数のコマンドを用意して、これをトリガにして内部オブジェクトを構築すべきです。activateOptions() という名前は Log4j のAppender仕様で憶えて、気に入ってます。何するか分かりやすいでしょ。

勿論こういう明示的な処理化トリガコマンドはきっちりドキュメントして周知徹底すべきです。私はこの分離が、「何か暗黙のセッタ呼び出し順に依存してなされる初期化」や「他のプロパティへの依存性があるゲッタ」よりもずっと優れている、というように思うわけです....

....こう考えてみて、この構図って実は REST とも似ているようにも思います。REST原理だと、

• GET は、副作用がなく内部状態を変更しない（だからキャッシュできる）
• PUT, DELETE, POST は副作用があり、内部状態を変更する。この時、PUT, DELETE は更に「べき等であるべし」という制約がある。

こう見てみると、まったく同じことですね。更に考えれば「セッタのべき等性」も制約に付け加えてもいいのかもしれません。「追加的」な変更は常に set～()  ではなくて、add～() か append～() という名前で明示する、というルールも導入したいところです。

皆さんはいかがでしょう？

私が友人と話していた時のことです。

私：３つのパラメータがあって、それぞれが独立に２つの状態を取るから、全部の組み合わせは８個になる。
友人：え、それって６通りじゃないの？
私：（もう一度説明を繰り返す）
友人：６通りだと思うんだけどなあ...

この友人、職業は医者です。ですから、理系の入試を通って大学に入っているんですけどね.....というわけで大問題「プログラマと数学」ですね。

実は私、大学は文系で文学部心理学科卒です。元々プログラミングをし出したのは、やはり心理学の実験データ解析が名目でした（ゼミの先生の著書が因子分析の本だったりしました....）。文系とは言っても数学は大好きで、教養でも数学の単位（初等整数論からカントール濃度の話になる講義でした。面白かったし、後々役にたったことがあります）を取って、「変人」みたいに見られた思い出（苦笑）もあります....

プログラミングをするようになっても、たとえば数学ベースの技術書から、アルゴリズムを取ってきて、自分で実装した（スプライン曲線とかＦＦＴとか必要に迫られて）こともあります。そういう具合に「数学を怖がらない...」というのは非常に役にたっているようにも思います。でもそういうの、年に１回もないんじゃないかなぁ。

しかし、ちょっとしたことで、「数学センス」みたいな部分、というのは非常に「日常のプログラミング」という部分でも役立つところ、というのはあるようにも感じます。何というのでしょうか、「数理的なカン」が働くのですね。詳細なアルゴリズムの細かいところで「あ、これ情報が足りない」とか、「考え方が美しくない...」とか、かなり早いところでカンが働く、というのはあるようにも思います。また、それこそ「プログラマの教養」というか、数理的なアルゴリズムを理解する（ＲＳＡ公開鍵暗号とか）あたりでも、やはりバックグラウンドが理解できますからね。

というわけで、ちょっと雑感です....

クイズ：「どんなファイルでも、かならず元のバイト数よりも小さくなる」という圧縮方式がウソであることを説明せよ。（ヒント：マッピングの問題として考えると変換先が足りなくなりますよ...）

追記：ファイルサイズが任意の n byte より小さい場合は、サイズが変わらない（あるいは逆に大きくなるとしてさえも）、としてもホントはＯＫです。また、問題では「バイト数」としましたが、「ビット」単位で考えても結果は変わりません。

昔のオーディオマニアの金言として有名なのは「入り口と出口にカネをかけろ！」というものでしたよね。つまり、レコードプレーヤーとスピーカーは、他のものより重点的に予算を配分してステレオセットを構成する...というのが定石のわけです。

２月１２日の毎日新聞夕刊に、内田樹氏のコラムで「情報と情報化」という記事がありました。養老孟司氏から教えてもらった、ということで、

「情報化」というのは「なまもの」をパッケージして、それを取り扱い可能な「情報」に変換する作業のことである。

という定義を紹介しています。で、このコラムの話は「情報化」にまつわる落とし穴についての警告で、

『情報化が適切に行われているかどうかのチェック』は生身の人間が、手間隙をかけてしか成し遂げることのできない種類の仕事だからである。

というものです。私どもプログラマ、というのは、「情報化されている」という前提で何事も進めていく立場にありますから、ある意味「情報化プロセス」は前提条件なんだけども、直接触れない...という微妙な立場にあって、結構はがゆく思うことなどしょっちゅうあるわけである。そういう意味で「よくぞ言ってくれた」という風に思うのと、「今更言われたって...」と思うのと半々くらいかな。

だから以外に私なぞ、「情報化」の部分の技術というのは結構関心があったりします。「コンピュータの中の世界」には詳しいけども、それが実世界との境界にあたる部分で何ができるのか？というあたりでは、「何もできない」というのでは情けないでしょう。コンピュータを使って何でもできる、とウヌボレていても、「じゃあ、夜７時になったら電灯をコンピュータを使って点けてみて！」と言われても、できないというのは、やはり「電灯を点ける」というのが適切に「情報化」できていない、というあたりにあるわけです。

とはいえ、同じような状況、というのは別口でプログラミング自体の中にも現れるわけです。これはゲーデルやチューリングが証明したこと（ここでの表現は超甘口アレンジです）ですが、

あるプログラムが「正しい」かどうかは本質的に証明不可能である

ということです。これはこう考えてみると得心がいきます（証明じゃないです）。

1. 1. プログラムのすべてのコードを全部バイト単位で連結して、一つの非常に巨大な数字であるとイメージしてください。この時、バイトを数字の桁である、という風にイメージするといいかな。
2. 2. では、「正しい」プログラムと「似た」プログラムはいくつあるでしょうか。たとえば「正しい」プログラムと一つの桁だけ違うプログラムは「似て」ますよね！
3. 3. プログラミングとは、膨大な候補の中から、「正しいかもしれない数字を選択すること」なのかも....

だから、デバッグも実は「情報化」なのであって、「情報化（プログラミング）が適切に行われているかどうかのチェック」を生身の人間が手間隙をかけてしないわけにはいかないわけです！

入り口と出口にカネをかけろ....というのはなかなかプログラミングではムリ、かなぁ.....

そういえば本を買いました。「プログラミング言語 Erlang 入門」です。

Erlang は関数型言語で、平行プログラミングに特化した仕様が面白い言語です。でこれ、「理論家が作った言語」....というわけではなくて、「すでに実戦に投入されていて、実績のある言語」というあたり、興味深いわけです....あ、要するに、元々エリクソン社の社内言語として開発されて、エリクソンでの豊富な経験があり、しかも Twitter でのメッセージング・サーバで使われていたりして、結構注目を集めた言語だったりするわけです。→twitterブームの陰で注目を集める“Erlang” , Rubyist のための他言語探訪 【第 10 回】 Erlang

 
というわけで年末に入門書が出まして、これが「プロミング言語 Erlang 入門」（アスキー・柏原正三著）です。結構やさしめの入門書なので、やや歯ごたえない感じですが、2/23に Erlang を開発した Joe Armstrong の本格的な解説書である「プログラミング Erlang」の翻訳が出る...らしいです（版元はオーム社）。ちょっと注目されそうな気がしますから、予習ですね。

 で、言語の感想....というと、この Erlang は当初「Prolog の改良」から始まったようで、いろいろと言語仕様が Prolog 臭いです。私は４０台半ばなので、例の「第五世代コンピュータ」プロジェクトにノセられて、８０年代に Prolog を勉強したことがあったりしますから、

なんか懐かしい....

というヘンな感想をまず持っちゃったりしてます（苦笑）。とはいえ、Prolog  が元祖みたいな、

パターンマッチ主導で宣言的に書いていく書法

というのは、Haskell でも採用されていて、「Lisp 風のカッコだらけでない関数型言語」の一つのパターンを作り出している、という感があります。ですから、「結局何も生み出さなかった」ことになる「第五世代コンピュータ」でも、Prolog とか Haskell に対するプログラマの心理的な敷居を下げる、という効果くらいはあったのか....などとも個人的には思ったりします。

 さて、今年の台風の目がコレ、になるのかもしれませんよ.....北欧は Linux みたいに革新的な風の元になる傾向がありますからね....

前回の構文解析話の続きです。

構文解析という技は若干特殊なテクニックではあります。ですから私もこの技法については結構一生懸命勉強したことがあります（１５年くらい前かな）。そのテキストに使ったのは「lex＆yaccプログラミング」でした。 この本、元はオライリーの本なのですが、動物本もまだ最初の頃で、オライリー・ジャパンではなくて、アスキーとかオーム社とかで、翻訳本を出していた時代の本（この本だと翻訳出版元はアスキー）でした。

で...この本、今 amazon で見てみると、新品はなくて中古がリストアップされています。 価格はというと、最安値 10.650 円.....元の定価は 3.600 円でしたから約３倍のプレミアがついちゃっているわけです。で、しかもこの10,000円～15,000円価格帯だとかなりの人気本のようです。

コンピュータ関連書、というのは意外にプレミアがつきにくいタイプの本でしょうね。まあ、これには理由があります。

1. 扱われている技術が「古く」なってしまうと、それが欲しい人がほとんどいなくなる。「古くならない技術」でないと、本としての価値もない。→ lex ＆ yacc はコンパイラやインタプリタを自作する時の必須基礎技術（いわゆる「コンパイラコンパイラ」）なので、コンパイラとインタプリタが存在する限り、必要な技術である。しかも UNIX 上のアプリとしての lex, yacc(flex,bison) は典型的な「枯れた」ツールなので、15年前の情報でも充分使える。


2. ネットの上で簡単に手に入る情報では、ちょっと実用レベルで使えるような知識が得られない程度にムズカシい技術でなければ、本としての需要もない。
まあ、lex, yacc による構文解析の解説ページ、ともなると、これ相当にタイヘンなものになってしまいます。やはり本として読んで理論をきっちり理解してから使う、というプロセスが必要なくらいの難しさがあるツールです（理論的にはいわゆる「文脈自由文法」を使うわけですし....）。

3. 類書が出にくい。そりゃやはりプログラミングの中でも、専門性の高い部類の技術ですから、売れません。出版企画として難しい部類でしょう。この「lex ＆ yacc」なんていうと、「これを読んでいれば、ドラゴンブックの翻訳第１巻は斜め読みでもＯＫ」と言ってもいいくらい、「凄い」ものが類書です。これじゃ陳腐化はしませんよねえ。

少し面白がって、高額な中古価格のついているコンピュータを調べてみました。こんなの高いようですよ（選択は趣味的です。言語ツール系に偏るのはごめんなさいね）。

Ｈｉｂｅｒｎａｔｅインアクション(12,800～)　新しい本なので、意外ですね....

Scheme入門（湯浅太一・12,470～）　私はこれでSchemeを勉強しました。Scheme の書籍って未だに３冊くらいしか出てないですね。

オブジェクト指向スクリプト言語Ruby（まつもとゆきひろ著, 18,995～）　開発者著書。

データ圧縮ハンドブック（ネルソン＆ゲイリー、20,000～）　圧縮アルゴリズムを丁寧に解説した良書です。愛読しました...

クイズです。

次の擬似コードの出力は？

もし A(=真) または B(=偽) かつ C(=偽) ならば
　　「OK」を印字する
さもなくば
　　「BAD」を印字する
終わり

.....要するに、論理演算子の優先順位の話です。これは大概の言語で演算子結合順位が「かつ」の方が「または」よりも高いために、

もし A(=真) または （B(=偽) かつ C(=偽) ）ならば

となって、全体が「真」になって「OK］が印字されることになります。ま、ここらへんややこしいので、皆さんも

不要であってもカッコを使って、結合順位を明示するべきだ

と教わったと思います。私は今の仕事でＵＩを作って、その中で論理演算子とカッコを使って、「複雑な検索条件をユーザが作り上げて検索する（参考：軽業Web）」ということをしてたりします。で...この時、

ノンプログラマの一般のユーザさんがこーゆー演算子結合順位なんて判るわけないよね！

というわけで、演算子結合順位を無視して同レベルと捉え、単純な左結合で連結する、というかたちで実装した...のはまあ判りやすさ優先の甘口実装なんですけどね。

ですから、ちょっとがんばりました。一応「自然数式処理」みたいなかたちでスタック使いの処理を書いて、カッコを評価の上で and, or を節点に持つ木構造を作る、というかたちでの実装です。

で....気になるのは、やはり次のことです。

一体プログラミング言語の演算子優先順位で、and と or のレベルは一般論としてどうなっているのだろう？？？(同一レベルとして評価する言語は果たしてあるのか？)

ということです。調べてみると、当然モダンな言語（Ｃ以降）では、and が or よりも高いのは当たり前です。しかし、SQL だって、and 優先ですし、Fortran, Pascal, COBOL のようなクラシック言語でさえも、and 優先です....だから「and優先」はほとんど例外のない一般的なルールのようですね。

考えてみると、かなり「数学的な」根拠から、「プログラミング言語の一般ルールが確立する以前でも、and は優先だ！」という考えがあったような雰囲気です。自然数式処理の場合、「乗算は加算に優先する」という明白なルール(これに背くAPLなんてものがありますが)をプログラミング言語でも採用するわけで、そのアナロジーで、and/or の論理演算も、広く「ブール代数」として捉えれば、and が論理積になり、or が論理和となるので、「積は和に優先する」する結果になります。

この優先順位が「コンピュータ言語のはじまり」から常識と捉えられていて、それを後の言語も自動的に受け入れてきているもののようですね.....