GNU EmacsとXEmacsは、しばしば懸念されるものの めったに起きることはないフリーソフトウェアプロジェクトのfork例。 ライセンス上、フリーソフトウェアプロジェクトのforkを強制的に止めることはできないが 協力した方が得、という話。
とはいうものの、この話の流れを読んでみるに、 forkの原因は技術的な要素よりも、 結局は人間関係とコミュニケーションが鍵であることと、 (本人は意図していないだろうけど)RMSのコミュニケーション能力は あまりほめられたものでなかろうことが読み取れる。
どこでも人間関係と言うのは難しいものだ。
はてなの伊藤さんのインタビュー。
オープンソースのコミュニティにコミットする人の中には、会社で充実した仕事ができなくてその反発からやってるという人も少なくありません。会社の中でくすぶっている人が外に出て道が開けるケースもあり、それは肯定されるべきだと思います。しかし、経営者の自分としてはそういうふうにエンジニアに思わせてしまうことが経営として失敗なので、肯定はしちゃいけないんですね。
「くすぶらせちゃいけない」というのはその通りだろう。 個人的には「積極的に外に出させる」というのをやりたい。 できてないんだけど。
NetBeansは進化中、という話。
ここで紹介されているスクリーンショットでは、
ができるようになっている。もう、「IDEがないから」という言い訳は 聞かなくてもすむのかもしれない。
Railsのおかげ(？)で、Rubyの代名詞という感じになったOpen Classだが、 ちょっと工夫すれば(annotationを使って)実現できる、という話。
Pythonのannotationってばなんでもできるよね。 おもしろいメタプログラミング機能だと思う。
それはそれとして、コメント欄では「たとえ可能でもしてはならない」というコメントが目立つ。 やはりOpen ClassはPython主義者(の多く)には耐えられないのかしら。
個人的には、この辺は言語で制限するのではなく、 「自分が何をしてるか分かってないと危険」ということだけ示して 許可したいのだけど。
PHP on Railsは不可能という話。
ActiveRecordをActiveRecordたらしめているものは、 リフレクション機能であり、それはPHPには欠けているから。 Javaにはリフレクション機能はあるんだけど、 言語的に硬いからなあ。結局はXMLなりGroovyなりを経由して 柔らかくするしかないのではないだろうか。
それはPHPでも同じか。複数言語を取り混ぜればよいという話になる。
というところで、タイムリーなMartin Fowlerの記事。
現在フレームワークを選んでいるのと同じように、何ができるかによって言語を選ぶような人たちのプロジェクトでは、複数の言語を見ることになるだろう。
そうなるかもしれない。しかし、その時、選択基準になる「何ができるか」とは「何」か。
LispでもRubyでもいい、十分に高度な抽象化能力を扱える言語であれば、 どの分野であっても、その言語の上にそれなりに有効なDSLを構築することができるはずだ。 となると、選択基準は実は「what」ではないだろう。
私の思いつくものは、以下の二つだ。
となると、JRubyやIronRuby(or Ruby.NET)のような相互運用性のある環境が より魅力的になるのかもしれない。 C言語とC Rubyはずっと以前からそういう関係を築いてきてるわけだけど。
デジカメでピンホールという発想はなかった。脱帽だ。