松田さんから
まだ判断材料が揃っていない時点で「ソフトウェア特許が悪」と 結論付けるのは早計ではないでしょうか。
というツッコミをいただきました。まったくその通りですが、 私は別に「ソフトウェア特許が悪」であると考えてはいません。
現時点では、ソフトウェアに限らず「特許(現在の特許制度)は悪」かも、と疑っていますが、 結論づけるほどの材料を持っていないことは自覚しています。
ソフトウェア特許は悪だと結論づけているような書き方をしてました？
現時点で、「特許の利点」について私の納得できるような理由を見たことがないというのはあります。 あ、「特許の利点」というよりも「現在の特許制度の利点」と言った方が正確かな。
もともとの理念である
発明者には一定期間、一定の条件のもとに特許権という独占的な権利を与えて発明の保護を図る一方、その発明を公開して利用を図ることにより新しい技術を人類共通の財産としていく
というのは、まだ理解できないのでもないのですが、 現在の特許制度が「新しい技術を人類共通の財産」とするのに役立っているか、 というとかなり疑問だと思います。
もともとの理念を実現できるような特許制度であれば、私は反対はしないような気がします。
フリーソフトウェアに特許がじゃまなのは確かですが、 特許制度が「人類共通の財産」の形成に寄与する目的をきちんと果たすのであれば、 そのことによる一時的な制限は引き受けてもよいと思います。
この辺はストールマンとはちょっと違う点です。
HSP作者さんは言語を作りたかったんじゃないんじゃないかなぁ。
まったくその通りだと思う。私は言語屋なんで言語のことしか見てないけど、 実際は彼が作りたかったのは「プログラマブルなツールジェネレータ」くらいじゃないかと。
で、言語(の文法)にはあんまり興味がなかったんで、 慣れ親しんだN-BASIC(あれ、N88-BASICかな)に類似の文法を実現したと。
すべての人に、言語文法に対して愛を持て、と言うこと自体がムチャな要求なので、 それはそれで当然のことなのかもしれないが、 なんかあんまり考えられていない文法の言語が量産されるのは、見ていてつらい。 余計なお世話だけど。
とすると、こんなのはどうだろう。
「プログラマブル」という機能を提供する、言語ツールキットがあって、 プログラマブルなツールを提供したい人は、そのツールのAPIに従って 機能をドロップインすれば、あら不思議、プログラマブルツールの出来上がり、 というのは。
発想としては、Tclとか、Guileとかに似ていないこともない。 だが、これらでは十分ではない。言語ツールキットの要求仕様はこんな感じではないだろうか。
自然な文法
BASICのような古臭い文法でも、 Lisp(S式)のような「(優れているが)特殊な印象を与える」文法でもないものを。
優れたAPI
ツールに組み込むことを念頭に置いた使いやすいAPIを提供する。
優れた移植性
WindowsでもUnix系OSでも動作する移植性。 なに、どうせ移植性が問題になる部分は、 「ドロップイン機能」の方で実現されるのだから難しいことではない。
リファレンス実装
「これを使えば可能です」は十分ではない。 「このツールは使っています」ということを示せねばならない。
性能
まあ、そこらの言語と同等であれば十分だけど。
TclやGuileは「文法」の点で不利だ。Tclの文法(というか実行モデル)は、 ある意味古臭いし、GuileのS式はほとんどの人にはとっつきにくい。
同じターゲットを目指してそうなものとして、Luaもあるが、 これもパッとしない。tableというモデルがいけないのか、 それとも別の原因があるのか。
探してみると、他にもSmallとかいくつも類似のプロジェクトがあるな。 大成功しているものが見当たらないのは、既存のプロジェクトがなにか見落としているのか、 それとも、この種のアイディアにはなにか致命的な欠陥があるのか。
なお、Rubyはこの目的にはふさわしくない。
言語仕様
Rubyの「全部メソッド」というモデルは強すぎる。 通常の手続きも必要だろう。「全部オブジェクト」は問題ないと思う。
インタプリタ実装
Rubyインタプリタは組み込みのことを十分に考えて実装されていない。 この点についてはTclの方が100倍優れている。
ライセンス
独自ライセンスのRubyは組み込みに関して安心感がない。 実際には問題は発生しないと思うけど。 ここは制限の少ないBSD系のライセンスが良いと思う。
失敗。いろいろとタイミングが悪かった。非っ常に残念だ。 先方にも申し訳ないことをした。
次女が修学旅行に出発する。広島と岡山だそうだ。
一泊二日で二箇所も回るのは慌ただしいことだが、 私の小学校時代みたいに岡山だけというのもなんだかよくわからないことになる。 鷲羽山に登って瀬戸内海を眺めたことしか覚えてないぞ。
Eolas特許が有効認定されそう、とのこと。 あんまり良い動きじゃない。
ソフトウェア産業というものが事実上存在しない国々では、 オープンソース開発者はロックスターのように評価されるのでは、 という説。
ヨーロッパではそうなのかもしれない。日本ではそうでもなさそうだ。
「そうなればよい」と思ってるわけではないが。
最近は自分の机がある本社ではなく、 駅前の「オープンソースラボ」にいることが多いのだが、 今日は(珍しく)お客さんがあった。
プログラミングを学んでそっち方面の仕事に転職したい(CとPerlは読み書きできる)、 けど、まだ勉強が足りないような気がして、とのことだった。
正直、私自身はあまり勉強しようとしてプログラミングを学んだことはないので、 そういうニーズにどう答えたもんだか、と思う。 私は別にそれを仕事にしようとしたわけではなく、 プログラミングそのものが面白いことだと思って、 それを実行してきただけだ。
プログラミング入門書とか見るとなんかすごい違和感があるのはその辺かもしれない。 「プログラミングを学ぶ」ということへの動機づけがよく分からないからだろうか。 「それを仕事にしたいから、採用されるだけのスキルを身につける」というのが 動機なのか。うーむ。
とりあえず、
とアドバイスしておいた。
もしかして、これって「オープンソースラボ」開設以来、 もっとも設立目的にかなった時間だったんではないだろうか。
大新聞社の記者の方がわざわざ島根までいらっしゃって 取材してくださる。Rubyやらオープンソースやら物作りやらをテーマに ３時間も話し込んでしまった。大変、楽しい時間ではあったが、 それを限られた紙面で一般読者にどう伝えるか頭を抱えていらっしゃった。
その辺が新聞記者のつらいところである、たぶん。
「IT化」というのは経営(判断)の自動化でもあるので、 あくまでも「経営の具体化」であって、 あたかも機械を導入するかのように「投資」するという考え方は間違っている、 という話。
確かに、経営陣の持つ「道具を導入する」というイメージと 実際の「仕事そのものを計算機が実行できる程度に明確化・具体化・自動化する」という プロセスとのギャップによって多くの「IT化プロジェクト」の「悲劇」が生まれているような 気がする。
できれば、そういう分野からは離れてくらしたいなあ。 あくまで道具の開発で終始できれば、それはそれで幸せかも。
企業によって支援される「コマーシャルオープンソース」というのは 実際にアリだと思うし、今後ますます重要になっていくとは思う。 私自身もオープンソース企業に雇用されている身だ。否定できるはずもない。
が、だからといってそうでないものを「草の根」と呼んだり、 「コマーシャルオープソースに..草の根オープンソースは太刀打ちできない」 というような捉え方には賛成できない。
リンク先エントリの内容には、 「お金が全て」のような気持ちが透けてみえるし、 従来のビジネスモデルに慣れきった人々からのウケは良くても、 多くの開発者が情熱を傾けている本質への理解が感じられない。 それなしには、たとえ「コマーシャルオープンソース」でも 成立するのは難しいだろう本質なのに。
『ソース公開しているのは(あくまでも)「チラリズム」である』というのは、 オジサンにも理解しやすいオープンソース論だが、 その程度のオープンソース論で、本当にオープンソースビジネスをやっていけるんだろうかと 人ごとながら心配になる。
まあ、この人はSugarCRMの日本代理店の中の人ということなので、 自分とこの商品がオープンソースだろうがなんだろうが、海外から持ってきた ソフトウェア商材を売るというビジネスモデルには変わりない(から、オープンソースの「本質」とか関係ない)ってことなのかもしれない。
Googleはそのパワーの源泉でもあるGoogle File Systemのソースコードを公開していない。 まあ、ある意味しょうがないとは思うのだが、なんだか残念な気もする。
と思っていたところへKosmixがGFS相当のグローバルファイルシステム KFSを公開したとうニュース。
すぐに使えるかどうかはともかく、注目していくべき技術であろう。
出た。紹介が遅くなった(このエントリを書いたのは2007-10-16)。 タイミングずれすぎ。
今回の言語探訪のテーマはProlog。 そろそろネタ切れ感が。
一年ぶりの更新か。「年刊Matzにっき」だな。
今年もニューオーリンズで開催されたRubyConf。同じ都市で二度開催は初めて。
で、しょっぱなが私のキーノート。
まあ、あんまり語ることはないので。スライドを見てもらおうか。
こんな感じ。
角谷さんオススメのspeakerdeck.comも使ってみた。