C++

今更ながらSTLをお勉強

某MLの影響でしばらく忘れ去っていたC++のStandard TemplateLibrary(間違っても某社の中間管理職のことではない。)のお勉強などを。以前C++を触っていた頃は、templateの動作がおかしかった(というか、仕様の通りに動作するようなコンパイラの実装系はなかったのね)ことと、STLって便利なコレクション系データのライブラリなのねと言う誤解があったことで、なぁなぁなお勉強になっていたのでした。
今日久しぶりにC++をSTLを使おうと思って、7年くらい前に購入していたεπιστημηさんの「Standard Template Library プログラミング」を再読することにした。(今じゃWebで読めます。) これまで根本的な誤解をしていたような気がするのだが、STLの肝 はループを抽象化したAlgorithmなんですね。(今更気がついたのか) Collectionへのアクセスはポインタを抽象化しているIteratorを、ループのカスタマイズをFunction Objectで行うのですね。いやぁ疑問が氷解というか、年食うとなんだか昔分からなかったことが、さくっと分かるようになるもんですね。(まぁ実際にプログラミングに生かせるかどうかわからんが。) とりあえず、凄く勉強になっています。(というか、勉強しなさい、コードを書きなさいと言うことなんでしょう…)

Lightweight Language Weekend 1日目

行ってきました。ざっくりとした的確な要約は、まつもとゆきひろさんのMatzにっきを参照。(こんな手抜きで良いのかな。)
あまりに手抜き過ぎなので、印象深いところをかいつまんで。今回はPerlにしてもRubyにしてもPythonにしても大きな変化がなかった1年なので、逆にマイナーな言語の存在が目立つカンファレンスでした。特に、SchemeやHaskellと言った関数型言語の人が目立ったなぁ。
今回特に面白かったなと思ったのはSchemeの1実装であるGaucheですかね。ここ数年Schemeは忘れ去られていた感がある(入門的な書籍類が全て無くなっていたので)のだけども、国内的にはGaucheのおかげで復権したと考えて良かろう。またどの言語でもキラーアプリがあれば動き出すのであるが、Gaucheは継続ベースのWebアプリケーション・フレームワークであるKahuaが最近広まってきていて、その紹介などがあった。HTMLをさくっとS式で書けるのは良いかもしれない。あとSchemeを勉強していてサッパリ分からないものの一つが継続で、これはいったいなんじゃろ？と言うあたりが今回少し解決した。今日あたりから「何でも継続」を読んで、真面目にSchemeで遊んでみようと思います。SICPでは凄く後のほうに載っていますが、LISPとは根本的に違うScheme特有の概念だと思います。
あとGroovyの話も面白かった。(「Javaの奇妙な冒険」と題した後半は爆笑物だったが。絵は補完すること。) JavaVMの上でJavaのSyntaxに似た言語で、Ruby-Likeなクロージャー(一昔前までイテレータと呼んでいたもの)を書ける言語で、出かける前にこれはなんじゃろねと言う話をしていたが、なるほどなと思いました。(出かける前までは_またよく分からない俺言語誕生かと揶揄していたので_)まぁよく考えれば、JavaVMのパフォーマンスがあがれば、何の変更もなくパフォーマンスが良くなるわけだし、もっとも多くのVM開発者がいるのはJava周辺ですから、こういうアプローチはアリかもしれない。(JavaのAPIをそのまま使えるというのはおまけだろう。)
「LLでお仕事」のBOFではいろいろと悲しい話を聞く。まぁ今回のカンファレンスではJavaは明らかにアウェーであるのは確かなのだが、LL全体としてはCやC++、VB、Javaに比べると立場が弱い。あとLLの中でもPerlは割と認知されているが、「Rubyで書いた検証プログラムを顧客の無理解から泣く泣く書き換えた」というかなりショッキングな話もあって、三浦さんとPerlで書き直したソースを解読するよりrubyを勉強する方が時間かからんだろうなどと言っていたのだが、何とも切ない話だ。クライアント側で考えると選択できる言語の幅は狭いので泣く泣く環境を選ぶことはあるのだが、サーバーサイドなら何とか選べるんじゃないと言う意見もあった。あと印象的だったのは、まつもとさんの_「秘密兵器」としてサクセスストーリーを積み重ねるしかない_というもっともな意見で、僕もそう思う。まぁこういう便利なものは便利と悟った人が効果的に使えばいいのかなと思う。
「君ならどう書く」のセッションでは前半は「ls-lRシェル」、後半は「n-Queen」ゲームと言うことだったが、前者は各種言語の考え方は分かるのだが、デザパタに当てはめるのは結構無理があるような… 後者はプロトコルは格好いいんだけども、ゲームバランスが… HTTPでなくて独自プロトコルの方がまだ良いかもしれない。あとルール的には誰かが負けるとおしまいでなくて、最後まで残ったものが勝ちとすべきだったかもしれない。まぁ来年以降の課題ですな。

新たなる戦いの序曲

この日記のタイトルを「戦いの軌跡」としているのは、この日記を付け始めた頃の2001年5月31日の記事にあるように、自宅の通信環境を高速化するための飽くなき戦い(他にもいろいろあるけれど)を書いてみようと言うことからだったのである。今振り返ってみるといろいろあった。某歴史的ベストセラーの如く「光あれ」と言ったら、光がある。すなわちさくっとFTTHな環境になるんだったら苦労はないのである。
ここに来てようやく直接自宅に線を引けるようになった。ここまで戦いを繰り広げたのだから、実際に線を引くという段階で_光であること_と_固定IPアドレスであること_が最優先での選定となった。居住している地域からNTT東日本のB-Fletsのニューファミリータイプとなり(東京電力のTEPCOひかりは隣の市まで来ているんだがなぁ)、ISPは使ってきたサービスにあわせていろいろ変えてきたが、技術的に信用を置けるISPは最初に選択したIIJ4Uを越えるところはなかったので、当面かなり高いサービスであるが、IIJmioのFiberAccess/SFとした。(IPv6トンネリングサービスを受けてみようとおもったのもある。)
今日の工事でようやくB-Fletsを使える環境となった。実際にFlets Squareでの速度確認では遅い時でも50Mbps程度、速い時では80Mbps程度出ているようなので、当面非常に贅沢な接続環境となった。まずどこにISOイメージを取りに行っても、使い切るような速度ではあるまい。
これで長かった一つの戦いが終わった。が、しかし_新たなる戦い_がこれから始まるのである。本来インフラを整えるのが目的ではなく、その向こう側にあったインフラの利用が目的なのである。すなわち、自宅サーバを構築した上で、構築したサーバを使って_遊びたい_のである。ということで、新たなる戦いに身を投じることになるのである。

Java 2 Platform, Standard Edition (J2SE) 1.5.0 Beta1

2月4日にSun MicrosystemsからJ2SE(Java 2 Platform, Standard Edition)の次期バージョンであるJ2SE 1.5.0 Beta1が公開された。JavaはまだJDK1.0のα版とかβ版とか言っていた頃の熱い時代に熱狂的に遊んでいたが、いろいろ熱が冷めるような事件があって、さらに諸般の理由があって_使わない/使えない言語_であった。いままでわりと保守的な更新を続けてきたJavaであるが、J2SE 1.5.0(コード名「Tiger」)では、Java2になったときと同じ程度、もしくはかつて例のない大きな改良が加えられることとなった。言語仕様に関わりそうなものは、ざっくり…

GNUの20年

ずいぶん前の話になるが、昨年はrmsがGNU Projectへの呼びかけ(翻訳,後の「GNU宣言」の元になる文書だと思う)から20年目の年だったそうな。昨年の9月末の話なので何をいまさらという話であるが、1月5日のNewsforgeにrms自身による「The Free Software Community After 20 Years: With great but incomplete success, what now?」という記事(和訳)が掲載されていたので、読んでみて思い出したかのように日記の記事にすることにした。
ソフトウェアにそれなりに踏み込んでつきあうようになると誰でもそうであると思うが、GNUの成果物の恩恵に預かっていることに気づかされることが多い。僕の場合は今年で11年目になると思う。最初の出会いはテキスト処理をするために使い始めたawkであるが、MS-DOSで使っていたので当然GNU版のawkであるgawk(の日本語版jgawk)だったように思う。当時書くのもめんどくさいテキストファイルのフィルタ処理がこんな簡単な言語でできるもんだと感動して使った記憶がある。(その後、awkの使いこなしでは師匠に絶対勝てねえと思ってperlを使うようになりawkを忘れ、今はテキストの処理の需要があまりないのでなんにもやってないが。)
その後、数値計算でCでプログラムを書く機会が多かった(Fortran嫌いなんで)ので、MS-DOSでMS QuickCを使っていた。Cを始めた頃はこの処理系でよかったが、当時積分計算をすることが結構多くて処理速度を稼ぐために最適化をかけたいことがよくあった。ただMS-Cのような処理系は_学生時代には絶対買えないお値段の処理系_(今も買えませんが)で、とても手を出せる状態にはなかった。またMS-DOSの制約以上の大きなメモリ空間を計算上必要としていたこと(こっちの方がより重大だった)ため、どうしてもMSのツールじゃ駄目だった。そんなときに大学のFTPサーバを覗いていて発見したのが、GNUのCコンパイラGCCのMS-DOS版であるdjgppでした。DOS-Extenderという妙な環境で動く何ともしれないコンパイラだったが、結構長い間愛用していた。
その後のLinuxの登場によりMS-DOSという妙な環境ではなく、何の制約もないUnix互換環境でGCCを使えるようになったので、ソースファイルごとLinuxの環境に移行してしまい、それ以来何かツールを作る環境はLinuxの上でやってきているし、こんな素晴らしいものはないと言うことでLinuxや*BSDの普及活動に時間があったら手間を惜しまず関わっている。まぁ最近はC/C++でプログラムを書くこともなくなったので、すっかり一利用者になってしまったけども。(お仕事上のVBAは除く。あれは選べない環境なので。)
最近の風潮ではGNUのGPLによる配付の縛りがきつすぎて、_GPL嫌い_な人を結構見かけるが、近年のオープンソースムーブメントのよりどころは_Linusによるバザール的開発手法の発明_とESRによる精緻な再定義によるものだとかんがえられる。しかし実際にはそれ以前の_rmsのFree Softwareの運動が基礎として存在_しており、GNU嫌いな人も_アンチテーゼとしての存在としてのGNU_なしには語れない訳だから、すべてに対して影響を及ぼしていると考えて良いと思う。改めて凄いことだと言わざる得ない。
さて、最初のrms自身の記事にもどるが、ちょっと過激なところはあると思うが大いに刺激を感じる記事かと思う。たしかに僕自身も特許やら企業秘密の中に生活している人なので、特許や企業秘密に依存するソフトウェアがどうしてもclosedでものでproprietaryな物にならざる得ないのは理解できるので、「Non-free software carries with it an antisocial system that prohibits cooperation and community.」は、ちょっと言いすぎだろうと思うが、先鋭的な意見を述べて戦い続けなければならない立場を考えると、確かにそう言い切ってしまわねばならないのだと思う。
さらに読んでいくと、

.NETの呼び声

最近、VBAでのプログラムにほとほと嫌気がさしてきたのであるが、お仕事関係ではMicrosoft WindowsというかMicrosoft Officeの呪縛を逃れることは出来ない。それ故プログラム環境としてVisual Basic for Application(VBA)を使うことになるのであるが、不満は多いので使っていてなんだかだめだめだなぁと思うことを列挙してみよう。

• _必ずExcelやWord文書の付録_みたいなものになる。文書を開くときに何となく厭な気分になる。(回避法はあるけれど。)
• 当然コードの_履歴管理をするのが大変_。(何が楽しくてVisual Source Safeを使わねばならないのか。頼むからCVSやSubversionを使わせてくださいな。)
• 正規表現が使えない。(がーん。 かなり不便。)
• 正規表現を差し引いてもテキスト処理がいまいち。(変形CVSなテキストを読むのがもう大変。)
• しょっちゅう関数の名前がだぶる。(名前空間をサポートしてくださいよ。僕のボキャブラリが寂しいだけ?)
• 使えるデータ型が_恐ろしいくらい貧弱_。(未だに基本な型と構造体と配列くらいしかなく、ハッシュやリストのような現代的な言語でサポートされているデータ型は_当然ない_。)
• クラスは作れるが、継承は出来ない。(勘違いしている人は多いけれど継承はOOPの必須事項ではない。)
• スレッドって何だっけ?
  という具合で、結構痛いところが満載なのである。そこまで使い込んでいるんだったらVisual Source Safeというか、OfficeのDeveloper Editionを買えばいいじゃんと言う意見もあろうが、僕はお仕事のためにわざわざOffice Developer版を買うほど酔狂な人間ではありません。 ちなみに家のPCにはOfficeをインストールしてません。家に帰って_Excelのアイコンを見るのも厭です_。ということで、会社で買ってくれないものを使う気にはならんのです。
  かといって、Windows Scriptの上で動く現代的なスクリプト言語であるActivePerlやActiveRubyは、_デフォルトでインストールされない_ということもあって、プログラムを使ってもらうという前提の開発では、管理が発生するためにメインの言語として選べない。(ExcelはどのPCでもバージョンは同じであることを前提に出来るが、PerlやRubyのバージョンなどの管理は職場で誰がするの?)
  ひょっとしたらVBA自身は、Office2003でVB.netのような言語の現代化が行われるのではないかと多少期待したのだけど、VBA自身はVBA 6.3から6.4にアップデートで余り変化はないみたい。(がっかり。 まぁ無論会社ではOffice2000までしか使ったら駄目ということになっているので、Office2003は使えないのだが。)
  という状況で、なんだか良い解法は無いなぁと思っていたのだが、先日のTCP/IP勉強会で、PostgreSQL方面の高橋さんより、「そういう話なら、.NETが良いよ。」という話を聞いたので、早速試すことにした。
  よく.NETのページを眺めていると、.NET Framework SDKには、コマンドライン版のC++とC#とVBのコンパイラが付属してくるのね！ てっきり、C#やVB.netで遊ぶにはVisual Studio .NETを買わねばならないのかと思っていたのであるが、僕が組むプログラムの規模ではVisual Studioには手を出さなくてよさそう。
  ダウンロード・インストールをしている間にWebをさまよえば、_フリーの統合環境は転がっている_もので、Javaの開発環境から進化して、C++やC#やPerlやRubyやXMLなどの編集が行えるJavaで書かれているEclipse(エクリプス)や、C#の開発環境に特化しつつVBの開発環境にも使えそうなC#で書かれているSharpDevelop(SharpDevelop-JP)といったオープンソースな環境が出回っているので、なんだか簡便な開発環境が整いそうである。
  今日はつらつら.NETのドキュメントとC#やVBのサンプルソースを眺めているわけだが、眺めているだけでも上記の問題は解決しそうである。例えば順に並べるとこんな感じ。
• ソースコードは_ただのテキストファイルになる_(当然)
• 当然コードの管理にCVSやSubversionを使える。
• Microsoft .NET Framework ではPerl5のような正規表現がサポートされている。
• テキスト処理はようわからんが、コンソールアプリを書けるからたぶん大丈夫でしょう。(調査中)
• 名前空間をサポートしている。(僕のボキャブラリが寂しくても_安心だ_。)
• コレクションクラスが_充実している_。(ハッシュもリストも_当然ありますよ_。)
• VBでも継承ができるようになった。(VB7からは継承が出来るようになりました。)
• スレッドを考慮したプログラムも当然書ける。
  という具合。ガベージコレクションもしてくれるのですか。メモリ管理関係も結構楽になるのかしら… しばらく眺めて勉強してみることにするが、MSと仲良く付き合うには、_過度の期待はしない_ことと_仕様はどうせすぐに変わるもの_と思って、_適当に勉強すること_と言うのが重用である。どうせ勉強しても長く持たないバッドノウハウだらけになるに決まっているのだから。
  今日の日記はリンクをいっぱい付けてみた。疲れたなぁ。

日帰り出張

今日は某社まで日帰り出張です。(アンカー打って良いのか?) つ、疲れた。

SICP

先日某MLで話題になった「計算機プログラムの構造と解釈」を仙台の書店で探索したのだが、ここ最近の仙台の書店で欲しいと思った本はすべて在庫として持っていないことが分かった。この本も見つけられなかったので、八重洲ブックセンタにて購入。(ここでも危うく見逃すところだった。) この本は巷で「Wizard Book」と呼ばれている有名な本である。
原書は「Structure and Interpretation of Computer Programs」で、本文はWebで読むことが出来る。非常にありがたい本なのである。原書のWebを読めば分かると思うが、僕の貧しい英語力でも文章の良さを理解できる非常に素晴らしい文章なので、出来れば原書を読むのが正しいと思う。この本を日本語で読めるという_気軽さ_も必要だと思うので訳書を購入。おそらく原書も買うことになると思う。
僕の経験では、国内の著者が書いた自然科学・工学の分野の日本語の教科書で_文章の良さを感じる_本を_読んだことがない_。僕の貧しい英語力で英文の素晴らしさを感じることが出来る教科書を見てしまって、思わず日米の教育水準の違いに愕然とせざる得ない。(ちなみに前回愕然としたのは「Feynman：Lectures on Physics」で、ちらちら読んだのはもう10年以上前の話だ。) こういうあたりに国語教育の問題点(物を書く教育をしないことや、読むことに関しては小説の偏重していることや、論理的な討論をする演習をしないことなど、他にもいっぱい)を見いだしてしまうのだが、そんなことを言っても僕の国語力もかなり怪しいので、こういうComfortableな文章を読みあさって日本語にフィードバックするしかないのですな。精進が必要ですな。
話がそれてしまったが、一言で言えば_この本は凄い本_である。(おおざっぱな意見すぎて失礼すぎるか。) 内容は難しいと思うが、こんなに面白いと思って読める本はなかなかない。SchemeなどのLISP系な言語は実際の仕事に直接役立つかと問われれば、おそらくすぐには役立たないと思う。ただ_役立つ/役立たないという思考軸だけが世の中の本質ではない_と思うのである。_読んで・手を動かしてソースを書いて楽しい・面白い_ということの方が遙かに重要だと思うのである。
ということで、しばらくこの「魔法使いの本」を読みつつ、魔法使いの弟子になってSchemeの呪文で遊ぶことになりそうである。もしCやC++やJavaやVBでしかプログラムを書いたことがないと寂しい経験しか持っていないと言う人には、_全く異なる物の考え方_をかいま見るためにもこの本を読んで、LISP系の言語をさわるべきなのかなとLISP万年初心者の僕も思うのだから、必読の書といえるのだろう。
帰りの新幹線でひたすら読む。1.1.4 Compound Proceduresあたりからだんだん深みに誘われてくる。とりあえず、帰りの新幹線で読んだ範囲で目から鱗だったのは、1.2.2 Tree RecursionのFibonacci数列の計算で、再帰を使った計算はFibonacci数列の漸化式から理解できるのだがこれは非常に効率が悪い。Fibonacci数列の計算を反復的なステップで計算するあたりでなるほどと思い、1.3 Formulating Abstractions with Higher-Order Proceduresで、Schemeの教科書を読んでいまいち想像が沸かなかった高階手続きといままでLISP系の本を読んでlambda記法のありがたみがいまいち分からなかったが、何となく見えてきたこと。理解するためにちゃんと手を動かさないと駄目だと思ったところ。とりあえず第1章だけでも読んで手を動かすところ満載なのである。

ようやく復帰か…

3日寝込んでようやく良くなった気がする。さすがに明日あたりから動かないとさすがに鈍ってしまう。とはいえ、明日1日会社に行くとまたまたお休みなんだねぇ。
それにしても、一人暮らしをしていて一番しんどいのはやっぱり風邪を引いた時だな。油断していると何食か食べ損なうからなぁ。まぁ気ままなSingle Lifeとの引き替えでなのではあるが。

100円で買える物

Newsweek 日本語版の今号の記事「竹中ショックが日本を救う」から。海外誌っておおむね竹中さんの評価がよいのよね。まぁ実体が伴えば僕も良いと思うんだけども。(その結果僕の会社が無くなってもね。)
話を元に戻そう。記事のなかで_「今の日本で100円で買える物」と言う話があったが、今の日本では100円でジュースも買えないんだよね。で、買うことができる物は、「ちょっとしたお菓子」と「大企業の1株」_と。これにはさすがに笑ってしまった。確かにそうだわ。(1株レベルでは買えないけど、価値はそんなもんよね。) うちの親会社の株価もだんだん100円に近づいてきたので、ちょっと考えるところではあるなぁ。と、しみじみ。

僕がJavaを積極的に使わない理由

今日はなんだか議論になってしまったので、一応日記にも書いておこうと思う。今の時点では僕はJavaを開発言語に使っても良いくらいの完成度になってきていると思っているので、以下の議論はだいぶんどうでも良くなっているのだが、何個かの理由があってまだJavaを開発用の言語に選択する気はありません。
僕はJavaに熱狂があった時代(Alpha版からBeta版の時代)を知っていて、そのあとに大きく失望したので使っていない訳だが、大ざっぱに言えば以下の項目に集約される。
仕様の策定がオープンでない
最近は解消された気はするが、仕様の策定がSunで行われていた頃は、信頼に足るコンパイラ供給ベンダがSunだけという感じだった。自分が使うツールの提供元がただの民間企業1社しかないというのは、あまりに脆弱だと思う。いまはThe Java Community Processである程度読みとれるし、コンパイラベンダも複数になったのでまぁいいかと思うのだが。
開発ツールの提供
当時JDKは、SolarisとWindows版しかなかった気がする。当時僕の主要な環境はLinuxだったので、採用すらできなかった。(BSDユーザーもMacユーザーも悔しかっただろう。)
国際化周りの対処の遅れ
JDK1.2でほぼ解決された問題と考えているが、やっぱ母国語が陽に使えないのは痛い。Unicodeをがんがん使うのは良いが、Unicodeを編集できるエディタが当時なかったこと、処理する対象は非Unicodeな文書で、Unicode周りの問題(正規化とか言うんだっけか)があってどうもねぇと思っている訳だ。
動作が遅い
これはJITコンパイラのおかげで解決を見たと言っていいだろう。(同じアルゴリズムでC++とほぼ同じくらいだから問題なかろう。)
僕は過去も今も「オープンソース」側の人なので、プログラムを書くのに最も重要なのは_「プログラムを書く自由」_だと思っている。僕はあくまで職業プログラマではないので、プログラムを書くことはこの上ない楽しみであり喜びであるべきなのだ。それゆえに上記の用件で最も大切だと思っているのは、言語仕様のオープン性とコンパイラの提供が永続的であることである。その条件を満たせない限り、使ってみようとなかなか思い立てないのである。
ただ今となっては時代遅れな意見も散見している気もするので、ぼちぼちJavaを個人的なプログラムの開発に使えるよう準備を整えて良いかと思っている。なにせXML周りはJavaがないと立ちゆかなくなってきているので切実なところであろうか。僕の中のJavaの不運は、_必要な物が必要な時に提供されなかったこと_につきる。(それで仕事する気が失せるんだもの。) 逆にLinuxは使いたい時に使える形で登場したのね。(こっちもかなり偶然性が強い。) まぁ時の運とはこういう物だろうな。
僕のなかでJavaの残りの問題は、C++におけるtemplateがないことくらい。これはJava GenericsがJDK1.5で実現すれば解決される。僕自身はライブラリ設計者ではないので、Genericな型を持つclassを設計することはないのだが、Collection classを使っていると、Collectionから要素を取り出すのに_型キャストが必要_と言うことと、_意図しない型の要素を追加できること_が気になるわけだ。Java Genericにはそれなりの期待をしている訳だ。
議論については、幾ばくかつきあうので、僕にJavaを使わせたい人は建設的なご意見をください。

woodyインストール その2

機能の話題の続き。うちのVAIO C1VR/BP(PCG-C1VR/BP)にDebian GNU/Linux 3.0(woody)をインストール。結局、Linux User 2002年9月号に付属のCDROMで再インストールする事にした。最近自宅のネットワークの調子がいまいち良くないので、apt-getするのがめんどくさかったわけだ。
使用したフレーバーはbf24、CDROMブートパラメータは ide1=0x180,0x386とすれば、付属のCD-ROMドライブでブートしてインストール可能である。あとは出て来るメッセージの通りにインストールであるから簡単だ。ただなまぐさついでにtask-selにて以下のタスクを実行した。