やはり複数の環境で動作確認しないと故障と断言してはいかんだろう、と思い、 本当に久しぶりにWindowsをブートしてみた。何ヶ月ぶりだろう。
すると動くではないか、なんと、悪いのはドライバであったか。
じゃあ、カーネルをupgradeしたときにドライバにバグが混入したのだろうな、 しかたないなあ、と思って普段の環境に戻したのだが、なんと
動くではないか
こういうリセットすれば動くとかいう「マジック」な対応は好きじゃないんだが。 「コンピュータの機嫌が悪くなったのでリセット」ではまるで素人ではないか。
ところで、久しぶりに使ったWindowsはやっぱり使いにくいOSであった。 どうも私とは相性が悪いみたい。慣れてないってことだとは思うんだけど。
PHPについて書いたら、いくつか反応をいただけた。ありがたい。
トラックバックしていただいたishinaoさんのものが 一番詳細のようだ。
まとめるとPHPの良い点というのは
というあたりだろうか。(1),(2)あたりはRubyでもeRubyやDBI/Rubyで対応できているのだが、 標準というところが大きいのだろうか。Rubyも1.8.1あたりではDBI/Rubyを標準添付にしようか。
ところで、「オブジェクト指向でないから」という意見をいただいたが、 これは理解できない。理解できないだけで否定するわけではないが。
PHPにもオブジェクト指向機能があることを考えると、 この意見の意味は「純粋オブジェクト指向言語でないから」という意味だと思うのだが、 私自身はその方が良いと思ったことは一度もない(まあ、Rubyの作者としては当たり前なんだけど)。 世の中にはそうでない方が良いと感じる人もいるらしいことは前から知っているけれども、 それがなぜなのかはまだ知らない。実に興味深い。
ところで、世の中のプログラミング言語には
がある。Perl、PHPやC++は最初のもののような気がする。 「よく使われる」ってところが重要で、これがないと「消え行く言語」になってしまう。 2番目の典型例はLispかな。 RubyやPythonは3番目かなあ。 言語のどのような特徴がこれらを引き起こしているかも今後ぜひ考察していきたい。
追記: Pythonはちょっと2番目入ってるかも。 そういえば、OSCONのDave ThomasのRuby in a Dayチュートリアルの最中にGuido van Rossumが登場して、
Rubyコミュニティの連中はPythonについて誤解を広めている
と文句したそうだ。心当たりはないんだけど。でも、その場に居合わせたかったなあ。 どう考えても、見ものだったはず。
「頻繁に使われるからこそ欠点も見えてくる」 というのはもっともで、その辺を意識して
「よく使われる」ってところが重要
って書いたわけです。だから私は「悪口しか聞かない割によく使われる」とは思ってません。
しかし、
などには興味があります。
タイムリーなタイトル。が、内容はそうでもない。
この記事を書いたMary E. Tyler女史(たぶんね)は、
では、自分のプロジェクトに最も適したオープンソース・ライセンスを選ぶにはどうすればよいだろう。
と期待させておいて、OSIの顧問弁護士であるLawrence Rosen氏にインタビューする。
彼の最終的な答えはこうだ。
「多数の企業に多数のライセンスがあるので、それぞれの違いと、自社製品にどう適用されるかをよく考える必要がありますね」と、Rosenは注意を促す。「フリーサイズの万能ソリューションはありません」
ま、確かにそうだわな。どのライセンスも利点・欠点があり、 全ての人のニーズを満たすライセンスはなさそうだ。 というか、さすが弁護士のセンセイ、言うことにソツがない。失言の多い私は見習わなくっちゃな。
ライセンスの選択にあたって、私の経験から言えるのは以下のようなことだ。
独自ライセンスを避ける
私はRubyに対してGPLと独自ライセンスのデュアルライセンスを選択したが、これは間違いであった。 ライセンスの条文を考えるのはプログラミングに類似した側面があるので楽しいのだが、 実利的に考えると独自のライセンスには問題が多い。
ライセンスに穴がないことを示しにくい。
いろいろな人によって検討されているライセンスなら存在しないであろう穴が、 独自ライセンスには残っている可能性が高い。
読む人が結局何ができて何ができないのか判断にしにくい
たとえばBSDならなにができる、GPLならなにが禁止されるのかは ちょっと調べれば(厳密ではなくても)だいたい分かるし、 相談する相手もそれなりに見つかるだろう。 だが、ユーザは独自ライセンスだとその辺に確信がもてずに、 直接訪ねることになるだろう。ライセンスに関する質問が世界中から来るのはうっとうしい。
同様の理由から、独自ではなくてもあまり知られていないライセンスを選ぶのはお薦めしがたい。
ライセンスの変更は大変
全てのコードの著作権を一人で所有している時にはライセンスの変更はなんでもない。
しかし、プロジェクトが進んで送られてきたパッチを取り込んだり、 メンテナが複数になったりすると、厳密には全員の承諾をとらないとライセンスの変更はできないことになる。 ライセンスの変更を行う可能性がある場合には、 貢献する人ときちんと合意を取っていないと面倒なことが起きないと言う保証はない。 そういう問題を避けるため、FSF、MySQL ABなどの組織・企業は コードを貢献する人から必ず承諾を取っている。
GPLを「再利用されるコード」に適用するのは慎重に
先日、「迷ったらGPL」と言ったのは私だが、 再利用されることを目的としたコードにはGPLは向かないことを指摘しなかったのは手落ちだ。
この記事にもあるように、 GPLの「派生物」の定義はちょっと広い(ほとんどの人のセンスでは広すぎる)ので、 再利用されることを目的としたコード(要するにライブラリ)がGPLであると、 利用したコードにもGPL互換のライセンスを適用せざるをえない。
世の中には自分のソフトウェアにGPLを適用することを嫌う人も多いし、 あるいはさまざまな事情によりGPL互換ライセンスを使えない人もいる。 再利用されることを目的とするコードは使ってもらってナンボだと思うので、 結果的に間口を狭めるGPLよりは違うライセンスを採用した方が望ましいと思う。 BSDライセンスとか、MITライセンスとか、LGPLとか。
もっとも、「GPLの布教」のためにあえてライブラリにGPLを適用する人もいると思う。 私にはそういう人を止める権利も手段もない。
一方、スタンドアローンのプログラムでは、利用そのものはオープンソースライセンスでは制限されないので、 この件については心配する必要はない。
自分の立ち位置に近いライセンスを
ライブラリでなくてもコードの融通は発生するものだ。 あっちのソースを見たり、こっちのソースからコピーしたりする行為が自由にできるのが理想的だ。 そういう意味では自分が所属するコミュニティや参考にしたいプロジェクトなどが選んだライセンスと 揃えておく方が実利的だろう。 Javaな人たちにはApacheライセンス、BSDハッカーにはBSDライセンスということになろうか。
とりあえずそういうものが思いつかない人(先日の「迷ったら〜」の対象者)は、 GPLソフトウェアの蓄積が大きい*1ので、 GPLを選んどくとよいんじゃないかな。
私個人の考えでは、特に企業が自社ソフトウェアをオープンソース化する場合にはGPLが向いていると思う、 特に他の理由がなければ。 RMSの本意とは違うかもしれないが、GPLを使えば競合他社を牽制することができるし、 MySQL ABやTrolltechのようにライセンスを使い分けるビジネスもありえるし。
あと、法的な確信が得たい人は、どうぞ弁護士に相談してくださいませ。
*1 以前受けた忠告に従いfreshmeat.netで調べると18433プロジェクト、一方、BSDはオリジナル、修正版を合わせて1995プロジェクト
4822221059
午前中、島根県立図書館に行こうと思い立つ。 冷房は効いてるし、本はたくさんあるし、駐車場はタダだし。 しかも無線LANまで使える。
で、何冊か見付けた本の中の一冊が 『4822221059』。 著者はIBMのオープンソースエバンジェリスト。 2003年の本だからあまり新しいとはいえないけれど、 まあ面白い内容であった。
この中で、私と意見が違うなと思ったところがあった。ライセンスの選び方として、
と解説されている(p.233)。これは最近の私の考えとはまるっきり反対方向だ。
私の今の考えでは
ソフトウェア無料を目指すならGPL
「無料」はオープンソースにとっても、フリーソフトウェアにとっても重要な目的ではなく、 目指すものでもない。そんなものを目指す人がいるのかかなり怪しいが、 もしいたとしてもGPLでもなんでも好きなライセンスを選べば良いと思う。 OSI準拠の方が良いと思うけど。
商用ソフトウェアの価値を上げるならBSD的ライセンス
「GPLは無料で自由であけっぴろげの世界を目指すライセンスなので、こういった目的には使えない」そうだが、この時点でGPLに対してなにか勘違いがあるような気がしないでもない。 MySQL ABやTrolltechのやってることはオープンソースで商用ソフトウェアの価値を上げることだと思うのだが、どちらもGPLだ。
もっとも、リンクして使ってもらってナンボのライブラリとかプラグインとかは BSD的ライセンスの方が向いている、というのはあると思う。
ソフトウェアの維持をコミュニティ化するなら、非GPL
「(自社開発のソフトウェアにGPLを適用すると)二度と自社の商用ソフトウェアの内部に転用できなくなることを覚悟する必要がある。ソースコードをGPLにするとはそういうことだ」とある。これは完全に勘違い。 GPLを適用しようがなんだろうが、自分のコードをどうするかは著作権者の自由。 コントリビュートされたコードの扱いについてだけは注意する必要があるが。
自社でライセンスを作るのもあり
2003年ころはまだのどかだったんだろうか。たった2年前なんだが。 これはお薦めしない。絶対に。
独自のライセンスは他のライセンスとの組み合わせの適否判断が困難である。 結局、使い勝手が下がってしまう。 ライセンスという非技術的理由で使えるものが使えなくなってしまうのはもったいない。
ま、そんな感じで。
追記:
読んでいるうちに気になる表現が見付かった(p.62)。
フリーソフトの語源は「フリー」な「ソフトウェア」という言葉である。 「フリー(free)」という言葉には「無料の」という意味と 「自由だ」の両方の意味があるが、 日本では基本的に「無料の」という意味だけが適用されていると思われる。
<中略>
ところがフリーソフトを初期から始めた人たちのなかには、 「フリー」を「自由な」という意味で始めた人たちもいた。 GNUの創始者であるリチャード・ストールマン氏は....(略)。
それはともかく、 日本ではフリー・ソフトウェア、あるいはフリーソフトという言葉は 無料のソフトウェアということで ここでは話を進めたいと思う。
うーん、ストールマンが怒り狂いそうなことをさらっと書いてるなあ。 「自由なソフトウェア」を無視してる(知らない)わけじゃないのに、 わざわざ「無料のソフトウェア」扱いしてるし。
書かれた時点では分からないけど、2005年時点でお薦めできるような内容ではなさそうだ。 この機会に他のオープンソース本も見てみるかなあ。
今度の『るびま』の連載で解説する予定なんだけど、 私の言語設計はCLU(より正確には久野さんのbitでのCLUの解説記事)から大きく影響を受けている。 その原則のひとつが、「ローカル変数のシャドーイングを許さない」である。
スコープのネストによって変数の意味が変化するのは悪である、という原則なのだが、 他の原則とは違って、これには「ちょっと混乱を招く可能性がある」というわずかな悪影響しかないわりに、 カット＆ペーストによって名称が重複した時に変数名の書き換えが強制されるというデメリットがある。 自発的に書き換えるならともかく、処理系に強制されると腹が立つ。
いろいろ考えたのだが、この原則は破棄した方が良さそうだ。 ただ、良い面もあるので、-vオプションを付けたと来に警告くらいはしても良さそうだけど。 将来、警告にレベルを追加したらかなり高いレベルで初めて警告されるようにする程度だと思う。
HikiをCVS版最新にアップデートしたらhiki-mode.elが動かなくなった。 どうも、link URLが変化してしまったせいでhiki-fetch-indexが無限ループするようだ。で、 hiki-fetch-indexの正規表現を以下のように変更した。
"<a href=\"[^?]*\\?\\([^\"]*\\)\">\\([^<]*\\)</a>: \\([^<]*\\)</li>"
要するに「?までスキップ」する正規表現にしたわけ、ついでにre-search-forwardもwhileの条件に加えることと、ifで行っていた「?」のスキップが不要になったので、こんな感じ。
(while (and (equal (char-after) ?<)
(re-search-forward "<a href=\"[^?]*\\?\\([^\"]*\\)\">\\([^<]*\\)</a>: \\([^<]*\\)</li>" nil t nil))
(setq indexes
(cons
(list i (hiki-http-url-unhexify-string (if (= (length (match-string 1)) 0)
"FrontPage"
(match-string 1))
hiki-coding-system)
うちに帰ったら、子供が一人増えてた。
いや、姪っ子が泊まりにきていたのだが、一瞬びっくりした。
「これで大家族だね」とか「いや、大家族にはあとふたりは欲しい」などと勝手なことを言う子供たち。
When a piece of technology polarizes programmers, it means something very important and dear to our programming heart is involved that we take sides. If programmers neither love nor hate a technology, it means the technology is mediocre.
優れたテクノロジーはプログラマの心を刺激する。 プログラマから愛されも嫌われもしないテクノロジーは凡庸なものだ
ということで、紹介されているRailsに反対する意見。
反対意見とは良いものである。
そのような意見が出るということそのものがRailsが「重要なテクノロジー」とみなされている証拠なのであろう。Rubyはどうなのかなあ。
こんどはポジティブな意見。「10 reasons why (〜する10の理由)」ってのは よくあるパターンではあるが、まあ、よくまとめてある。
また、公平のためかcons(デメリット)についても4項目紹介してある。
募集開始されましたよ。もうそんな季節なんだねえ。
今年は東海岸で精神的距離が遠いけど、 今年も出席しようという強者はいるかな。 規模とかの話はまだ聞いてないけど、 昨年(350強)よりは多いんじゃないかな。
あんまり大きくなってもらっても、しんどいけど。
今年のキーノートはLL魂のLanguage Updateフルスケール版、 というのはどうだろうか。＞ ささだくん
調査機関Ｇの結果によると
で、PHPダントツである、という話。 もっともPHPプログラムはindex.phpというファイルを使う傾向があり、 それがカウントされている可能性があるので公平ではないのではないか、との指摘あり。
フレームワークでは
で、極端な差はないものの、Ruby on Railsの勝利。
もうPython 3000が近いということで登場したGuidoからのFAQ。 Python 3000の冒険度合が下がってしまった今となっては、 (野次馬的視点からは)あんまり面白くはない。
lambdaやmapやfilterは残るのにreduceはなくなるのね。
システムの規模が大きくなるにつれて、 Rubyによって向上する生産性よりも、低下する保守性の方が問題になるのではないか、 という話。
私自身はそのような規模のソフトウェアを開発したことがないのでなんとも言えない。
が、周りから聞くことから推測するに、ある程度以上の規模のソフトウェアを開発することは それがどんなツールであっても大変である。ので、
のいずれか、または両方が必要なのではないだろうか。 また、そのような対策が十分たてられない状態では、 静的型はある程度有効だろうが、真に信頼性の高い、複雑なシステムを作るための (カバレージの高いテストを含む)プロセスがあるのであれば、 動的型の問題は顕在しないのではないだろうか。
しかし、「それは理想だ」ということなんだろうか。