月に一度の岡山での会議。昨日帰国して、今日岡山まで運転はきついなあと思ってたら乗せてくれる人あり。 助かった。
すいません、会議中、うとうとしてました。時差ぼけ...というのは単なる言い訳で、 私ったらどこでも寝ちゃう人なんです。真面目な会議だったのに。
10日のプレゼン後、 何人もの人から「Sapir-Whorfの仮説を知ってるか」と聞かれた。 私の話がその仮説にそったものだったかららしい。
「Sapir-Whorfの仮説」とは
Language shapes the way we think, and determines what we can think about.
というようなものらしい。 最初に議論されたのが1929年ということだから、実はずいぶん古い仮説だ。
「言語が思考を規定する」というのは私の好きな言葉であるし、実際にそう思っているので、 私自身はこの仮説は真実であると信じているのだが、今回教えてもらうまでは この仮説について全く知らなかった。
ただ、この仮説に基づいて書かれたSFである『4150102481』は、 高校時代に読んで私に深い影響を与えた本である。この本を読んで言語を好きになったのか、 言語が好きだったからこの本を読んだのかははっきり覚えていないけど。 たぶん、言語好きの方が先だったんじゃないかと思う。
で、どうやら私は、この本の印象と自分自身の経験から仮説を再発明したらしい。 車輪の再発明は私の得意技ではあるのだが、またやってしまった。
禁止したいForkの一例はMSのJavaとか。
MS JVMを選んだユーザの気持ちとしてはForkかどうかはどうでもよくて、「 互換かどうか」だけが重要だったのではないでしょうか。 そして、「非互換な互換品」MSJVMはSunとしては嬉しくなかったでしょうし、 できるものなら禁止したかったでしょう。 で、たまたまライセンス上可能だったから禁止したと。
でも、同じことはIntel x86プロセッサにも言えませんか。 IntelはAMD(あるいはTransmeta)の「互換品」は禁止したかったんじゃないかと思います。 けど、できなかった。
想像力は大切。ありすぎるのも困るけど、
ええ、困ってます。 ですから、貧しい私に想像力を適用した結果を具体的に示してくださると助かります。
Mr.orz(「Mr.」と「さん」を同時につけるのは変ですよね)
この点、わたくしは、「ＧＰＬというのはヌケの多い隙だらけの契約」と読んでます
この点、私は「GPLは契約ではない。著作権行使方法の宣言である」と読んでます。 日本でもアメリカでも誰からも文句が出ない形でGPLを契約として成立させるのは無理があるような気がします。 そういう意味では「契約としてヌケ」があっても障害ではないと思っています。
言語処理とかTEXのようなフォーマット言語だと、ユーザからすると「一度書 いた資産が将来もそのまま使えるか」がとでも重要（企業にとっては、市場 規模を決めるファクタ）。しかも、「version-upによって過去の資産が使え なくなってしまった」というのは「私が明日バスに轢かれる可能性」よりは るかに高いものであって、経営上きちんと予測して対処すべき責任（予測し て対策を練らなければ重過失）と考えます。
まだ分かりません。ソフトウェアは自発的には進化しないので、 ここでの「過去の資産が使えなくなる」ような「version-up」とは誰かが行うものなのですよね。 原著作者が行うのであれば、たとえ互換性がなくてもそれは自分の責任であり、 それは少なくとも原著者にとっては「合理的な非互換」であったと考えます。
他者が行うのであれば、
原著者にできるのは、 a)どのような改変が誰によって行われたかを明示すること、 b)再配布を行う時には、修正したものもオープンソースとして開示すること、 を要求することなどであり、それはLPPL 1.3でも、GPLでも可能である、 と思います。LPPL1.3では第６項と第１０項がそれを述 べており、GPL2では第２項がそれに当たると思います。
メンテナの交代が明示されているぶん、LPPLの方がこの点ではわかりやすいとは思いますが、 GPLだから重大の問題が発生する(企業責任が問われる)ほどのことはないと思います。
むしろ、LPPLが(まだ)「OSI認証」でないことによる、 「本当にオープンソースと呼んでもよいの、問題はないの」という不安、 GPLコンパチかどうか(まだ)確認されていないことによる、 「GPLソフトウェアとリンクしてもよいのか」という不安(特に後者)があるので、 私だったら現時点ではLPPL 1.3は薦めません。
ところで、GPLのヌケである「ソースとバイナリの価格づけの関係」というのは、 第１項の
You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.
という部分でしょうか。 配布方法として磁気テープが一般的であった時代を感じさせる表現ではありますが、 「ヌケ」とまでは思いませんでした。
GPLが現在の状況に合わない点がまったくないとは断言できません。 おそらくはいくつもあることでしょう。 しかし、運用上問題があるほど合わない点にはまだ気がついていません。 ご教示いただけるとさいわいです。
時代に合わないと言えば、刑法なんかも成立が古いだけに変な表現が残ってますよね。
オリジネータの著作権法的な地位をGPLよりは一歩あげ、オリジネータはすべての改変情報を知ることができる、（改変は自由であるものの）正式な改変であるか否かはオリジネータが決定できる、という点で、forkに対するユーザの懸念とオープンソースにより享受できる利益は両立できると考えます。
具体的にどのようなライセンスを考えていらっしゃるのか分かりませんが、 GPLでも上にあげたa)とb)の要求があるので、 全ての改変情報を知ることは可能で、それらの変更を取り込むことも可能だと思います。
わざわざGPLよりも「地位をあげる」ということは、原著作者になにか新しい権利を付与したいのでしょうか。 強すぎる権利は全体の自由を減らすのではないかと懸念しますが、 これはまた別の機会に話しましょう。
個人的には、forkは仕方ないことだし、起こり得ることで、その可能性をことさら恐れるに足らないほど低いと言う必要は無いと思います。開発者中心の世界ではむしろ適度な競争になって良いことでもあるでしょう。ただ、企業の方針としてフォークを避けたいと考えることも妥当ですし、それに対する説得力のある反論は、「フォークは滅多に起こらない」ではなく、「フォークしてもメリットがありますよ」の線なんじゃないかとの印象を持ちました。
私の言いたかったことは「互換品の登場は禁止できない」でしたが、 「フォークは滅多に起こらない」って言ってますね、確かに。
フォークのメリットと言えば「フォークが起きても競争が促進されるのでメリットがある」というところでしょうか。 特にオープンソースの場合、改良の融通ができるのでより速い速度の進歩が可能ですし。
フラッシュ頻度を下げたら一晩で終わっていたよ。 900MBのメールのインデックスが1GBってのは多いのか少ないのか。 インデックスのサイズが大きくなったら、動きの機敏さがどうなるかと心配したけど、 全然問題なし。
Estraierの名誉のために言うと、以前のmorqで検索が遅かったのは、 私の書いたEstraierのインデックスを読み込むライブラリが遅かったせいで Estraierのせいではない、念のため。
前にも書いたように、Rast対応になったmorqは快適に動くのだが、 あまりにもたくさんの候補が出るとさすがに遅い。そこで、query文字列に
という拡張を行った。
打ち合わせ。仕事が入りそう。
ただ、Linuxをプラットフォームにしているとは言え、 我が社としては全然経験のない分野であるのがちょっと不安。 また、仕事の結果がオープンソースに反映される可能性もなさそうなのもちょっと残念。
しかし、それなりの額で恒常的な仕事になりそうなので、 経営的には大変ありがたい。タイミング的にはちょうどいいといえばちょうどいいのだが。
しかし、明日の集中講義だが、登録が90人もいるというのはどういうこと？
もっとこじんまりとした感じだと思ってたのに。 グループ分けして活動しようとか思ってたけど、無理かなあ。
しかも、情報以外にも、人文とか自然とか芸術とか医学とかの人が登録してるんですけど。 与しやすいと思われたか。
ほぼ一年ぶりの筑波。なつかしー。
というわけで、1日目は昨年とほぼ同じ内容の講義。 10時から12時、1時半から4時くらいまで。 実に合計4時間半か。よくもそんなにしゃべったものだ。
で、少々時間があまったので、 先日のキルギスのスライドから「5 principles of Usability」の話もする。 これだけ話しててRubyのコードが登場したのはここだけだという。
スライドはこちら。 まあ、4時間半の内容をこれだけで表現できるわけではないが。
「人工知能(artificial intelligence)」という言葉が彼の造語とは知らなかった。 もうちょっと数学よりの人かと思ってた。
いつの間にか日経ソフトウェアから日経エレクトロニクスへ異動した 大森さんによるErlangの紹介。しかし、いまだに心の中で「えるらんぐ」と発音しちゃうな。 正解は「あーらん」です。
さて、この記事には事実とやや異なる点がいくつかある。その辺を指摘しておこう。
まず、一番気になる点はタイトルから。「組み込みから生まれた」とあるが これは私の知る限りでは事実に反する。
Erlangは，1987年ごろにスウェーデンのEricssonで開発されました。元々は，信頼性が要求される通信機器のために設計された組み込み用のプログラミング言語です。
確かにErlangは「1987年ごろにスウェーデンのEricssonで開発」されており、 「信頼性が要求される通信機器のために設計された」が、 その通信機器とは電話交換機である。 電話交換機はそれはそれで面白い領域ではあるのだが(CHILLのような専用言語もある)、 しかし、一般的には「組み込み」とは言わない分野だと思う。
もうひとつは、私がこの言語に感じている思いについて。
まつもと氏は今でもErlangがお気に入りらしく，今年4月には自身のWeb日記で，「次」に来る言語の候補としてErlangの名前を挙げています
もちろん、私がErlangに注目しているのは事実で、 私を経由してはじめてErlangを知った人も多いだろうとは思う。 また、「次の言語」の候補として名前を挙げたこともある。
しかし、Erlangは最初から私の「お気に入り」の言語ではない。 たとえばLispがそうであるようには。 Erlangと比較するならばPythonでさえ、私のお気に入り言語と呼んでもよいと思う。
では、私はErlangの何に注目して、何が気に入らないのか。
注目しているのは、もちろん、アクターモデル(プロセスモデルと呼んでもπ計算モデルと呼んでもよいのかもしれない)による、高生産性並列プログラミングである。
たいたいにおいて並列プログラミングは難しいのだが、 Erlangにおいては、他言語のオブジェクトと同程度に軽量な「プロセス」と、 それらの間のメッセージ通信モデルにより、比較的簡単かつ高生産性で 並列プログラミング可能である。
しかも、関数型言語として値がimmutableであるが故に 同期や排他制御のコストがない(または低い)ので、 コアの数が増えれば増えるほど性能が向上する点も見逃せない (ただし、Erlang言語処理系そのものが驚くほど速いわけではない、らしい)。
気に入らない点は3つ。
ひとつは文法。Erlangには文法に気を使わない人によって設計された言語の臭いがする。 慣れの問題かもしれないけど、正直、Erlangの文法はお世辞にもわかりやすいとはいえない。
もうひとつは計算モデル。個人的に関数型言語はどうにも相性が悪いのだが、 Erlangはさらに相性の悪い論理型言語(具体的にはProlog)の感触もある。 これもかなり慣れの問題で、気にならない人は気にならないだろう。
最後も非常に個人的なことなのだが、ソースコードが読みにくい。 「Erlangの秘密」を探ろうと思ってソースコードを眺めたのだが、 どこになにがあるのかさっぱりわからなかった。残念。 もっとも、他の人にとってはRubyのソースコードだって読みやすくないかもしれないわけで、 「お前に言われたくない」と思った人もいるかもしれない。
というわけで、正直な感想は「Erlangは注目すべき言語だが、おそらくは将来の他言語に影響を与える礎になるのではないか」である。
RubiniusのEvan Phoenixのインタビュー。
そうか、こんな風にしてるんだね。 まだRubiniusのソースコード読んでなかったよ。
しかし、これはこれで茨の道だと思うけど、 それをある程度動くところまで持っていったEvanの努力(と根気)は 大したものだと思う。
こんどはJRuby方面。
ある種のメソッドは予約語にしたい、という話。 以前、ささだくんも似たようなことを言ってたから気持ちはわかる。
ある種のメソッドとは
要するにコールフレームに属する情報を参照したり書き換えたりするメソッド。 たとえば、evalとかlocal_variablesとかがあがっている。
うーん、どうしよう。確かにそうするとコンパイル時にできることが増えて、 うれしい(特に実装者が)というのは理解できるけど、 予約語が増えるとろくなことはないし。悩ましい。
それにString#gsubとかIO#getsのような「普通の顔をしてるけど、 実は特殊なメソッド」をどうするのかとか考えると夜も眠れない。
で、最近は結構午前中に寝てたりする。
とりあえず、String#gsubについては、 ブロックにMatchDataを渡す新しいメソッドを用意するのはどうだろうか。 より使用を促すためString#sとか短い名前を付けるのが良さそう。
Rubyのためのリファクタリングツール。
実際に使ってはいないが、ドキュメントを読んだり スクリーンキャストを見たりする限りでは結構いろいろと リファクタリングを自動化できそう。
私自身はEmacsでバリバリと書いちゃって、 リファクタリングツールなんて使わないオールドタイプだけど、 それはそれとしてリファクタリングツールがあるのは良いことだ。
あー、こういう風なソフトウェア開発っていいなあ。
って、今でも好き勝手に開発してるんだから、 こういう風に開発できるようにすればいいのに。
そうか、私はチーム開発が圧倒的に苦手だから、 こういうスタイルの開発をまともにしたことがないのか。 それはそれで反省したり、いろいろ考えたりすべきことだろう。
でも、こういうのをTracよりももっと積極的に支援するツールって あったらうれしいんじゃないかな。それともTracで十分？