少々古い話になるが、SophosがActiveStateを買収したという話があった。
リンク先のインターネットウォッチの記事を引用すると
英Sophosはカナダのスパム対策ソフトベンダーActiveState社を買収したと発表した。買収総額は2,300万米ドルに相当するという。
Sophosはウイルス対策ソフトベンダーだが、スパム被害が拡大する中で、企業など法人市場でウイルスやスパム、不法アクセスなどセキュリティに関する統合的ソリューションへのニーズが高まっている現状を受けて、ActiveStateの買収を決定した。ActiveStateのスパム対策の技術やノウハウを得ることで、よりセキュリティソリューションを充実させるのが目的だという。
と、まあ、事情を知らなければ「ウィルス対策ベンダーがスパム対策ソフトベンダーを買収した」という普通のニュースに読める。
しかし、実際にはもう少々裏がある。AcriveStateは、 元々はスパム対策ソフトベンダーでも何でもなくて、Windows版Perlの開発とPerlサポートを目的として、 オライリーとマイクロソフトが出資して1997年に創立された会社である。 その後、対象をPython, Tclにも広げて、KomodoというIDEを提供していたりする。 つまり、れっきとした「言語ビジネス」カンパニーなのだ。
ところが、正直売り上げはいまいちだったらしい。 去年くらいからオープンソースでないスパム対策ソフトを販売しはじめ、 とうとうそれがきっかけで身売りする破目になってしまったということだ。
まあ、ソフトウェア開発関連のビジネスも継続するということで、 ActiveStateそのものがなくなってしまうよりは百万倍良いのだが、 それでも、「やはり言語ビジネスは死屍累々」の一例が歴史にきざまれた、との思いが強い。
ActiveStateには知り合いが何人もいるので、彼らが安泰であることを願うものだ。
なお、japan.linux.comの記事は さすがにActiveStateのことをもうちょっと押さえている。
さて、これはActiveStateはオープンソースビジネスカンパニーでもあったので、 オープンソースビジネスの難しさも表現しているかもしれない。オープンソースビジネスはまだまだ脆弱だ。 実際、なかなか金にならない。NTTコムウェアの長野氏が語るように、 「システムの価格が下がっても、原価が下がるため、利益率は下がらない」とはいかない場合も多いのだ。
もっとも、これはオープンソースビジネスが特に脆弱である、というわけではなくて、 ソフトウェアビジネス全般が脆弱だという意味かもしれない。
先日の言語ツールキットに関連して、 (Gaucheの)shiroさん*1から コメントをいただいた。貴重な意見だと感じるので、ここに全文再掲。
文法のデザインは、ハフマン符号化のようなものかもしれません。基本は「良く使うものを書きやすく」ですが、それをすると、その影で書きにくくなる部分があります。例：演算子など、lexerにとって特殊な意味をもつ文字を増やす→識別子にその文字が使えなくなる。中置記法を使う→その演算子が２項演算に限定される(haskell方式を使わない限り)。そもそも、「良く使う」ものが特別扱いされているということを覚えておかねばならない、等。最後のものは、言語設計者の考える使用法と、言語ユーザの考える使用法がずれている場合に、ユーザの負担になります。
使う人のバックグラウンドや対象となる問題領域にかかわらない、グローバルに最適な「良く使うもの」を決められるとするか否かで、立場が分かれると思います。
そのようなグローバルな最適点は無くて、最適な解は個々の問題を解くプログラマのみが知っている、とする立場に立つと、「良く使うもの」を言語設計者が決め過ぎるのはpremature optimizationになります。この立場では、なるべく文法規則を単純で一様なものにしておき、必要ならプログラマが問題に合わせてカスタマイズする、という方向になります。これがLispやTclの立場だと思います。
一方、問題の対象が限定されればされるほど「良く使う」操作に関して予測が立てやすくなるので、最適化が成功しやすくなるでしょう。シェーダー言語に、汎用的配列とは別に2〜4要素のベクタと配列を扱う文法レベルでのサポートがあるのは大いに意味があります。
問題の対象を一切限定しないで、グローバルに最適な文法をデザインできるか、はかなり未知なる領域だと思います。
これくらい切れ味の良い文章が書きたいものだ。私の文章と言ったら...。
まあ、それは置いといて、このコメントを切り口として文法のデザインについて考えてみたい。
shiroさんは「問題の対象を一切限定しないで、グローバルに最適な文法をデザインできるか、はかなり未知なる領域」とあいまいに表現してらっしゃるが、私はすべてをカバーするのことは、はっきり無理だと思う。 だから「premature optimizationを避けるため単純で一様なものを選択する」のが「LispやTclの立場」だというのは、 十分理解できる戦略である。
しかし、TclやLispは「単純で一様」ではあるが、 多くの人にとって、とっつきにくいのも事実である。 また、あらゆる局面に対応するためにあらゆるカスタマイズが可能なのは良いとしても、 あまりに柔軟に変化しうるので、結局提供される共通項は大枠(メタ文法)だけということになりかねない。 となると、「単純で一様」なものですべてをカバーしようと思うと、 無理が出るような気がする。
ふむ。最適な文法をデザインしようとすれば「バックグラウンドや対象となる問題領域」によっては、 premature optimizationになる。 しかし、それを避けて「単純で一様なものを選択する」ことは(それを好む人がいる一方で)、 とっつきにくさを生んでしまうし、柔軟性によってかえって消費脳力が増えてしまう(かもしれない、私の仮説)。
鍵は「あらゆる領域をカバーすることはない」ということだろうか。 すべてに最適な文法が存在できなくても、たとえば仮に、 80%で有効で、 残りのうち10%が可能である(残り10%はすっぱりあきらめる)、 という文法が存在できるとすれば、 その文法には十分価値があるのではないだろうか。
(比較的オーソドックスな)プログラマビリティを提供する文法を仮定すると、 この「80%に有効な文法」というのはけっこう可能なところではないだろうか。
さて、仮に言語ツールキットを本当に作るとして*2、 成功するために必要そうな条件について、後日考察してみることにしよう。
初心者に優しくないと評判のまつもとです(苦笑)。
この辺のまつもとさんの発言はパラドキシカルなもので、「そういう発言をすると良心的な初心者は（良心的なので）結局萎縮する一方、良心的でない初心者は（良心的じゃないので）そんな発言は気にしないか、逆切れする」ということで、実はあんまり益のない発言だと思うのですがどうでしょう＞まつもとさん
確かにそうかも。いや、その辺はあえて無視して、 良心的な初心者にはたたみかけるように「萎縮するな」と(ある意味無茶を)呼びかけ、 そうでない初心者は相手にしないってのが私の立ち位置かもしれません。
実は、若干エゴイスト入ってる私には、 「困った初心者」に悩まされないことの方が、 初心者を助けることよりも重要だったりするかもしれません。
ところで、初心者に優しいが、そればっかりやってRubyの開発が全然進まないまつもとと、 初心者の扱いは他人に任せるがRubyの開発はばっちりのまつもととどっちがお好みでしょう？ みなさん。
期待はともかく、なんとなく正体は「初心者にも優しくなく、開発も進まないまつもと」のような気がしないでもないんですが。
いずれにしても、高橋さんの
私見では、MLには「give and take」などは存在しません。あるのは「質問・ネタフリという貢献」と「回答・応答という貢献」だけ、つまりgiveしかないのです。
という言葉には賛成です。
shelarcyさんのツッコミに、 ぜんぜん分からないなどと返事してしまったが、 ちょっと考えたら、一部は理解できてきた。これくらいすぐ理解しろよって感じだが。
要するに
ということが要点のようだ。
ここは反論として、なぜツールに言語を組み込むことがナンセンスでないか、を示すべきだろう。 ただし、「DSLはナンセンス」という主張はしない。 っていうか、ユーザと開発者がそれを望むならDSLはナンセンスどころか優れたアプローチだと思うし。 ただ、組み込み言語がナンセンスであるほど万能のソリューションではない、と言うだけ。
考えるに、言語(DSL)が主ではいけない技術的な理由はない。 プログラマブルなツールと、そのツールが持つすべての機能を利用できるDSLとでは、 技術的には差は全くないだろう。 にもかかわらず、いまだに私は「成功するためには言語主・ツール従ではなく、ツール主・言語従」であるべきだと考えている。
なぜか。
最大の理由は「ユーザと開発者の心理」である。
DSLをポンと渡されて自由に使いこなせるユーザは少ない(と思う)。 まずは提供されるツールを使い、 それを拡張したいと考えた時にはじめてプログラム機能を使いツールを強化していく、 というのが一般的なユーザエクペリエンスではないだろうか。 となると必然ツール主体が望ましいということにはならないだろうか。
開発者もDSLを作りたいと言う人は少数派だ(と思う)。 たくさんいる「ツールを作りたい開発者」が自分のツールにプログラム機能が欲しくなった時の答えとして 「じゃあ、あなたのツールを機能ごとにばらばらにして、この言語から使えるようにすれば立派なDSLになりますよ」というのは、あんまり喜ばれないんじゃないだろうか。 むしろ「この言語ツールキットをリンクして機能を登録してやれば、 あなたのツールがプログラマブルに」と言ってあげた方が、 (たとえ実際の作業の本質がほとんど大差なくても)心地よく聞こえるのではないだろうか。
成功するためには、心理的な側面も重要だ*1。
ところで、shelarcyさんの意見だが実はまだ理解できないところがある。
*1 ここで「だから、Lispや関数型言語は広まらないんだ」なんて暴言は思っても吐いてはいけない。そんなこと言ってませんからねー。言ってないってば
月に一度の断食安息日。今月もつつがなく終わった。
授乳中の妻と小さい子供(たち)は断食しなかった。 上の子たちはよく協力してくれた。 思春期にさしかかって、自我が発達したら教会のことをどう思うのか不安に感じたことも あったが、少なくとも現時点までは親が伝えたいと思ったことを良く理解してくれているようだ。
いや、できた子供たちだ。
今日も出張。東京へ。
情報処理月間のU-20プログラミングコンテストの表彰式。 例年、表彰式は失礼していたのだが、今年は審査委員長の石田先生が 急遽出張になったということで、審査員講評を行う人(の一人)として 呼ばれたのだった。
いやあ、元気のいい若い人を見るのは気持ちがいい。
大賞を取った高橋くんを取材するため、 テレビ岩手から取材が来ている。すげー、地元のヒーローだ。 ま、ローカルニュースで取り上げられるくらいのことはしてると思うけど。
で、私も取材された。「彼はどうですか？」
当然のようにほめちぎっておいた。 「世界に通じる人材になれますよ、きっと」とか。 ホントにそう思うしね。
その後、「日経コンピュータ」の取材。 「日経コンピュータ的立ち位置からのオープンソース」に関して。
(アメリカで)「ruby」という単語を含む求人情報数がどう推移しているか、というグラフ。 伸びてる、伸びてる。
「ruby」の部分を「java」「php」「python」とかに変えても なかなか面白い。
うちに帰ったら、長女が「お父さん、プログラムって面白いね」という。
耳を疑った。
彼女は「どうせMatzの娘と言われるだけだから」とシニカルな態度で プログラミングに興味なんかぜんぜん見せなかったのに。
話を聞くと、技術の先生が、学校のパソコン室のコンピュータにドリトルをインストールしてくれていて、 それのタートルグラフィックスで遊んでみたのだそうだ。
パパート先生、ありがとう。
その他、ドリトルの関係者の皆さんにもお礼を言いたい。
ま、それ以上、興味が進んだ風ではないのだが、 とりあえずプログラミングが面白い(こともある)と 感じてくれただけで、私は満足だ。
前後するが、上記のような展示が行われるということで、 CEATECに参加してきた。
非常に興味深かった。まだ試作段階ということなのだが、 家電上のCell(CPUとして見るとさほど高速ではない。GPUも積んでないし)でも それなりの速度で動作していた。
また、この試作版メニューでは自作アプリケーションの登録までもできるそうだ。 実際にマンデルブロ集合を表示していた。
開発者の方とお話ししたところ、ゼロから(Rubyを知らないところから)始めて 3ヶ月でものになったのだそうだ。組み込みの「普通」を知らないので、 「それって早いんですか」と聞いたところ、「早いです。しかも生産性すごく高いです」 とのことであった。
まだ、このプラットフォームを実際に採用するというところまではいっていない のだけれども、今後に期待、というところか。
家電組み込み領域ではできるだけリソースを削るというアプローチが一般的で ソフトウェア生産性のためにリソースをおごるという発想は 受け入れられないのではないか、と少々意地悪な質問をしたところ、 Cellを採用するような家電では違う傾向が出てくるのではないか(と期待している) とのことであった。確かにそうなれば喜ぶ人は多いだろう。
このほかにも東芝のブースではCellを使った いろいろな展示が行われていた。一般的にはSpursEngineが人気のようだが、 個人的にはひっそり(？)と展示されていたCellクラスタリングとかの 方が面白かった。
有機ELなどいろいろ話題な展示もあったようだが、 興味の方向が違うので、東芝の展示だけみて帰ってしまった。
午後はIPAで用事をしてから松江に帰る。
追記
ITproの高橋さんから、別の記事を紹介していただく。
「視察」なんて偉そうだよね。