平成十七年十一月十五日晴天大安吉日紀宮清子内親王殿下御結婚之儀開催而地震是有於茨城県白林檎曰仰天動地也。哎呀。
皇室で吉事があって何か催しがあるとき、必ずボンボニエールなる小箱が引出物として下賜されるそうである。テレビの画面で見る限り、浅田飴の缶とベビーパウダーの缶のちょうど中間くらいの大きさの容器である。今回は陶器であったが、かつては金属製のものが多かったようだ。明治時代から始まった風習だそうで、サーヤのご結婚の儀に合わせて、京都の何とかいう博物館で歴代のボンボニエールが展示されている。そこの館長によれば、ボンボニエールとはフランス語で菓子入れというような意味で、必ず金平糖を入れて振る舞われる由。かつて砂糖が貴重品だった時代には、黄金と同じくらい上等な扱いを受けていたそうだ。
先日のT.F.の結婚式では、金平糖ではないが、土産として栗きんとんが振る舞われた。正月のお節料理に入れられるようないわゆる栗金団ではなく、もっと和菓子然としたものである。岐阜の名物だそうで、上品な甘さで、美味かった。食べればすぐになくなってしまうものの、記念品的な品物をもらうより、ずっと印象的だと思う。
賞味期限が翌日という点もT.F.らしいセンスが感じられて良かった。
そうそう、カスピ海ヨーグルトであるが、出来なかったのは気温の低いのが原因であったらしい。冷蔵庫から出して室温に置いておいたら、何事もなかったように発酵したそうだ。まったく、人騒がせな話である。
エセ漢文に誰も突っ込んでくれないので大変寂しい白林檎である。おかげで風邪をひいてしまった。もう大分良いが。
漢文といえば中国であるが、今、かの国では、大学生の自殺が社会問題になっているそうだ。一人っ子政策のおかげで過保護な上にも過保護に育てられ、了見の狭いまま突然激しい競争にさらされるおかげで、自己崩壊するケースがほとんどだという。他国の話とはいえ、嘆かわしいことである。
ところで、ほとんどのプログラミング言語では、ifという予約語が用意されている。これは条件分岐に使用するもので、平たく言えば「もしこういう操作がされたら、こう対応する」というプログラムを組みたいときに使うものである。多くの場合elseという語と対で用意されていて、「もし○○なら△△して、そうでなければ□□する」という動作をさせることが出来るようになっている。白林檎が愛用するPerlではelsifというのも用意されているが、
スペルが非常にビミョーという点も含め、機能やら何やらを調べてみるのもご一興だろう。
条件分岐はプログラミングに於いて最も基礎的な要素のひとつである。まあ、当然といえば当然だ。例えば自動販売機はコンピュータで制御されているが、そのコンピュータはプログラムによって動作している。100円を入れても500円を入れても同じ動作だったり、どのボタンを押しても同じ商品しか出てこないようでは、何の役にもたたない。役立たずどころか至極迷惑な存在になる。
そんなわけで、条件分岐はプログラミングの基礎的な要素である。と同時に分岐条件の設定、つまり「プログラムが動作するシチュエーション」を想定する能力は、プログラマの基本スキルのひとつと言って良い。大袈裟な言い方をすると、未来を見通す能力が、プログラマには求められる。過去の事例を参考にしたり既存の資産を活用することはもちろんあるけれど、プログラミングという作業に於いて、時間は常に「現在」よりも少し先を走っている。
どんな優秀なプログラマでも、予測を誤ったり、予想を遥かに超える状況に自分のプログラムがさらされることは必ずある。いわんや一般プログラマにおいてをや。一般プログラマレベルにすら達していない白林檎に至っては、自慢ではないが、作ったものが正しい(つまり白林檎の予測した)操作を一度もされずに終わることなどざらにある。
こういうとき、プログラムは──というより、それが動作しているコンピュータはエラーを出す。エラーが出るのは腹立たしいものだが、考えようによっては安全機構とも言える。思いもよらぬ使い方をされ、データが思いもよらぬ状態になったまま操作が継続されて、思いもよらぬ散々な事態になるよりは、「こんな状況知りません」といって中断した方が、結果として安泰な場合が多いからだ。
問題はエラーが発生したときの処理方法で、強制終了という最悪の事態を引き起こさずにいかにプログラムの進行を継続させるかが求められる。この辺もプログラマの腕次第ということになる。
少し余談になるが、
想定の範囲外という意味で、プログラムエラーのことを日本語では「例外」という。エラーが発生したときの処理は「例外処理」といって、プログラミングの教本などを見るとひとつの章を設けられていることが多い。
さて、ここまで書いたことは、何もコンピュータプログラミングに限った話ではない。製造業や建設業はもちろん、すべての業種にも当てはまる話であるし、それどころか個人々々にとっても身近な話だ。週末に旅行をしようと計画をたてたり、翌日の予定を確認して空き時間の詳細を詰めてみたりというのは、誰しも経験のあるところだろう。
中学校で素晴らしい成績を収めて○△高校へ進学し、現役で東大に入って首席で卒業した後、将来のことを考えてワカメを食べながら財務省官僚として働き、ゆくゆくは大臣になって故郷に新幹線を作るのだと野望を抱くのだって、いわば人生をプログラミングしているのである。
現代社会において、人生に線路を敷くのは親の役割であることが多い。いわば子供プログラマである。世の中から大人がいなくならないところを見ると、ほとんどの親が何らかの結果を導くことに成功しているということになる──最初に予定していた結果と異なっていたとしても、だ。
予定と異なる結果になるのは、子供の成長過程で、予想していなかった事がしばしば起きるからだ。だからといって、まさか成長をシャットダウンするわけにもいかない。そこで、方針を変更する。方針を変更すれば、それは結果だって変わるだろう。
こういうことはしばしばある。むしろ一度も変更されない方が稀であろうし、変更すなわち親の例外対応を経験していない子供は不幸ですらある。何か障害に突き当たったときに「一度立ち止まって、進路修正を行う」という処理が許されることを、親から吸収出来ないからだ。
正しい、あるいは比較的正しい例外処理を知らない人間は、例外にぶつかると、強制終了せざるを得なくなる。言い換えれば、自ら命を断つことを選択するケースが非常に多い。エリートとすることを期して英才教育を子供に施す者は、すべからく例外処理についてもきちんとプログラムしてやるべきである。それがプログラマの義務であるし、親として出来る最大限の教育というものだろう。
善哉々々。美しきかな樽募金。我らが広島東洋カープに栄光あれ。
いろいろ考えた末、白林檎はPerlと一蓮托生なるべしと心に決めた。仕事では都合というものがあるから、PHPを今すぐきっぱり捨て去るというわけにもいかないが、自分の匙加減でどうとでも出来るものに関しては今後一切perlに任せることにする。
Webに関わる上で、PHPは確かに便利な言語だ。セッション管理はしてくれるし、Cookieも手軽に焼ける。MySQLとは親密だし、マルチバイト文字の扱いも簡単で、ほとんどの場合CGIよりも速い。HTMLの中に埋め込める上、テキトーに書いてもあまり怒られない。最初からWebページをターゲットにして開発されてきただけあって、実に効率が良い。
正直言って、こういった使い勝手の面では何の不満もない。むしろ開発者の方々にお歳暮を贈りたいくらいである。
だが、実行環境が頻繁にバージョンアップされるのが実に鬱陶しい。バージョンを上げなければセキュリティ的にマズいことが多いにも関わらず、バージョンを上げるとそれまで動いていたものが動かなくなることも有り得るのが、実にウザい。まだ発展途上だからといえばその通りで、その成長も充分評価に値するとは思うけれど、いくらなんでもこれでは付き合いきれない。
最近ミョーな形の墓石を作るのが流行っているという話を、ある人から先日聞いた。形はともかく、墓碑には、
#!/usr/bin/perl
my $year = 1978;
while (1) {
die "Thank you all :)" if ($year++ > 2178);
}
とでも彫ってもらうのも面白いかもしれない。
ところで、Perlにもバージョンがある。おお。接続詞から始めると筒井康隆のようだ。
で、Perlにもバージョンがあって、現在は5である。5というくらいだから、過去には4もあったし、1〜3もあったに違いない。ぼくは4からしか知らないので、それより前のバージョンについてはよくわからないが、Perl 4からPerl 5にバージョンが上がるにあたって、ものすごい進化の仕方をした。オブジェクト指向プログラミングの概念の導入である。
プログラミング言語にもバージョンがあるというのが不思議だという人も多いと思うが、厳密にいうと、バージョンが上がるのは言語ではなく、それを処理するシステムの方である。もっとも、それに伴って言語の記法に追加や変更が加えられることも多く、その意味では言語のバージョンも上がると言える。
言語と処理系の関係は、ちょっと語弊があるかもしれないが、喩えるならOSとアプリケーションの関係みたいなものだ。アプリケーションの箱をひっくり返してみると、必ず「対応OS」とか「システム要件」とかいった項目の表示があるはずだ。古いバージョンのアプリケーションは大抵新しいOSで動かすことが出来るが、その逆、つまり新しいバージョンのアプリケーションを古いOSで動かすことは出来ないことが多い。まあ、大体そんなところだ。
とにかく、Perlでもオブジェクトを使えるようになって、大変便利になった。さらにはものすごい数のモジュール──これも敢えて語弊をおそれずに喩えるなら、Webブラウザのプラグインみたいなものだ──が、世界中の有志によってメンテナンスされていて、「ちょっと複雑なプログラム」くらいのレベルであれば、CPANを回ってモジュールをいくつか拾ってくるだけで実現してしまうことも多い。
ただ、Perl 5では、実際には本当の意味でのオブジェクト指向が実装されているわけではなく、既存の機能を応用して実現しているので、JavaとかPHPとかRubyとかいった最初からオブジェクト指向で設計された言語と比べると野暮ったいというか、取り回しが面倒なところがあった。Perlらしいといえばらしいのだが、PHPに徐々に取って代わられつつある原因のひとつであることも確かだ。
それを解決すべく、Perl 6の開発が進められている。はずなのだけど、困ったことに、どうも進捗が芳しくないらしい。多分、世間のPerl使いがPerl 5で満足してしまっているからではないかと思う。必要は発明の母というが、その逆の状態に陥ってしまっているのではなかろうか。
一蓮托生と決めた以上、何か貢献出来ればいいのだが、この場合Perl 5を愛用していてもあまり解決にならないわけで。でも、まあ、世界の隅っこでPerlスクリプトを書き続けるのも、Perlの勢力を維持するのに必要なのかなあ、などとも思う。優秀な枯れた言語であるが故のジレンマと言えるかもしれない。