[言語]言語ビジネスの難しさ少々古い話になるが、SophosがActiveStateを買収したという話があった。リンク先のインターネットウォッチの記事を引用すると英Sophosはカナダのスパム対策ソフトベンダーActiveState社を買収したと発表した。買収総額は2,300万米ドルに相当するという。Sophosはウイルス対策ソフトベンダーだが、スパム被害が拡大する中で、企業など法人市場でウイルスやスパム、不法アクセスなどセキュリティに関する統合的ソリューションへのニーズが高まっている現状を受けて、ActiveStateの買収を決定した。ActiveStateのスパム対策の技術やノウハウを得ることで、よりセキュリティソリューションを充実させるのが目的だという。事情を知らなければ「ウィルス対策ベンダーがスパム対策ソフトベンダーを買収した」という普通のニュースに読める。実際にはもう少々裏がある。オライリーとマイクロソフトが出資して1997年に創立された会社である。Tclにも広げて、KomodoというIDEを提供していたりする。れっきとした「言語ビジネス」カンパニーなのだ。ところが、正直売り上げはいまいちだったらしい。それがきっかけで身売りする破目になってしまったということだ。それでも、「やはり言語ビジネスは死屍累々」の一例が歴史にきざまれた、との思いが強い。ActiveStateには知り合いが何人もいるので、彼らが安泰であることを願うものだ。ActiveStateのことをもうちょっと押さえている。オープンソースビジネスの難しさも表現しているかもしれない。オープンソースビジネスはまだまだ脆弱だ。実際、なかなか金にならない。「システムの価格が下がっても、原価が下がるため、利益率は下がらない」とはいかない場合も多いのだ。ソフトウェアビジネス全般が脆弱だという意味かもしれない。コメントをいただいた。貴重な意見だと感じるので、ここに全文再掲。文法のデザインは、ハフマン符号化のようなものかもしれません。基本は「良く使うものを書きやすく」ですが、それをすると、その影で書きにくくなる部分があります。例:演算子など、lexerにとって特殊な意味をもつ文字を増やす→識別子にその文字が使えなくなる。中置記法を使う→その演算子が2項演算に限定される(haskell方式を使わない限り)。そもそも、「良く使う」ものが特別扱いされているということを覚えておかねばならない、等。最後のものは、言語設計者の考える使用法と、言語ユーザの考える使用法がずれている場合に、ユーザの負担になります。使う人のバックグラウンドや対象となる問題領域にかかわらない、グローバルに最適な「良く使うもの」を決められるとするか否かで、立場が分かれると思います。optimizationになります。この立場では、なるべく文法規則を単純で一様なものにしておき、必要ならプログラマが問題に合わせてカスタマイズする、という方向になります。これがLispやTclの立場だと思います。問題の対象が限定されればされるほど「良く使う」操作に関して予測が立てやすくなるので、最適化が成功しやすくなるでしょう。シェーダー言語に、汎用的配列とは別に2〜4要素のベクタと配列を扱う文法レベルでのサポートがあるのは大いに意味があります。問題の対象を一切限定しないで、グローバルに最適な文法をデザインできるか、はかなり未知なる領域だと思います。これくらい切れ味の良い文章が書きたいものだ。私の文章と言ったら...。それは置いといて、このコメントを切り口として文法のデザインについて考えてみたい。shiroさんは「問題の対象を一切限定しないで、グローバルに最適な文法をデザインできるか、はかなり未知なる領域」とあいまいに表現してらっしゃるが、私はすべてをカバーするのことは、はっきり無理だと思う。理解できる戦略である。多くの人にとって、とっつきにくいのも事実である。あまりに柔軟に変化しうるので、結局提供される共通項は大枠(メタ文法)だけということになりかねない。無理が出るような気がする。optimizationになる。とっつきにくさを生んでしまうし、柔軟性によってかえって消費脳力が増えてしまう(かもしれない、私の仮説)。鍵は「あらゆる領域をカバーすることはない」ということだろうか。その文法には十分価値があるのではないだろうか。この「80%に有効な文法」というのはけっこう可能なところではないだろうか。成功するために必要そうな条件について、後日考察してみることにしよう。私が「Rubyのまつもと」と呼ばれるように。初心者パラドックス初心者に優しくないと評判のまつもとです(苦笑)。高橋さん曰く:この辺のまつもとさんの発言はパラドキシカルなもので、「そういう発言をすると良心的な初心者は(良心的なので)結局萎縮する一方、良心的でない初心者は(良心的じゃないので)そんな発言は気にしないか、逆切れする」ということで、実はあんまり益のない発言だと思うのですがどうでしょう>まつもとさん確かにそうかも。ない初心者は相手にしないってのが私の立ち位置かもしれません。初心者を助けることよりも重要だったりするかもしれません。期待はともかく、なんとなく正体は「初心者にも優しくなく、開発も進まないまつもと」のような気がしないでもないんですが。take」などは存在しません。あるのは「質問・ネタフリという貢献」と「回答・応答という貢献」だけ、つまりgiveしかないのです。いう言葉には賛成です。考えたら、一部は理解できてきた。これくらいすぐ理解しろよって感じだが。個別のツールに言語を組み込む必要はない(言語が主、ツール(機能)が従)ツールに言語を組み込むなんて..ナンセンスということが要点のようだ。ここは反論として、なぜツールに言語を組み込むことがナンセンスでないか、を示すべきだろう。「DSLはナンセンス」という主張はしない。いうか、ユーザと開発者がそれを望むならDSLはナンセンスどころか優れたアプローチだと思うし。組み込み言語がナンセンスであるほど万能のソリューションではない、と言うだけ。考えるに、言語(DSL)が主ではいけない技術的な理由はない。技術的には差は全くないだろう。かかわらず、いまだに私は「成功するためには言語主・ツール従ではなく、ツール主・言語従」であるべきだと考えている。最大の理由は「ユーザと開発者の心理」である。DSLをポンと渡されて自由に使いこなせるユーザは少ない(と思う)。いうのが一般的なユーザエクペリエンスではないだろうか。なると必然ツール主体が望ましいということにはならないだろうか。開発者もDSLを作りたいと言う人は少数派だ(と思う)。「じゃあ、あなたのツールを機能ごとにばらばらにして、この言語から使えるようにすれば立派なDSLになりますよ」というのは、あんまり喜ばれないんじゃないだろうか。(たとえ実際の作業の本質がほとんど大差なくても)心地よく聞こえるのではないだろうか。成功するためには、心理的な側面も重要だ*1。ところで、shelarcyさんの意見だが実はまだ理解できないところがある。利用する」とはどういう意味か。「ある言語でうまくできること」のに「私が考えなかったこと」は何か。ここで「だから、Lispや関数型言語は広まらないんだ」なんて暴言は思っても吐いてはいけない。そんなこと言ってませんからねー。月に一度の断食安息日。今月もつつがなく終わった。授乳中の妻と小さい子供(たち)は断食しなかった。上の子たちはよく協力してくれた。あったが、少なくとも現時点までは親が伝えたいと思ったことを良く理解してくれているようだ。いや、できた子供たちだ。