CNET Japanの『「SIerのビジネスモデルを変える」--新ウェブ言語Curlとは』という記事で、Curlとそのビジネスについて紹介されている。 インタビューを受けているのは、カール・アジアパシフィック(CAPC)の塩野谷光司社長と田中秀明企画本部長。
過去の観察とあらゆる考察の結果として、 言語ビジネスについては希望を持てない私だが、 成功できるはずがないとまで思っているわけではないので、 彼らの主張について考察し、見守っていきたいと思っている。
詳しくは記事を 読んでいただきたいが、彼らの主張を要約すると以下の通りである。
これらに対する私の意見は以下の通り。
Curlの言語仕様は『4839908834』を 二度ほど立ち読みしただけしか知らないのだが、 少なくとも既存のプログラミング言語をよく知る身には決して学びやすくはない。
一番の問題はどこにブレースを付けてよいのか、いけないのかが分からないこと。 あるいは上記の本の問題なのかもしれないけれど、サンプルのメソッド定義のボディで、 ある文はブレースで囲まれており、ある文はそうでないのを見ると不安を感じる。 それ以外の文はなんだかQuote形式のLispみたい。最近ぽい表現だとTclか。 でも、LispやTclの方が(文法が低レベルなぶんだけ)理解しやすい。
リッチクライアントは魅力かもしれないが、 Javaアプレットがあれだけ期待された割にそれほど成功しなかった点を見ると、 安心はできない。言語の成功は機能だけにはよらないからだ。
Curlは開発効率が高いというのは分かる気がするが、 スクリプト言語的性質を持つ言語であればJavaの半分から3分の1の期間というのは、割と普通。
Javaには豊富な資産が存在するので、 その中にそのものずばりのライブラリ(or フレームワーク)を持っていれば、 そんな差はふっとんでしまうだろうけど。
有料の言語はやはり難しいと思うなあ。言語みたいに差が出にくいものでは、 試してみるのにさえお金がかかるものを採用するのは難しいんじゃないだろうか。 Oracleのような単機能のものであれば、まだ分かりやすいけど、 言語は導入してもそれだけじゃなんにもできないから。
「多くのコンパイラは有料でしたし、Javaもすべて無料なわけではありません」という田中氏の発言には 同意できない。もちろん昔から今に至るまで有料のコンパイラは存在していて、 細々とビジネスになっているのは事実だが、有料の処理系しかなくて成功した言語は極めて稀だ。 VBくらいじゃないだろうか。マイクロソフトのような市場に対する影響力があってはじめて成立することなんじゃないだろうか。
無料の処理系があって、いろいろ試してみてこれは使えそうだっていうんで、 より性能の高い処理系を買うっていうのが通常のパスではないだろうか。 そこで(いくら企業にとってみれば安価であるとはいえ)、 有料の処理系しかなければ圧倒的に敷居は高い。
だからといって、無料の処理系を出してしまうと広まるかもしれないが(実は無料でさえ新しい言語が世に広まるのは非常に困難なのだが、それは置いておくとして)、そのぶん、お金を出して処理系を買おうという意欲は確実に減ってしまうわけで、痛し痒しである。REBOLとかそんな感じだよね。
長い歴史の中で言語ビジネスでかろうじて生き延びているのは、 既存の言語の(ハイパフォーマンスな)処理系を売っているところだけではないだろうか。 新しい言語を導入して一儲けを企むベンチャーは後をたたないが、 文字通り「死屍累々」である。Curlにはぜひ例外になってもらいたいものだ。
というわけで、2004年度の半ばにはブレイクしてくることが期待されるCurl言語、 私も応援したいのだが、お金を出して開発環境を買うほどの熱意はない。 せめて『4839908834』でも買うことにしようか。
本屋で漫画雑誌を眺めると、 小学校、中学校、高校まで同じ学校の先輩が連載を始めていた。
２０年ぶりに見る先輩の漫画は、あんまり変わってなかった。 でも、ちょっと抑えてあったかな。 今後は漫画の道に進むんだろうか。
考えてみれば、当時は自分も高校生だったから気がつかなかったけど、 ２０年前に十代であれだけ描けたってことはすごいことだったんではないだろうか。 卒業直後からもう伝説になってたしな。
思い返せば私の高校時代は「鳥取県西部漫研黄金時代」の直後で、 二級上まではすごい人がたくさんいた。前田さんしかり、赤井さんしかり。 プロになった人もいた(いまは小説を書いている人もいるな)。
しかし、黄金時代が過ぎ去った後の私たちの世代はもう出がらしで、 たいしたことはできなかった。まあ、私は「描く人」ではなかったし、 そもそも漫研じゃなかったし。
やったのはせいぜいCOMECON(米子だからコメなわけだ)という同人誌イベントを企画したくらいか。
このレポートを書いたKenneth Brownは「LinusはLinuxを書いてない、Minixの盗用だ」と書いて、 Tannenbaumにけちょんけちょんにけなされていた人。まだ懲りていないらしい。
「こんな馬鹿がいる」という以上には意味のない記事だが、 マイクロソフトもこんなのに出資しているという事実自体が彼らにとっての不利益ではないかと。
学生の作品は公開していただきたい、ぜひ。
「R言語」のRubyは「P言語」の中間にいれてもらえないのは悲しむべきか喜ぶべきか。 もっとも「R」と同じ仲間に分類されても困るが。
ところで「G言語」って「GMW」の「G言語」、…じゃないよね、きっと。 「C」と「G」は4つ離れているから「#」を「+」4つと解釈したのかなあ。
でも、
(C++)++
だから、「+」4つじゃ、「E」にしかならないんだけど。残念。
あらすじ。「ブロック中のretryの動作の説明に疑問を感じたTom Moertelは、 その意味を理解すべくHaskellでRubyのmini evalulatorを実装し、 その動作を完全に理解したのであった。Cool」
そこまでやるか。継続を使ったretryの挙動の記述は(継続が理解できていれば)わかりやすい。
Joel on Softwareより。2000年3月だからずいぶん古い話だ。
良い人材を採用するための面接について。Joelは必要な資質について、 「今なにができるか、ではない」という。それはこれからいくらでも学ぶことができるから。
必要なのは
の両方を備えていることである、という。
両方備えていないのは論外として、どちらかしか持っていないとするとどうなるか。
Smartだけの人は(しばしばPhDを持ってたりするが)、実用にならない方向に能力を使ってしまう。 すばらしいが(ビジネスとしては)役には立たない。
Gets Things Doneだけの人はもっと悪い。彼らは考えずにプログラミングする。 コードを関数化せずにコピペしまくったり、 とりあえず動くが拡張性も何もないコードを書いたり。 結果として将来大きなトラブルを引き起こし、 他のSmartな人々の手を煩わせることになる。
でもね、Smartだけの人でもいいと思うんだ。他の人の意見を聞く耳があれば。 Gets Things Doneの部分は他の人が補うことができると思う、ある程度は。
あ、でも、ビジネスには「夢想家」は要らないかな。
もっとも私自身も若い頃は単なる夢想家で、 実力も知識も行動力もないため、壮大な構想を夢想するだけだった。 でも、人はいつかそこから卒業して、地に足をつけてなにかを作り出す必要があるのだろう。
Skypeで聞いてました。なかなかおもしろい。
でも、最後の私の質疑のところは面白くなかった。 いや、質問が少ないのもそうだけど、私もあまり気の利いた答えができなかったので。
それと、ああいうイベントって終わった後の雑談とかから有益なヒントが得られたりするんだよねえ。 Skypeじゃそういうの、ないものねえ。
監督が海外旅行に出かけたので、 副監督たる私が集会の管理・司会を行うことになる。
監督会の一員になって約１年、 監督会の出席が私一人だけになったことなく、 管理などすることがなかったので、緊張する。
とはいえ、いつもと違うことがあることがあるわけではなく、 ごく普通に乗り切った。
あ、聖餐のパンを持ってくるのを忘れたので、 お昼ご飯用に持ってきていたメープルパンが用いられた。 (主に子供に)好評であった。....。
Railsアプリケーションを(そのまま？)オフラインで動かす技術、なのだそうだ。
残念なことにフリーソフトウェアではないので、実際にどんなものなのかはよくわからないんだけど、興味深い。
「へぇ、サルでも分かるなんて大胆なタイトルだなぁ。誰が書いたのかなぁ」と 思って、読んだら、書いたのは自分だった。
しばらく前にオープンソースマガジンに書いた記事だった。 すっかり忘れてたよ。
後、sumimさんから指摘を受けてるけど、