Matzにっき

_ [生活]自宅作業

疲れがたまっていたのと、肋骨が痛いので、自宅で作業。

Rubyのバグをいくつか直した。

_ [OSS]Young Programmer, Stop Advocating Free Software!

村田さんからのタレコミによる。

「なんでもかんでもFree Softwareであるべきだ」という若いプログラマよ、 考え直せ。実社会に出てプログラミングで生活しようと思えば、 Free Softwareじゃ食べていけないぞ。フリーソフトウェアを推し進めるべきでない。

とかいうような内容のオープンレターがslashdotにポストされた。 年よりのたわごとと断言したいところだが、どうも このレターを書いた本人より私は年寄りらしい。どうしたものか。

まあ、「フリー(この場合は無償)」では食べていけないというのは、よくある指摘である。 実際、ありとあらゆるソフトウェア関連のプロダクトおよびサービスが代価なく配布されると、 産業として成立しないのは事実でもある。

しかし、ソフトウェアの性質である

• コピーが安価
• コピーによって劣化しない
• コピーの配布が安価

によって、ソフトウェアのコモディティ化は避けることはできないだろう。 フリーソフトウェアでなくても、ソフトウェアそのものを販売するビジネスは そう遠くない将来に、ごく一部の例外を除いて成立しなくなると思う。 そうなったら、このレターを書いた人はソフトウェア産業の保護を訴えるのだろう。

もちろん、訴える権利はある。が、実際に保護されるだろうか。 むしろ、ラッダイト*1運動のようになってしまうのではないだろうか。産業革命に取り残される運命の人々が不安を感じて人たちが騒いだのはある意味当然だ。 しかし、その運動は産業革命そのものを止めることはできなかった。 100年以上たった今、産業革命は定着し、ラッダイト運動は存在しない。

ソフトウェアのコモディティ化はソフトウェア産業の構造変化だと思う。 「ソフトウェアの自由」提唱者はそれに便乗して、さらに先に行こうとしている。 プログラミングラッダイトはそれを止めることができるか。

本棚から古い『GNU Emacsマニュアル』取り出し、その中の『GNUマニフェスト』を読んでみると、 このオープンレターを書いた人物がまだまだ子供であった頃に、 彼のレターに対する答えがすでに与えられていることがわかる。

「プログラマは飢え死にしてしまわないだろうか」

誰も強制的にプログラマにさせられるということはないとお答えしておきましょう。 我々の大部分は道の上に立ってしかめ面をしてそのまま飢え死にせよといいわたされることもありません。 我々は何か他のことをするでしょう

しかしこれは質問者の暗黙の仮定を受け入れてしまっている点、誤った答えです。 つまりソフトウェアの所有権がなければ、プログラマは一銭たりとも稼げないという仮定です。 おそらくそれはオール・オア・ナッシングという仮定でしょう。

プログラマが飢え死にしない本当の理由は、プログラム作業に対してお金が支払われることが可能だからです。 ただし、今ほどは儲からないだけです。

コピーを制限することだけがソフトウェアにおけるビジネスの基礎ではありません。 それが最も多くのお金をもたらすので、最も共通した基礎になっているだけです。 もしも顧客の方からそれが禁止されたり、拒絶されたりした場合には、ソフトウェア・ビジネスは、 今のところほとんどなされていないような他の組織的な方法を基盤として変遷していくでしょう。 どんなビジネスでもそれを組織化するのにはいく通りもの方法があるものです。

おそらく新しい基盤のもとではプログラミングは現在と同じほどは儲からないでしょう。 しかしそれだからといって新しい変化に反対する理由にはなりません。 セールスマンがいまと同じだけの収入を今後常に保証してもらえないことが不公平だとはいえません。 プログラマも同様で、収入が減じてもそれはやはり不公平だとはいえないでしょう。 (実際には、プログラマはそれ以上の稼ぎがあるに違いありません。)

このマニフェストが出されたのはおそらく1987年ごろだと思うのだが、 そのころStallmanはこれからの社会のあり方について十分考察していたことがうかがえる。 さらにマニフェストの後半に登場するビジョンには感動さえ覚える。

長い目で見れば、プログラムを無料にすることは、欠乏の終わった世界への第一歩です。 そこでは生計を立てるためにあくせく働かなくてはならない人はいなくなります。 人々は(週10時間の化せられた仕事、たとえば法律の制定、家族のカウンセリング、ロボットの修理、 小惑星の探査といった作業をこなしたあとは)プログラミングのような面白い活動に自由に熱中することができます。プログラミングによって生計を立てることはもはや必要ではありません。

StallmanはSFじゃなく、本気でこういう世界が来ると考えているのだ。 もちろんこれはまだ実現していないが、この先人類が滅亡しなければ、 100年後にはこれに近い世界が来るかもしれない。

Stallmanは100年先を見ていた。 「無償じゃ生活できない、これが現実だ」と文句を言う人はどこまで先を見通しているのだろう。 Stallmanと比べてしまうとすごく近視眼的な気がする。

そういう観点では、CNETの「オープンソースの採用で共食い状態？--ソフトウェア企業のジレンマを探る」という記事で紹介された、 IBMソフトウェアの技術戦略ディレクターDoug Heintzman氏の言葉の方が現実を見ている(ような気がする)。

たしかにリスクはある。しかし率直にいって、上り調子のものをしゃかりきにつぶそうとするのはエネルギーの無駄だ。誰も市場には勝てない

最初に戻ろう。若きプログラマはフリーソフトウェアを推し進めるべきか。

推し進めるべきだ、と私は思う。なぜか。

もし、私の予想通り、フリーソフトウェアが未来であれば、それ以外の道は衰退の道だ。 抵抗するものはラッダイトだ。 今フリーソフトウェアを選ぶことは新しい世界で人よりも先んじることができる。

もし、私の予想が間違っていて、フリーソフトウェアが未来でなければ、 いつでもフリーでない世界に帰ることができる。 その時、フリーソフトウェアのソースコードとコミュニティから学んだ知識と経験は絶対に役に立つ。

たとえ私が間違っていても、未来がどうであっても、けっして損はない。

_ [OSS]Open Source History

OSDNの佐渡さんからオープンソースの歴史と経緯についてメールをいただきました。 許可をいただきましたので掲載します。

お疲れ様です。ふと日記を見ると、私の名前が出てたので歴史ぐらいは簡単にまとめておきます。

オライリーのオープンソース本(1997年と誤記されている箇所あり)を 読めばだいたいのことは分かるのですが、オープンソースという言葉は 1998年2月3日に初めて生まれたというのが通説です。(ESRあたりが 実はその数週間以前にOpen Sourceという言葉自体も案として持っていた 可能性を捨てきれないと考え通説と言ってます。公にはなってませんが ペレンスあたりと情報交換はひんぱんにしていたらしいですし。)

経緯的には、アンチビジネス的なイメージに悩まされていたVAリサーチ(当時) がそれを払拭する手段を求めていたという背景が大きいのですが、直接きっかけと なったのは Netscapeのソース公開のニュースです。1998年1月22日にNetscape のソース公開計画が公表されましたは、そのNetscapeの行動を成功 に導いてフリーソフトウェア自身も成功に導きたいESRとフリーソフトウェア のイメージに悩まされていたVAリサーチのLarry Augustinらの思惑が がっちり合って、2月3日のVAリサーチでの会合で「Open Sourceという名称」と 「DFSGをその定義」として使ってフリーソフトウェアのキャンペーンしていこ うという流れになったわけです。この会合に出席していたのは、 Larry Augustin、ESR、John "maddog" Hall(USENIXの重鎮、Linux Internatinalの会長で既にVAにjoinしてたかも)、Sam Ockmanらですが、 その後ESRがVAのboardになってますので、出席者の多くがVAのメンバーと いうような会合だったのではないかと思います。 <URL:http://www.oreilly.co.jp/BOOK/osp/OpenSource_Web_Version/introduction/introduction.html> これを書いているのも当時のVAリサーチ社員だったりします。

で、ここまでは密室でしたが、ESRがこの会合終了後からOpen Source を成功に導くべく動きだし、2月4日にLinus の指示を獲得、1週間以内に www.opensource.org立ち上げ、DFSGをOSDとして書き直し、SPI Inc. (Debianの商標等を管理している組織)を通じてOpen Sourceの商標申請 までが行われたと思います。この動きがほぼ今のOSIを形成するものと なっていますが、この時にweb、osd、TMの作業を行ったのがペレンスです。 US Patent Officeで確認したところ、"OPEN SOURCE"の申請は98年2月24日に 受理されています。

その後は <URL:http://wp.netscape.com/newsref/pr/newsrelease577.html?cp=nws02flh1> 2月23日のNetscapeのリリースでおそらく世界初のOpen Sourceという 単語を使ったリリースが出ます。ここではアカラサマにOpen Sourceという 言葉を使用しています。

ですが、まだこの時点では主要なハッカー連中の支持があったわけでは ありません。しばらくはESRとペレンスあたりがOpen Sourceの 支持獲得に動き、4月7日にTim O'Reillyが一働きして、主要な開発者 を一ヶ所に集め、free softwareにかわる名称について議論を行い、そこで 投票によってOpen Sourceを今後使うことが採択されました。RMSはここでは 出席しなかったと思いますが、その当時はOpen Sourceという名称については 静観するというスタンスでした。出席者等詳しいことは <URL:http://www.linuxgazette.com/issue28/raymond.html> に書いてあります。ここでのポイントは、

Larry Wall (Perl), John Ousterhout (Tcl) and Guido Van Rossum (Python). Eric Allman (Sendmail) and Paul Vixie (BIND/DNS) were present, representing their own projects and the BSD community. Phil Zimmerman, the author of PGP, was there too, as was John Gilmore, a co-founder of Cygnus and the Electronic Frontier Foundation. Brian Behlendorf spoke for the maintainers of Apache. Jamie Zawinski and Tom Paquin represented Netscape and mozilla.org.

という出席者で投票でOpen Sourceを使うと決めたことでしょう。これ以降 は多少のゴタゴタもあったりしますが、Open Sourceという言葉自体は すんなりと浸透していくことになります。日本でも夏頃にはチラホラと 使われるようになり、98年の年末ぐらいには少なくともLinux界隈では 普通の言葉になってたかなぁと思います。

で、OSDについては経緯的に2月3日にはDFSGを使うと決めていたわけで 最初からセットです。4月7日の投票時に、GPL, Artistic, BSD, MPL, Python を使う開発者がそれに御墨付をつけるという行動にでたのも、Open Source にとっては非常に結果をもたらしたのでしょう。

また、Open Sourceという単語はNetscapeやVAといった企業のマーケティング 的な目的も含んでいましたが、その運動を作りだし、実行したのは同じフリー なソフトウェアに関わるコミュニティです。この点からも単なる一企業の エゴで作られたものではないことは分かります。

それから、<URL:http://sourceforge.jp/projects/faif/document/ch11_txt/ja/>も参考になる、 とのことです。 こちらを読むと、ESRらが1996年ごろまでバザールモデルを意識していなかったということが分かります。 ある意味、驚異的ではあるのですが。

_ [会社]打ち合わせ

本年度のIPA「オープンソースソフトウェア活用基盤整備事業」への応募について打ち合わせる。今年はちゃんと「オープンソースソフトウェア」なのね。 去年は「オープンソフトウェア」という謎の造語だったのに。

で、いくつか候補が上がる。最終的には二つにまとめる。 今後、詳細化が必要になる。

_ [Ruby]バグ

面倒なバグが発見される。Procの中からbreakやreturnが実行されたとき、 ジャンプ先が存在しないケースがあるので、その場合にはLocalJumpError例外が発生する。 その例外の発生条件がbreakとreturnで異なっていることに気がついていなかった。

つまり、

def foo1
  Proc.new{break}.call
end

def foo2
  Proc.new{return}.call
end

とあるとき、foo1の方はbreakのジャンプ先であるProc.newの呼び出しが完全に終了しているため、 飛び先が存在しないのでLocalJumpErrorが発生する。しかし、foo2の方はreturnの飛び先である foo2(の終端)がまだ存在しているため、そのままreturnすれば良い。

で、長い時間かかってなんとなくうまく動いているところまで持っていったのだが、 まだよくわからないコードが残っている。リファクタリングしないとな。

_ [METI]第3回高度IT人材早期発掘のあり方検討会

東京に移動。内容を具体的に書くのはまずいような気がするので、 印象とキーワードだけ。必要に応じて妄想してください。

結局事務局の努力により、無難な線にまとまりそう。

プログラミングコンテスト、プロコン、検索にかからない、 自前サイトの必要性、 プレゼンスの改善、インセンティブ、結果のフィードバック、 ノウハウの蓄積ができるように、 プログラム実行を作品として見るか、ソースコードそのものを見るか、 ソースコードレビュー、公開するかどうか、 一点突破主義を認めたい、自己申告制。

セキュリティキャンプ、セキュリティ甲子園への道、 合宿、講義、雑談、学習、次年度のチューター。

_ [家族]保育園お楽しみ会

朝の第一便で東京から戻る。伊丹に降りるかもと脅されたが、 結局無難に出雲に帰れた。そのまま息子の保育園へ。

保育園の出し物はなんか緊張感がないというか、力が抜けているというかなんというか。 まあ、そこがいいんだろうな。のんびりと眺めていた。息子は緊張しやすいたちなのか、 堅い顔をしていたのだが、なんとか自分の役割をこなせたようだ。

_ [テレビ]鋼の錬金術師

なんか先週あたりから急激に話が進んでいるような。

それに原作とかなり乖離してきている(6巻までしか読んでないけど)。 なんとなくアニメの方ができが良いような。

スピード感はあるし、順番を並べ替えつつもストーリーが破綻していない。

_ [家族]全員集合

教会終了後、実家に。はじめて一族全員が集合する。

両親、私の家族、妹たちの家族、弟家族、それと先日帰還したばかりの下の弟、 総勢１９名。いつのまにこんなに増えたんだ。

なごやかに話をしたり、食事をしたり。良い時間を過ごした。 次に全員が集まるのはいつになるだろうか。 両親が帰還する1年半後か。

_ [会社]検収

朝からIPAオープンソフトウェア活用基盤整備事業、 「クロスプラットホーム性を持つ帳票開発ツールの開発」の検収。

今回はトラブルもなく、お昼には完了。 こんなに手間のかからないところばかりだとありがたいとのお言葉をもらった。

次年度も、ものにしたいものだ。

_ [Ruby]breakとreturnのバグ

先日も悩んでいたバグだが、予想以上に厄介だ。

問題点は、breakとreturnで飛び先が違うので(breakはブロック付きメソッドの継続、returnはブロックを囲むメソッドの継続)、有効範囲も違うのだが、 今までは(1.8では)returnの有効範囲しかチェックしていなかったので、 まれにbreakで正しくないところにジャンプする可能性があることだ。

で、考え出すといろいろなところが絡み合って面倒なことになる。 こちらを直すと別のところが動かなくなったり。 しょうがないので、デバッガで追いかけ、 動作を理解し、紙の上にメモを書きながら、Rubyのあるべき挙動を洗い出す。

で、洗い出した挙動からテストケースを作り、失敗するケースを またデバッガで追いかけ、コードを直して試してみる。 試した結果から「あるべき挙動」の間違いが見つかったりもする。

ああ、面倒な。

こういう時、無闇に複雑なRubyの実装を恨んだりする。 自分で書いたものだけど。優秀なプログラマならこんなに試行錯誤しなくても、 ばしっと解法を見つけたりするのだろうなあ。

しかし、一方で「言語のあるべき姿」を考えるのは、 私にとって最高の楽しみであったりする。 そっちばっかりやって実装に手を抜いているから、 今のRubyがある(良い意味でも悪い意味でも)と言えよう。

バグの完全退治にはもうちょっとかかりそう。

_ [言語]AIR

「スクリプト言語ＡＩＲ」だそうだ。

スクリプト言語ＡＩＲは、新しく簡潔で自然なスクリプト言語です。

ここで「自然」という意味は、日本語や英語といった人間の話す自然言語に似 た構文をもつことを意味するものではありません。

日頃からコンピュータのプログラミングやシステム管理等を行っている人々

− 特にＵＮＩＸやＣ言語に日頃から親しんでいる人々 −

に違和感を感じさせないと言う意味の自然です。

と紹介されている。特徴は

ＡＩＲのソフトウェアとしての特徴を幾つか上げてみますと、

• オープンソースであること。（ＧＰＬ）
• スクリプト言語であること。
• 開発者が日本人であること。

等があげられます。

一方で、スクリプト言語としての特徴は、

• 構文がシンプルで直観的なスクリプト言語であること。
• 各種ＵＮＩＸツールやＣ言語の考え方を、そのまま素直に発展させていること。
• 実行速度が速いこと。

等があげられます。

だそうだ。ここのところ毎日のようにリリースされている。

言語仕様を見てみると、パターンマッチなしのAWKみたい。 あまり冒険はしていないように思える。 それが良いのか悪いのかは分からないけれども。 言語の良さは「生き残ることができるか」で決まる部分が多いので、 長い目で見守っていきたい。

_ [会社]オープンソースソフトウェア活用基盤整備事業

久々に松江で見かけたおごちゃんを交えて、来年度応募への作戦会議。

片方はうちで以前開発した視覚障害者用インタフェースL-Voiceを完全ソフトウェア化しようという提案だったのだが (現在は音声合成にハードウェアを利用している)、サーベイの結果いつの間にか すでにGalatea Talkという オープンソースで立派な音声合成エンジンができていたので(これもIPA支援だ)、 こちらはボツ。L-Voiceの完全オープンソースソフトウェア化というのも、 それはそれで価値がある仕事ではあると思うが、今回の公募趣旨には沿わないと思う。 お金のつじつまが合えばぜひ開発したいものだ。

もう一つの方についてはそのまま進めることとする。 若干適用範囲が狭い気もするが、それを広くするための開発です、という言うことにしよう。

後は雑談。プログラマの世代間断絶とか、SEという呼称は要らないとか。

_ [Ruby]バグ退治

昨日のバグはやっと退治できた。 ああ、面倒だった。気がついてから直すまで1週間近くかかったんじゃないか。

で、こういう思いをするたびにインタプリタを書き直そうと思うのだが、 Rubyくらい複雑な言語のインタプリタをゼロから書き直すほど集中力が持続しないのだよ。 これが年をとったということか。もしや若い者にが〜っと作り直してもらって、 それをちまちまいじるのが精一杯ということか。情けない。

_ [原稿] Linux Magazine

時間があるぞ、と思っていると、もう次の〆切が来てしまう。 月刊とはかくのごとくつらいものなのだが、これで週刊連載とかどんなものなんだろう。 想像もできない。

今月は(今月も)いろいろ重なってて公私ともに忙しく、少々パニック気味。

今月は「RubyとEmacs」。ruby-mode.elとかRRBとかを解説するんじゃないだろうか。 ただ、内容については書き終わってみるまで油断できない。 〆切直前にテーマを変更したことは何度もある。 よく乗り切れたものだ。

_ [Ruby] Ruby2 Random Thoughts (1)

Ruby2、こんなのはどうだろうか、のコーナー、パート1。

1.8からはメソッド本体の中でメソッドを定義できるようになった。 メソッドはそのメソッドを囲むクラスに定義される。 あんまり使い道はないのだが、禁止する必要まではあるまいとの理由だ。

が、これを外側のメソッドのselfの特異メソッドの定義としたらどうだろう。 現状よりは少々使えるものになるのではないだろうか。 また、2重定義の効率を上げれば、 (名前の重複がなければ)一種のローカル関数としても使えるような気がする。

実装はそんなに難しくない。 互換性についても、 1.6以前ではそもそも使えなかったのだから、まだ利用者も少ないと思うし。

_ [生活]確定申告

ようやっと済ませた。また〆切ぎりぎりだ。

手順は簡単。まず昨年分の支払調書を集めて金額を計算しておく。 それから、昨年集めた領収書のうち、経費分を合計しておく。

後は源泉徴収票、支払調書を持って 確定申告会場に行き、係の人に相談すれば終わり。 PCで申告用紙に入力後、印刷までしてもらえる。 私の場合には玉湯町中央公民館が会場だ。 待っている人もおらず、15分程度で完了。らくちん。

_ [本]Hacker and Painters

Paul Grahamからメールが来た。「今度O'Reillyから論文をまとめた本を出すので、 "Blurb"を書いてもらえないか」だそうだ。"Blurb"ってなんだろうと思ったら、

Blurbs are those quotes where people say "this is a good book."

なんだそうだ。

そういえば、海外の本の裏表紙にはたいてい「この本は素晴らしい」とかほめる言葉が載っているっけ。 私はPaul Grahamの論文のファンだし、彼の主張の多くには大変共感している。 大変名誉な事なので引き受けようと思うのだが、身に余る気がしないでもない。 ちなみにforewordはEric Raymond。

載る論文のリストは以下の通り。

• Hackers and Painters
• Taste for Makers
• What You Can't Say
• Why Nerds are Unpopular
• The Other Road Ahhead
• Ho to Make Wealth
• Mind the Gap
• A Plan for Spam
• The Hundred-Year Language
• Beating the Averages
• Revenge of the Nerds
• Succinctness is Power
• Why Arc Isn't Especially Object-Oriented
• The Roots of Lisp
• The Dream Language
• Design and Research

私の好きなのは、「The Hundred-Year Language」と「Succinctness is Power」。 「The Dream Language」って読んだことないな、と思ってたら 「Being Popular」の改題のようだ。

これらのほとんどにはShiroさんによる訳ができているので、 オライリー・ジャパンからも出版するのはどうだろうか。

_ [教会]ステーク大会

春のステーク大会、土曜の部のために新見まで。 玉造から新見まで2時間強。

今回は割り当てもあるので緊張する。 が、なんとかこなせたようだ。

_ 難読名字

新見までの道で珍しい名字の酒屋(諸遊酒店)を見かけた。 高校時代の同級生にいたが、他では見かけたことがない。 そういえば学生時代には珍しい名字の同級生が何人もいたなあ。

以前、難読地名について書いたが、 地域特有の名字もいろいろありそうだ。

たとえば、松江で一番多い名字は「野津」である。 こんなに偏っているケースは珍しいかも。

私のいる玉造では「新宮」とか「福間」が多い。

私の同級生の中で珍しそうな名字は以下の通り。

• 諸遊
• 五明田
• 兵頭
• 三藤
• 大丸
• 峠田

解答は例によってまた今度。

_ [教会]ステーク大会

日曜の部。今度は子供たちを連れて。やはり2時間強。

ついたらお昼。私の両親、妹夫婦、弟夫婦、弟も交えてお弁当。 1時から集会。副ステーク会長が解任された。転勤だそうだ。 新しい副ステーク会長はちょっと意外な人。

その他、いろんな人の話。長い時間であったが子供たちはわりとおとなしくしていてくれた。

帰り。流れが良くて2時間以内に帰れた。 が、すっかり疲れて眠り込んでしまう。さすがに2往復はつらいな。

_ [原稿]Linux Magazine

このエントリは本当は今日のぶん。

日付を間違えたのだが、すでにリンクを張っている人もいるし、 このままにしておく。

ちゃんと毎日書かないから日付を間違えるんだ。反省。

_ [原稿]Linux Magazine

月例の〆切。今月は「EmacsとRuby」。 Emacs使いがruby-modeとRRBについて熱く語る、 といった内容。

RRBは今まで使ったことなかったけど、結構便利。 C用のRefactoring Browserも欲しいなあ。もうあるのかな。

追記:

このエントリは本当は15日のもの。

_ [原稿]Linux Magazine

本来の〆切は15日であったが、プライベートで忙しく、 一日延ばしてもらった。こんなことは滅多にないのだが。

分量が少し多くて、Emacsの歴史に関するうんちくを少し削る。

_ [テレビ]『め組の大悟』

最終回。なんかあっと言う間に終わったな。

全体を通しての感想を。

• 大悟がスーパーマンじゃない。

  全編を通じて、大悟は割と普通の人だった。せいぜい普通よりちょっと勘が働く程度。 神田隊長は「炎の中に突っ込んでいけるバカ」と評していたが、 その根拠になる描写はなかったような。 原作の大悟君はたびたび周りの人を驚愕させるのだが、そんなことはほとんどなかった。

• 甘粕くんの性格が違う

  大悟の「永遠のライバル」甘粕士郎くんだが、 原作では冷静沈着タイプ(でも大悟に引きずられちゃう)なのに、 ドラマでは大悟とおんなじ直情型。

• 火事場が少ない

  予算の関係かしら。放火とか、催涙スプレーとか、資材の崩落とか、 火事でないエピソードが多かったように思う。過去の火事のテープを聞くってのもあったな。 あ、でも、今思い返すと、高校も、おじいさんのうちも、廃工場も燃やしてるから、 少ないとまでは言えないかな。

• 女性消防士を扱うエピソード

  原作では「マザーコンピュータ」(忍足さんだっけ)でちょっとだけ触れられていた 女性消防員の一件が まひるちゃんという機関員を通じてひとつのエピソードになっていた。 脚本家が女性であることと関係があるのか。

• 死人が出た

  原作では要救助者、同僚ともに誰も死なない。それが大悟のパワーなのだが、 ドラマでは同僚がフラッシュオーバーに巻き込まれて死んでしまう。

総括するとドラマとしては破綻せずまあまあのできのような。 原作のパワーを再現するのは無理だろうしな。

_ [会社]打ち合わせ

例のIPAの件の打ち合わせ。応募資料などについて話し合う。

こういうのを見るたびに、エンジニアに必要な能力は国語力だと思う。

_ 難読名字(解答編)

難読っていうか、単に珍しいだけってのも含まれていたな。

• 野津(のつ)
• 新宮(しんぐう)
• 福間(ふくま)
• 諸遊(もろゆう)
• 五明田(ごみょうだ)
• 兵頭(ひょうす)
• 三藤(さんとう)
• 大丸(だいまる)
• 峠田(たわだ)

世の中にはいくらでも珍しい名字はあるものですが。

_ [Ruby]でばっぐ

しばらく忙しくてRubyをいじってなかったが、今日はちょっと作業できた。

やったこと。

• object.c (Init_Object): remove Kernel#to_a.

  使うと警告が出ていたObject#to_aを削った。

• eval.c: remove specialized version of rb_Array(). use simple one defined in object.c.

  Object#to_aを特別扱いしていたrb_Array()の定義を削って、 object.cにあるすなおな定義(ifdef outされていた)を使うようにした。

• enum.c (enum_zip): use "to_a" instead of "to_ary".

  引数を配列に変換する時、to_aを使うようにした。

• eval.c (proc_eq): avoid false positive by using scope and dyna_vars. no longer use frame.uniq.

  空Procが違う場所なのに==が真になるケースがあった。チェック条件をより正しく。

• eval.c (proc_arity): arity is now defined as number of parameters that would not be ignored. i.e. Proc.new{}.arity returns zero. update test suites too.

  arityというのは「渡してもエラーにならない引数の数」のつもりだったのだが、 「無視されない(パラメータとして受けとった)引数の数」ということにした。 これにより Proc.new{}.arity は -1 でなく 0 になる。

これでRuby2に一歩(半歩)だけ近づいたな。

_ [Ruby]GC

以前考えていたGCアルゴリズムだが、 ブロックを生成するとローカル変数から参照されているオブジェクト全部に参照マークが付いて 効率が上がらないことが判明していた。 が、リターン時にlazyにマークをつければ効率はそんなに下がらない(はず)。 いかんせん思いついたのが遅すぎた。発表申し込みの〆切は明日だ。

今回はあきらめるしかないか。

_ [Ruby]クラス変数

1.9ブランチで以前から宣言していた「クラス変数のプライベート化」をコミットした。

これで「ぎゃっ」という人はそれなりにいそうだ。 実際、drbのtestは修正の必要があったし。

今後は、クラス変数は外からは(サブクラスからも)見えないことに注意していただきたい。

_ Yaboo BB

勧誘の電話が来た。玉造でもYahooBBのサービスが始まったということだ。 いや、近所のスーパーでも赤いジャケットを着た人が待ち伏せしてたので、とっくに知ってたけど。 実は数日前にも電話があったのだが、その人は「Linux使ってます」と言った時点で退散したのだった。 根性なし。

別に個人情報がどうこうということはないので(苦笑)、 今日は話を聞いてみることにした。

せっかくなのでいろいろ聞いてみたが、 ちょっとツッコんだ話になると、すぐに分からない、とあきらめてしまうので面白くない。 技術担当という人に代わってもらったのだが、 その人も「サブネットの構成は？」とか聞いたら、やっぱり分かんないみたい。

クレーマーみたいだな。いじわるすぎたか？

_ Jolt Award

今年はDave ThomasとAndy Huntの『Pragmatic Starter Kit』がJolt AwardのBooks sectionでProductivity Awardを受賞したそうだ。

おめでとう。日本語版は...出ないかなあ。

Daveは来年はPickaxe IIで取るとか言ってるぞ。

_ [Ruby]ハッシュ新形式

Ruby2にいたる文法変更の一環。

{foo: 1, bar: 1}

のような式を許すようにした。その意味は

{:foo => 1, :bar => 1}

ChangeLogには私の名前でエントリしてあるが、実際には中田さんのコード。

それと、これはまだ実現できないけど、

method(a=>b, c=>d)

のような、「末尾の引数にハッシュを直接書ける」文法は今後使わないようにしてほしい。

これの意味を

method({a=>b, c=>d})

から

method(**{a=>b, c=>d})

に変更して、将来の名前付き引数に使うつもりなので。

追記:

警告した方が良いというakrさんのツッコミ。

確かにその通り。もうちょっと考えが煮詰まったらちゃんとコードでもアナウンスします。

_ [テレビ]『鋼の錬金術師』

だんだん原作から離れていく。いいのかっ。 下手すると原作より(私にとって)面白いという怪作になるかも。 あ、原作も好きだけど。

_ [家族]反抗期

長女はそろそろ思春期と呼んでもよい年ごろなので、最近反抗したがる。 私自身は第二次反抗期がなかったので(そう、本当になかった)、 なかなか理解してあげられない。

今日も「教会に行きたくない」ということなので、1時間ほど話を聞いた。 いろいろつもりつもった感情のいろいろがあったらしい。 話したいだけ話させて、いろいろ聞いた後、 いくつかお互いに改善の約束をした。 今日は岡山に行くはずで行けなかったのだが、かえって良かったというものだ。

私にとっても学ぶことが多かった。

• 子供にとっては論理は関係ない。感情重要、って話は別の文脈で聞いたような気がするな。
• 子供の成長のためと思っていろいろ注意しても、その内容は覚えてない。 覚えてるのは、どんな気持ちでそれを聞いたか、だけ。
• 子供も一個の人格なので、公正な態度で接するべき。対等ではないけどな。

あれだけぐずぐず言っていた長女も、お昼ごろにはけろっとしていた。 根は素直ないい子なんだよな。うん、うん(親馬鹿か)。

_ 弱点

聖文にこんな言葉がある。私の好きな言葉だ。

ここでの「わたし」は主、つまり神さまである。

人間には弱点がたくさんある。その弱点が長所になるというのだ。なんと希望のある言葉だろう。 小さい時からこの言葉の希望が好きだった。 でも、自分の弱点がどうやって長所になるんだろうと、疑問に思っていたのも事実だ。

だいぶん歳をとった今ならちょっとは分かる気がする。

私は子供のときから数学が苦手だった。あらゆる科目の中で数学だけ飛び抜けて悪いのだ。 あと、物理や化学も成績はそんなによくなかった。数式の扱いが下手だから。

今思えば、私にはある程度以上複雑なものを扱う能力が欠けているのだと思う。 小学生レベルの単純な算数ならなんとかなるが、数学のレベルが上がって、 ある程度の複雑さを備え、応用力が要求されると、ある閾値を越えて、理解できなくなってしまうのだ。

これは今でも私の弱点である。

しかし、言語設計者としてはこの弱点は長所として働く(ような気がする)。 つまり、私のような弱点がない人は複雑さを恐れない。 彼には理解できてしまうから。 しかし、私は理解力に人より低い限界があり、それを自覚しているので、 Rubyの複雑さは(確かにRubyは複雑な言語だが)、 ある一定のレベルで収まっていて、 それがこの言語の魅力につながっているのではないかと思うのだ。

以前、Dave Thomasの「なぜRubyが設計できたのか」という質問に、 当時は「なぜ他の人が似たようなものを作らないのかが分からない」と答えたが、 今なら「私の弱点が功を奏したから」と答えるかな。

昔から数学について劣等感を感じていたのだが、最近はそうでもなくなった。 今でも数学に強い人には憧れるけど。

ひとつ、確信していることがある。 Damian Conwayには私の弱点はないだろうということ。 そしておそらくはLarry Wallにも。それがPerl6にとって良いことかどうかは知らないが。

_ ご近所を探せ

「■大河原克行の「パソコン業界、東奔西走」■ これが国内最大のPC一貫生産拠点・島根富士通だ」

この工場はうちから車で40分ほどのところにある。ご近所で頑張っている様子を見るのは誇らしい。 応援したいものだ。実は富士通のマシンを買ったことはないんだけど。 LOOX Sが継続してたり、LOOX Tのポインティングデバイスがパッドでなければ候補なんだがなあ。

しかし、モノを作るところは苦労と工夫を継続している。 それに比べてソフトウェア業界はなあ。まだまだできることはありそうだ。

_ [本]4887187491

会社の人から借りてくる。なかなか面白い内容だ。 「セキュリティ甲子園」というキーワードのみから、ここまで書ける創造(想像)力には頭が下がる。

が、実際問題、こんな問題出した日には付いてこれる高校生はいないだろうなあ。 実施側にはいろいろと悩みがあるのだ。そんなことを思いつつ、東京へ移動して、 「高度IT人材早期発掘のあり方検討会」へ。

_ [METI]高度IT人材早期発掘のあり方検討会

本年度、最終回。当初あれだけ発散した内容を、ある程度のところまで落ちをつけてしまう、 官僚とシンクタンクのパワーを見た気がする。

基本的には「プログラミングコンテスト」と「セキュリティキャンプ」の二本立て。 セキュリティキャンプはかなり面白い企画。私も聴講したいなあ。

_ [本]Blurb for "Hackers and Painters"

昨日(22日)が〆切だったが、時差の関係でこちらは今日でも大丈夫。

実はすっかり忘れてて、ホテルであわてて書き出した。 こんな感じ。

Since programmers create programs out of nothing, imagination is our only limitation. Thus, in the world of programming, the hero is the one who has great vision. Paul Graham is one of our contemporary heros. He has the ability to embrace the vision, and to express it plainly.

His works are my favorites, especially ones describe language design. He explain the secret behind languages, programming, and human nature, which can only be learned from hacker experience. This collection of his papers show you his great vision, and tell you the truth about the nature of hacking.

Happy Hacking.

0596006624(日本版については聞いていません)。

追記:

shiroさんから「どこに出したら良いのかしらん」というコメントをいただいたので、 個人的に知り合いのオライリージャパンスタッフのアドレスを伝えておきました。

_ [会社]打ち合わせ

会社で打ち合わせ。人こそがうちの会社の最大の財産だなあ、と強く感じる。

_ デジカメ

最近、またデジカメが欲しくなっている。今度は銀塩コンパクトカメラの代替が欲しい。 素早いスナップはExilimで十分なのだが、「写真機」としてみると、

• パンフォーカス
• マクロなし
• 絵の粗さ

が気になる。大きさは多少大きくても(コンパクトカメラ程度なら)良いから、

• 適当に素早い動作
• オートフォーカス
• それなりの絵
• ほどほどの価格

のデジカメっないものだろうか。 特に絵については、いろんな条件で撮って見ないと分からないからなあ。

_ [Ruby]香川県ホームページ

日経BizTec Specialの記事によれば、 香川県のホームページはRubyとPHPで構築されているそうだ。

同記事には、Rubyについて

システム開発言語には、オブジェクト指向型スクリプト言語「ruby」を採用した。Javaや、rubyと同じくスクリプト言語である「PHP」などの選択肢がある中で、決してメジャーではないrubyを選んだ理由は「メンテナンスのしやすさと互換性の高さ」だったという。

メンテナンスのしやすさとは、プログラムの修正や変更がしやすいということだ。当初はJavaという選択肢もあったが、プログラムを修正するたびにコンパイル（実行コードの生成）が必要な「コンパイル型言語」より、修正や変更を柔軟に行える「スクリプト言語」を選択したというわけだ。データベースの扱いが容易なスクリプト言語としてはPHPもあるが、「テンプレートを使って簡単にデザインを変えられるようにしたいという要望に対し、 rubyが機能的に優れていました」（富士通香川システムエンジニアリング システム部eビジネスグループ主任 矢野雅彦氏）。

と語っている。「互換性」と言われると1.6と1.8の間でもいろいろあったので (1.8と1.9の間でもいろいろある予定だし)、かなり心苦しいのだが、 Rubyが高く評価してもらえたのは素直に嬉しい。

_ [本]4150113378

4150113378 Greg Eganの短編集を読む。

• 貸金庫
• キューティ
• ぼくになることを
• 繭
• 百光年ダイアリー
• 誘拐
• 放浪者の軌道
• ミトコンドリア・イヴ
• 無限の暗殺者
• イェユーカ
• 祈りの海

表題作『祈りの海』は(中編サイズのような気がするけど)、全然感動しなかった。 道具立ても陳腐だし、オチも凡庸。異世界の描写はやるならもっと突っ込んだ方が良い。 でも、これってヒューゴー賞やらローカス賞やら取ってるんだよね。 私の感性が鈍いのかなあ。それとも宗教関連の作品に偏見があるとか(ありえる)。

一番面白かったのは『貸金庫』、続いて『ぼくになることを』、『誘拐』、『放浪者の軌道』くらいかな。 特に『ぼくになることを』は最近読んだ哲学的な何か、あと科学とかの＜思考実験（３）　どこでもドア２＞を思い出した。 いや、どこでもドアの方は毒があり過ぎて、ちょっと読んでてつらいんだが。

アイディアに感銘を受けたのは『百光年ダイアリー』、『無限の暗殺者』。

ところで、『ぼくになることを』って同じ設定を使った遠未来の話があったよね。 タイトルが思い出せない。波動を使ったスポーツのようなのが出る話。 あれ、Eganじゃなかったような。

_ [言語]Curlと言語ビジネス

CNET Japanの『「SIerのビジネスモデルを変える」--新ウェブ言語Curlとは』という記事で、Curlとそのビジネスについて紹介されている。 インタビューを受けているのは、カール・アジアパシフィック(CAPC)の塩野谷光司社長と田中秀明企画本部長。

過去の観察とあらゆる考察の結果として、 言語ビジネスについては希望を持てない私だが、 成功できるはずがないとまで思っているわけではないので、 彼らの主張について考察し、見守っていきたいと思っている。

詳しくは記事を 読んでいただきたいが、彼らの主張を要約すると以下の通りである。

1. Curlはウェブシステム開発用のプログラミング言語であり、 HTMLやJavaScript、Flash、Java、C++などの機能を包括している。 単一の言語でさまざまな領域をカバーできる。 一番重要な機能はリッチクライアントが開発できること。
2. Curlは開発効率が高い。感覚的にはJavaの半分から3分の1の期間で済む。
3. Curlはライセンスビジネスを行う。ライセンスは最近大幅な値下げを行った(開発環境が5万9800円、サーバライセンスが20ユーザーで30万円から)。有料の言語であっても効果が十分高ければ広まる(に違いない)。
4. 2004年度の半ばにはブレイクしてくるのではないか。今年度の売上目標は3億円。

これらに対する私の意見は以下の通り。

1. Curlの言語仕様は『4839908834』を 二度ほど立ち読みしただけしか知らないのだが、 少なくとも既存のプログラミング言語をよく知る身には決して学びやすくはない。

   一番の問題はどこにブレースを付けてよいのか、いけないのかが分からないこと。 あるいは上記の本の問題なのかもしれないけれど、サンプルのメソッド定義のボディで、 ある文はブレースで囲まれており、ある文はそうでないのを見ると不安を感じる。 それ以外の文はなんだかQuote形式のLispみたい。最近ぽい表現だとTclか。 でも、LispやTclの方が(文法が低レベルなぶんだけ)理解しやすい。

   リッチクライアントは魅力かもしれないが、 Javaアプレットがあれだけ期待された割にそれほど成功しなかった点を見ると、 安心はできない。言語の成功は機能だけにはよらないからだ。

2. Curlは開発効率が高いというのは分かる気がするが、 スクリプト言語的性質を持つ言語であればJavaの半分から3分の1の期間というのは、割と普通。

   Javaには豊富な資産が存在するので、 その中にそのものずばりのライブラリ(or フレームワーク)を持っていれば、 そんな差はふっとんでしまうだろうけど。

3. 有料の言語はやはり難しいと思うなあ。言語みたいに差が出にくいものでは、 試してみるのにさえお金がかかるものを採用するのは難しいんじゃないだろうか。 Oracleのような単機能のものであれば、まだ分かりやすいけど、 言語は導入してもそれだけじゃなんにもできないから。

   「多くのコンパイラは有料でしたし、Javaもすべて無料なわけではありません」という田中氏の発言には 同意できない。もちろん昔から今に至るまで有料のコンパイラは存在していて、 細々とビジネスになっているのは事実だが、有料の処理系しかなくて成功した言語は極めて稀だ。 VBくらいじゃないだろうか。マイクロソフトのような市場に対する影響力があってはじめて成立することなんじゃないだろうか。

   無料の処理系があって、いろいろ試してみてこれは使えそうだっていうんで、 より性能の高い処理系を買うっていうのが通常のパスではないだろうか。 そこで(いくら企業にとってみれば安価であるとはいえ)、 有料の処理系しかなければ圧倒的に敷居は高い。

   だからといって、無料の処理系を出してしまうと広まるかもしれないが(実は無料でさえ新しい言語が世に広まるのは非常に困難なのだが、それは置いておくとして)、そのぶん、お金を出して処理系を買おうという意欲は確実に減ってしまうわけで、痛し痒しである。REBOLとかそんな感じだよね。

   長い歴史の中で言語ビジネスでかろうじて生き延びているのは、 既存の言語の(ハイパフォーマンスな)処理系を売っているところだけではないだろうか。 新しい言語を導入して一儲けを企むベンチャーは後をたたないが、 文字通り「死屍累々」である。Curlにはぜひ例外になってもらいたいものだ。

というわけで、2004年度の半ばにはブレイクしてくることが期待されるCurl言語、 私も応援したいのだが、お金を出して開発環境を買うほどの熱意はない。 せめて『4839908834』でも買うことにしようか。

_ [家族]保育園修了式

うちの息子が保育園を卒業する。思えばこの3年、たびたび送迎したものだった。 小学校には自分で行ってくれるから、これで楽になるな。

まわりを見回すと、親や先生にはうるうるしている人が多く見受けられた。 確かに保育園はあずかっている時間が長いから、 下手すると(下手しなくても？)家族よりも長い時間を過ごしたりするわけだものな。 情が移るのは当然だろう。

うちの子は当初内にこもりがちなタイプだったので、先生にはずいぶん迷惑をかけた。 あの頃と比べるとずいぶん活発になったものだ。大変感謝したい。

_ [会社]面談

午後は会社で入社希望者の事前面談に参加。 正式な申し込みの前に、会社の事情とか情報交換とかがしたいという希望なのだ。

私としては、今までうちの会社にはなかった才能の持ち主なので、 ぜひともおいでいただきたい。仲間(同類)が増えるのも嬉しいし。 こうやって、オープンソース関係者をスカウトするのが私の野望なのだ。 まだ数人しか成功していないけれども。

あと、この人とは別件だが業務連絡:

あー、履歴書だけ送ってきて、そのままにしている関係者、 待ってますから、フォローの連絡をください。 今のままじゃ面接も出来ません。

この日記を読んでるのは分かってるんだ。

_ [教会]出雲

家族を置いていくのが少々心配ではあるが、今日は出雲訪問。

聖餐会では「祈り」について話したが、後で話の中で使ったエピソードは、 以前にも出雲で話していたことが判明。ちょっとショック。 最近は、いつどこで話したかネタ帳に記録しているのだが、 このネタは日付の記録を行う習慣前に書き込んだものだったらしい。 今後気をつけよう。

支部長さんといろいろと話す。地方の小都市の教会特有の悩みは山陰地方のどこでもある。 人材流出の悩みは深い。

_ [家族]歩く

息子が「うちの近所でメノウがとれる」との話を聞いてきたらしい。 せっかくだから、帰宅後、息子の「探検」につきあう。 むやみにあちこち歩き回る息子につきあっていたら、 予想以上に歩く破目になってしまった。疲れた。 数キロは歩いたろうか、普段から全然運動していないから、体がなまりきっている。

息子はメノウらしい石をいくつか拾ってご満悦。

夕方は、友達と「足湯に行く」と言って出ていった娘たちが帰ってこない。 暗くなりはじめたので、どこまでいったかと探しに出かける。 足湯のある川沿いに、温泉街の端まで歩いても見つからない。 これでまた1キロやそこらは歩いた。もうダメ。

結局、すっかり暗くなってきたから帰ってきた娘に少々説教してから、 友達を車で送っていく。

_ [本]Lightweight Language Magazine

届いた。全体に去年のLL Saturdayの雰囲気を活字でよく再現している。 行かなかった(行けなかった)人も、これを読めば大丈夫。 追加されている記事もあるので、行った人も楽しめると思う。

私の原稿は3本。

• Lightweight Language Magazineに寄せて

  Larry Wall(Perl), Guido van Rossum(Python), Zeev Surasuki(PHP), そして私(Ruby)、 という言語デザイナーによる献辞。 なんて豪華な。注目点は実はそれぞれの写真だったりするかも。

• Lightweight Languageとは？

  LLの定義について。Matz流「俺定義」が炸裂します。

• Language Update

  Rubyの最近と将来について。他の言語に比べておとなしすぎるかなあ。

_ [言語]List Comprehension(リスト内包表現)

LLMで思い出したけど、Pythonに最近加わった。 List Comprehension(p.136)って記法としてはあんまり嬉しい気がしないんだけど。 いっそ、Haskellのみたいにすれば良かったのに。 Pythonが記号的な表現を嫌うのはわかるけど、 もっとコンパクトな記法の方が元々のPythonの性格に合っているのではないかと(そのためにblock by indentationとか導入したんだと思うし)。 まあ、言語の性格はだんだん変わるものではあるけどな。

Python版:

def qsort(list):
  if not list:
    return []
  x, xs = list[0], list[1:]
  return qsort([y for y in xs if y < x]) + [x] +\
         qsort([y for y in xs if y >= x])

Haskel版:

qsort [] = []
qsort (x:xs) = qsort elts_lt_x ++ [x] ++ qsort elts_ge_x
                where
                  elts_lt_x = [y | y <- xs, y < x]
                  elts_ge_x = [y | y <- xs, y >= x]

Rubyには要らないと思う。Enumerableとブロックの組み合わせが十分強力だから。

def qsort(list)
  if list.size == 0
    return []
  end
  x, *xs = *list
  elts_lt_x, elts_ge_x = xs.partition{|y| y < x}
  qsort(elts_lt_x) + [x] + qsort(elts_ge_x)
end

ちゅーか、ブロックのパワーに比べたらList Comprehensionは中途半端。 Pythonにもlambdaがあるからいくらでも似たようなことができるはずなのに。 Guidoはlambdaは好きじゃないらしい。

_ [OSS]オープンソース・ソフトを「作る」ことはビジネスになるか

ITProの高橋さんのコラム。

これに対する答えは、質問の解釈の仕方によって変化しそう。

• オープンソースソフトウェアを作ることをビジネスにすることが可能か(不可能ではないか)。
• オープンソースソフトウェアを作ることをビジネスにすることは、私にもできるか

前者であれば疑いはない。 実際にビジネスを回している会社はいくつもあるのだから(成功例がひとつでもあれば可能であることは証明可能)。 後者についての私の答えは「誰にでもできるほど簡単ではないし、将来それほど簡単になるとも思えない」である。 誰でもすぐに気がつくと思うけど、オープンソースビジネスはリスキーだ。 苦労して作ったソフトウェアそのものが無償で配布されてしまうので。

ただし、この記事に対するコメントにあるような、

オープンソースに協力している企業の技術力を示すとありますが、利用者は誰が作っているかなどほとんど見ないので、投資コストには見合わないですね。。。

という意見には賛成しない。オープンソースソフトウェアは配布コストがほとんどかからないので、 できるだけ広く行き渡って、技術力を気にする人のところに届けばそれで十分だからだ。 たとえ99.8%の人が「誰が作っているかなど見ない」かどうかは関係ない。

リスクについていえば、ビジネスには基本的にリスクが付き物だ。 オープンソースというキーワードを利用して競争力を得ることでリスクが減ることだって考えられる。

企業規模によっては、 少々のリスクをとってオープンソースというやり方を「利用」しなければ、 そもそもレースに参加できない。たとえば、うち(netlab.jp)の場合。 投資コストに見合う見合わないの問題ではない。

私には、なにもしないこと、差別化を行わないことが最もリスクが高いように感じられる。 オープンソースを利用するにしても、しないにしても。

_ [言語]言語ビジネス

言語ビジネスとは、今まで存在していなかった新しい言語によってビジネスしようという試み、と定義しよう。 その他にも、既存の言語の処理系を使ってビジネスする「言語ビジネス」もありえるが、 ここでは扱わない。

私は言語ビジネスを応援したいと思っている。しかし、失敗してほしくないとも思っている。 そこで、言語ビジネスの現状と課題について(Curlを例にして)まとめておこうと思う。

言語ビジネスの難しさは、「新しい言語の価値」にあると思う。

• 新しい言語を取得するのにはコストがかかる。 実際はたいしたことはないことが多いのだが、 少なくとも多くの人はコストがかかると思っている
• 新しい言語が定着するのは難しい。 定着しなければその言語に対して行った投資が無駄になるかもしれないという意識は ビジネスの障害になる
• 「新しい言語」でなければできないことというのは、意外に少ない。 多くの言語は似たような計算モデルを採用しているし、 「この言語でならできる」機能は、実は若干のツールの整備で既存の言語でも可能かもしれない。 (例: Curlの機能の多くはJava AppletやFlashや専用クライアントを使って実現可能)
• 言語開発者の感じている「感動」は、その言語の潜在的顧客には伝わらない。 言語開発者にとって「新しいこと」や「美しいこと」は大問題で、 それを実現する新しい言語は素晴らしいものだが、 多くの顧客にとってはそれらはどうでも良い

結局は「言語そのものはビジネスにならない」ということの再確認のような気がする。

ではどうするか。思いつくいくつかの方法をあげておこう。

• 言語ビジネスとは別のルートで言語を普及させておく。

  SunがJavaで行ったように、直接ビジネスとは関係のない形で、 無料の処理系を配布したり、オープンソース化したりすることで、 世間に認知してもらう。ついでに企業ブランドを売り込むことを忘れない。

• 言語ではなく、「機能」を売る

  「普通の顧客」には言語はどうでもいい。 言語設計者としては自己否定につながるので認めたくないのだが、事実は事実だ。 そこで「アプリケーション」を売り、その組み込み言語として「新しい言語」をくっつけておく。 たとえばAutoCADのAutoLispとか。

  あるいは周辺ツールを売るビジネスもありえるだろう。 たとえばZend Corp.は開発環境Zend Studioを売っている。

• 既存の言語をジャンプ台にする

  既存の言語処理系を使ったビジネスを行いつつ、 独自の言語拡張を付加して「新しい言語」にしてしまう。 たとえばBorlandがPascalにオブジェクト指向機能を追加してDelphi(Object Pascal)を作ったように。

これらのうちいくつかを組み合わせたり、別の方法を導入することで 明日の「成功する言語ビジネス」を見ることができるかもしれない。

もっともこれらを組み合わせても万全ではない。 上で述べた戦略をとっても生き残ることができなかった企業も数多い。 Objective-CのStepstoneも今はなく、EiffelのISCも「かろうじて」という感じだ。 Borlandも傾いている。

そんな茨の道でも頑張ろうというチャレンジャーはぜひ応援したいものだ。

とりあえず、Curlには「言語を前面に出さず、効率の良いWebアプリケーション開発ツールとして売る」戦略をお勧めしたい。Curl言語をオープンソース化するとなお良いが、たぶん無理な相談だろうなあ。

ところで、WaterとかAQUAとか、どうなったんだろう。

_ [家族]花見

午後から私の両親が来て、花見をする。 ちょうど今日が満開くらいか。

ついでに玉造の足湯につかる。

子供たちは両親とともに実家に。 春休みで親子双方にストレスがたまっているので、 ガス抜きをかねて4日ほど実家にあずかってもらうことにした。