『Dr.WEB メールデーモン』、MTA 用迷惑メール対策製品です！
CNET Japanの『「SIerのビジネスモデルを変える」--新ウェブ言語Curlとは』という記事で、Curlとそのビジネスについて紹介されている。 インタビューを受けているのは、カール・アジアパシフィック(CAPC)の塩野谷光司社長と田中秀明企画本部長。
過去の観察とあらゆる考察の結果として、 言語ビジネスについては希望を持てない私だが、 成功できるはずがないとまで思っているわけではないので、 彼らの主張について考察し、見守っていきたいと思っている。
詳しくは記事を 読んでいただきたいが、彼らの主張を要約すると以下の通りである。
これらに対する私の意見は以下の通り。
Curlの言語仕様は『Curlプログラミングエッセンシャルズ』を 二度ほど立ち読みしただけしか知らないのだが、 少なくとも既存のプログラミング言語をよく知る身には決して学びやすくはない。
一番の問題はどこにブレースを付けてよいのか、いけないのかが分からないこと。 あるいは上記の本の問題なのかもしれないけれど、サンプルのメソッド定義のボディで、 ある文はブレースで囲まれており、ある文はそうでないのを見ると不安を感じる。 それ以外の文はなんだかQuote形式のLispみたい。最近ぽい表現だとTclか。 でも、LispやTclの方が(文法が低レベルなぶんだけ)理解しやすい。
リッチクライアントは魅力かもしれないが、 Javaアプレットがあれだけ期待された割にそれほど成功しなかった点を見ると、 安心はできない。言語の成功は機能だけにはよらないからだ。
Curlは開発効率が高いというのは分かる気がするが、 スクリプト言語的性質を持つ言語であればJavaの半分から3分の1の期間というのは、割と普通。
Javaには豊富な資産が存在するので、 その中にそのものずばりのライブラリ(or フレームワーク)を持っていれば、 そんな差はふっとんでしまうだろうけど。
有料の言語はやはり難しいと思うなあ。言語みたいに差が出にくいものでは、 試してみるのにさえお金がかかるものを採用するのは難しいんじゃないだろうか。 Oracleのような単機能のものであれば、まだ分かりやすいけど、 言語は導入してもそれだけじゃなんにもできないから。
「多くのコンパイラは有料でしたし、Javaもすべて無料なわけではありません」という田中氏の発言には 同意できない。もちろん昔から今に至るまで有料のコンパイラは存在していて、 細々とビジネスになっているのは事実だが、有料の処理系しかなくて成功した言語は極めて稀だ。 VBくらいじゃないだろうか。マイクロソフトのような市場に対する影響力があってはじめて成立することなんじゃないだろうか。
無料の処理系があって、いろいろ試してみてこれは使えそうだっていうんで、 より性能の高い処理系を買うっていうのが通常のパスではないだろうか。 そこで(いくら企業にとってみれば安価であるとはいえ)、 有料の処理系しかなければ圧倒的に敷居は高い。
だからといって、無料の処理系を出してしまうと広まるかもしれないが(実は無料でさえ新しい言語が世に広まるのは非常に困難なのだが、それは置いておくとして)、そのぶん、お金を出して処理系を買おうという意欲は確実に減ってしまうわけで、痛し痒しである。REBOLとかそんな感じだよね。
長い歴史の中で言語ビジネスでかろうじて生き延びているのは、 既存の言語の(ハイパフォーマンスな)処理系を売っているところだけではないだろうか。 新しい言語を導入して一儲けを企むベンチャーは後をたたないが、 文字通り「死屍累々」である。Curlにはぜひ例外になってもらいたいものだ。
というわけで、2004年度の半ばにはブレイクしてくることが期待されるCurl言語、 私も応援したいのだが、お金を出して開発環境を買うほどの熱意はない。 せめて『Curlプログラミングエッセンシャルズ』でも買うことにしようか。
This work is licensed under a Creative Commons License.
以上の問題に加えて，有料の言語には「サポート期間」という問題もあります．RubyにしろJavaにしろ，たしかに無限のサポート期間が保証されているわけではありません．それでも，例えばSUNが倒産しようとまつもとゆきひろ氏が突然Rubyをやめたり，或いは事故か何かで二度とプログラミングができなくなっても（失礼！），それでJavaやRubyという言語までもが死ぬわけではありません．一度普及すれば，他の企業なり個人なりコミュニティなりが代わりにサポートを続けることが期待されますし，おそらくそうなるでしょう．(RubyならRubyコミュニティの方々が．JavaならばIBM辺りが．Javaのオープンソース化の話さえあったりする．)これに対して言語そのものが有料である場合は，その特定の組織がサポートを打ちきっただけで二度と使えなくなります．それこそVBやVC++のように．MSが突然発表した「VB/VC++サポート打ち切り」の方針に，悲鳴を上げた利用者が一体どれだけいたことか．．．．たとえCurlが宣伝通りに生産性が3倍あったとしても，いつその言語が使えなくなって他の言語に移植する羽目になるか．そのリスクを考慮するとたったの3倍程度では割に合いません．<br>あるとすれば完全に使い捨てのプログラムだけですね．書いた後に一度走らせたら二度と使わないような．私には一体どんな分野ならそんな無駄なことをするのか，ちょっと想像できませんけれど．
Eiffelはどうですか?
>村山さん<br><br>わが国の著作権法ではプログラミング言語自体は著作権保護の対象から除かれています(10条3項1号)ので、「有料の言語」というのは「有料の処理系しか現在の所選択肢がない言語」であって、「言語そのものが有料」と表現されているとちょっと違和感があります。全く現実的じゃないですが、Javaのように、言語仕様からオープンな処理系を他の誰かが作れば基本的に話は同じです。VBのオープンな実装って有るのか知りませんが、.NETクローンのMONOなんかも似たような話じゃないでしょうか。<br><br>ところで、まつもとさんは「長い歴史の中で言語ビジネスでかろうじて生き延びているのは、既存の言語の(ハイパフォーマンスな)処理系を売っているところだけではないだろうか。」と仰っていますが、Curlの記事中では、「Javaを利用した今のウェブシステムではサーバにかかる負担が大きい。・・・Curlは一度プログラムやデータをサーバからダウンロードすれば、あとはクライアント側で処理します。」の下りで、事実上のハイパフォーマンス処理が可能という話をしているので、言語の学習コストが無視できるほど低ければ、既存言語ではありませんが、既存ソリューションドメインでのより高いパフォーマンスを持つ処理系の実装そのものが売りになる筈です。そうすると、Curlは、アプリケーションサーバ等のフレームワークが主体で、言語自体はMacromediaのActionScriptみたいな役割の組み込みSDKの一部にすぎません(何で既存の言語のサブセットとか拡張とかにしないかは謎ですが)。「CurlはHTMLやJava、Flashなどの機能を包含」とか書いてあるので、Flashが競合相手なんだろうなあという印象です。
curlの話からは逸れますが，<br>言語仕様自体には著作権は認められなくても，周辺技術などを特許で押さえることは可能です．それによって互換処理系を作ることが絶対に不可能になるとは限りませんが，極めて困難になります．一例としてMSのような企業を相手に特許訴訟を戦うリスクを考えると「VBの仕様を無償で公開し互換処理系に対しては特許使用料は一切請求しない」と公にされていない限りは，互換処理系を作ることは事実上禁止されていると言って良いでしょう．なお公になっている場合でさえも，信用できなければ同じことです．SCOやらgif特許やらがそれを証明しています．<br>もう一つの問題は言語仕様です．言語仕様が極めて曖昧な場合には，その仕様に準拠した「互換処理系」は作れません．（<br>まあ仕様がある場合でもVisual J++のような非互換処理系も存在したりするわけですが．．．．）また実装のバグに合わせて恣意的に仕様の方が変更される可能性もあります．そうなるとオリジナル処理系のバグに合わせた仕様変更の度に，互換処理系メーカーは互換実装の変更が求められます．これも互換処理系の実現を困難にします．<br>本題のcurlに関しては，「一度プログラムやデータをサーバからダウンロードすれば」ということの障害の大きさを理解していないのようですね．多くのユーザーにこれを強制することは簡単ではありません．
やろうとするかどうかは別の問題だが<br>やる気になれば多くのユーザに強制するのは至極簡単です。
Curlは言語の枠組みというよりは、リッチクライアントの流れで理解するのが正しいと思います。<br><br>http://www.atmarkit.co.jp/fbiz/cbuild/serial/doukou/05/doukou05.html<br><br>http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=9892&forum=12&start=15<br><br>言語自体はどれも成熟して（資産も積み上がって）<br>容易に変えられなくなって来てますし。何年も<br>移行にかかります。トレンドを売り込むのなら<br>フームワークの違いくらいしかありません。
VB.NETについて補足すると,IDEは有償ですが,コンパイラは.NET Framework SDKの一部として無償配布しています。確かにVB6までは処理系を公開しなくても広く使われていたので,文意に異論はありません。
統一性が取れなくなるのでオープンソースにするのは反対ですが、Curlの利用を無償にしたらいいのでは。言語ビジネスを中心ではなく、周辺ビジネスを狙わないと。