合同結婚記念日*1以来の近隣の兄弟が集まる。今回は年末からうちに来ている末の弟も参加。総勢13名。千葉にいる妹夫婦や浜松にいる両親も参加できるとよいのだが、そういう機会はもうちょっと先になるだろう。
子供が多いので大変な騒ぎになったのだが、楽しかった。 持ちよりの食べ物が予想以上に多くてお腹いっぱい。ごちそうさまでした。
途中、年齢差の話になって、
とかいろいろ飛び交って混乱する人が出てきた。人数が多いと大変だ。
*1 「合同(結婚記念日)」と構文解析する。間違っても「(合同結婚)記念日」ではない
弟を連れて松江の教会に。
「あけましておめでとう」のあいさつがあちこちで聞かれたり、 帰省で普段見かけない人がいたりする以外はごく普通の第一日曜日。
弟は思いがけない知り合いにであったようだ。 「いろいろな人にあっていろいろなことを考えていた」と言っていた。 若い彼にはいろいろ考えることがあるようだ。
年寄りの私は、Rubyのことと子育てのことくらいしか考えることはないなあ。 いや、純粋に仕事のこととか、オープンソースのことも時々は考えてるかな。
弟を連れて親戚のうちに。妹夫婦も来ていて大変な人数に。
陽気なおじさんと話し込んでいた。70代、80代の人々にとって、 戦前とか天皇制とか戦争とかは遠い話ではないことを実感した。 知らない話がたくさん聞けて興味深かった。
その後、米子へ。松江より米子の方が人口はよっぽど少ないのに買い物するところは多いのは不思議だ。 「本の学校」による。お世話になった書店(の支店)である。 本屋としての規模では最近うちの近所にできたセンター店(多和山店)に負けるが、 こっちの方が変わった本がたくさん置いている。
何冊か買い物した後、鳥取に帰る弟を米子駅まで送り届ける。
Python作者、Guido van Rossum自らPythonにオプショナルな静的型を導入することについて語る。 パート1。 パート2。
さすがはGuido、Python Type SIGでのさまざまな議論を反映しているとみえて、素晴らしいまとめである。 CLOS(とその派生系であるDylan)を別にするとまだ誰も成功していない 「動的言語における静的型」に必要な機能を不足なくカバーしているように見える。
これだけあれば、静的型言語として足りないものはなさそうだ。 Generic Typeなどは多くの静的型言語(例: C++, Java)の設計者も当初は見落としていた(しかし後にその重要性に気付いた)ものなので、きちんと押さえていることはポイントが高い。
私が一昨年のRuby Conferenceのスライドで「Optional Static Typing」とさらっと書いたものに対して、 より深く、より完全な考察を行ったものだと考えてよいだろう。さすがだ。
しかし、このようにGuidoがまとめてくれたものを眺めて、改めて考えると、 やっぱ将来Rubyに静的型は導入するのやめようと思った。 たとえオプショナルでも。
理由は以下の通り。
Guidoは
this is something that many people, especially folks writing frameworks or large applications, need
と書いているが、LispあるいはSmalltalkの実績は、必ずしも静的な型がなくても 大規模アプリケーションやフレームワークが構築できることを証明しているようにも思える。
というわけで、オプショナルな型システムは将来にわたってRubyに実装されることはないだろう。 もうちょっと簡易な(かつDuckTypingを意識した)型チェック機能の導入はありえるかもしれないが。
静的言語であるところのJavaと動的言語のPythonとの比較。 この論はPythonをRubyに置き換えてもだいたい成立する。
興味深いところを引用。
XML is not the answer. It is not even the question. To paraphrase Jamie Zawinski on regular expressions, "Some people, when confronted with a problem, think “I know, I’ll use XML.” Now they have two problems."
This is a different situation than in Java, because compared to Java code, XML is agile and flexible. Compared to Python code, XML is a boat anchor, a ball and chain. In Python, XML is something you use for interoperability, not your core functionality, because you simply don't need it for that. In Java, XML can be your savior because it lets you implement domain-specific languages and increase the flexibility of your application "without coding". In Java, avoiding coding is an advantage because coding means recompiling. But in Python, more often than not, code is easier to write than XML. And Python can process code much, much faster than your code can process XML. (Not only that, but you have to write the XML processing code, whereas Python itself is already written for you.)
実は今までどうしてJavaな人たちが(決してJavaと相性が良いわけでもない)XMLをあんなに使いたがるのか、 十分に理解していなかったのだが、これではっきりした気がする。 XMLはJavaよりもずっとagileでflexibleなので、 「Javaアプリケーションのスクリプティング」の標準的言語の地位を確立しているのだ。 なるほど、そういうことか。
そもそも独立したアプリケーションスクリプティング言語を必要としない PythonやRubyにどっぷりな人には理解できないことに違いない。 我々がXMLを必要とする局面は唯一「interoperability」だけだ。 それさえもXMLよりはYAMLの方がよっぽど適していると思うけど。
おととい米子に行ったのにもかかわらず再び米子訪問。 母校(米子東)のすぐそばを通ったが、遠目には学校はなにも変わっておらず、懐かしい気がした。 いくつかの場所で買い物。
Jakarta TapestryとHiveMindの作者であるHoward Lewisが、 Dave Thomasの強い勧めに従ってRubyを使ってみたら思ったより良くてびっくり、という話。
興味深いのは以下の点。
気になる速度については以下のように述べている。
My trembling first journey into Ruby is this script, which does the work. It's sloppy, doesn't report errors well, and took me too long to write (almost as long as it would have in Java!) ... but it works and is impressively fast. In fact, I've been very surprised at just how fast Ruby is to load, parse and execute. Visibly faster than Python ... faster than Java I'd bet.
「PythonよりもJavaよりも速い」んですか。それはめでたい。でも、なんでだろう？
ブラジル生まれのスクリプト言語Luaの歴史。
元々はデータエントリのための言語だったんだ。初耳。
うう、また変な特許が。ITmediaの記事が正しいとしたら、この特許は
USPTOの要約では、同特許は「共通のライブラリを使用する複数のソース言語のファイルをコンパイルする方法とシステム」と説明されている。
USPTOの要約には、「本発明はソース言語コンパイラ技術に関連しており、特に、ランタイム環境で実行される実行可能プログラムやアプリケーションの作成に使われるソース言語から独立したランタイムライブラリおよび環境を作成するためのコンパイラの使用に関連している」と記載されている。
なのだそうだ。これのどこに新規性が。
以前紹介した「Adding Optional Static Typing to Python」に関連してフレームウォーが発生しそうなので、Guidoが火消しに回った記事。整理するとともに、より現実的な案を提案している。
Argument and return type declarations
以前のエントリの通り。文法は
def foo(a: t1, b: t2) -> t3: ...body...
ただし、前回は紹介されなかった「意味」が定義されている。
def foo(x: t1, y: t2) -> t3:
...body...
is more or less equivalent to this:
def foo__(x, y): # original function
...body...
def foo(x, y): # wrapper function
x = adapt(x, t1)
y = adapt(y, t2)
r = foo__(x, y)
return adapt(r, t3)
全体にPEP-246(Object Adaptation)を採用している。
Attribute declarations (maybe)
型のついた属性。
class C:
x: t1
を以下のように解釈する。
x = typedAttribute(t1)
Interface declarations
interfaceを導入する新文法の提案。PEP-245(Python Interface Syntax)よりimplementsが要らないなど簡略化されている。
Design by contract (maybe)
function decoratorでpre, postを明示的に指定するというスタイルが目新しい。具体的にはこんな感じ。
def _pre_foo(self, a, b): # The pre-condition has the same signature as the function
assert a > 0
assert b > a
def _post_foo(self, rv, a, b): # The signature inserts the return value in front!
assert rv > b
@dbc(_pre_foo, _post_foo) # design-by-contract decorator
def foo(self, a, b):
return a+b型システムとしてはgeneric typeがなくなったりとかなり後退している。とはいえ、なんか、いきなり現実的になった感じ。Object Adaptationとかdbcとかは興味深いし、Rubyでも採用できそうな気がしないでもない。
先日のエントリが引き金になってできたページらしい。 静的解析によりRubyプログラムの型不整合を発見するツール、と考えたらよいのか。 これも面白そうな試み。 完璧は無理でもデバッグの助けにはなりそう。 どこまでチェックできるのか注目したい。
取引先との打ち合わせに参加。なにが出てくるか事前に予想できなかったので、同席したが、 実際には出番はなかった。これは、つまり、保険みたいなものか。「出番がなくてよかったね」と。
センセーショナルなタイトルだが、内容はあんまりない。要するに「特許ゴロ」のような企業がいくつもあり、それらを退治する根本的な方法は(まだ)ない、ということのような気がする。結局は現在の特許制度の限界と破綻の可能性を暗示しているということか。
Internet Watchより。
プログラミング言語の人気度を推測するために毎月ランキング情報を提供している「TIOBE Programming Community Index」が、「2004年のプログラミング言語」にPHPが選ばれたと発表した。この賞は、同インデックスにおけるレーティングの増加率が最も大きかった言語に与えられる。
だそうだ。おめでとうございます。
インターネットでしばしば使用されるスクリプト言語では、Perl（2.14％減）が6位、Python（1.72％増）が8位となっているほか、Rubyが29位に入っている。
と、とってつけたようにRubyが取り上げられているのが、嬉しいやら悲しいやら。
もっとも、このTIOBE Indexはかなりいいかげんな測定のようで、あんまり参考にはならないかもしれない。 ランキングを見ても、今日現在の1位であるCや、2位のJavaはともかく、「SAS(12位)」や「RPG(20位)」などは「違う単語が入ってるんじゃない？」って気になる。また、「ABAP(14位)」のような聞いたことのないものも含まれているな。
TIOBE IndexにおけるRubyのランキングについては、Premshree’s Personal Weblogのこのエントリが参考になる。なんか昨年後半に急激に下がっているような。
プログラミング言語に人の名前を付けるのは、ひところの流行だったわけだが*1、とうとう、Guido van Rossumの名前をとったものが登場。 名誉なことではないか。
その実体はロボットを操作する教育用言語(Python文法)だそうだ。
*1 だが、RubyはJack RubyやSam Rubyの名前を付けたわけではない
オープンソースの問題点として、
をあげ、それを解決することへのプロポーザル。 基本的には新しいコミュニティを意識した組織を作ることを考えているようなのだが、 それがうまくいくかどうかは、彼ら(amiculus.com)自身も自信がないようだ。
問題の把握は適切だ。が、それを解決するにはもう少し考察が必要な気がする。
Langsmithメーリングリストで発表された新言語。
ぶちあげたはいいが、なかなか議論が低調なlangsmithメーリングリストから、 最初に登場した言語として注目したい。なにより名前がいいな。絶対重複してそうだけど。
個人的な評価はとりあえず置いておいて、みなさんは、このAlanをどう思いましたか？
朝から雪。あっという間に道が真っ白になる。 米子道はそうとう積もっていて、 雪道をこわごわ岡山へ。
しかし、岡山県に入ってしばらくすると雪は消え、 岡山市内では雪なぞ影も形もない。 山陰と山陽の気候の違いを思い知らされた。
会議終了後、日が暮れて凍結しないうちにできるだけ進みたくて、少々急いで帰る。 山間に近づくにつれ、朝よりは量は減っているものの、それなりに雪が積もっている。
だが、息がスムーズだったので気がゆるんだのか、あるいは、急ぎ過ぎたのだろうか。 蒜山のあたりでスリップ。右サイドをガードレールに当ててしまい、 タイヤがグリップを失った。カウンターを当てようとしたが*1、コントロールし切れず、そのまま回転。 時計まわりに約300°ほど回転したところで止まった。
ガードレールに当ててしまったところは少しへこんでしまったが、 それ以上には車にも人にも被害はなかったのは、とてもとてもラッキーだったと思う。 命があってよかった。
でなければ、Rubyの開発が致命的に滞っていたことだろう。 もちろん家族も路頭に迷う。
車にまた大きな傷をつけてしまったのはショックだが、 ここは我慢しなくてはいかんのだろうな。
*1 素人がとっさにマンガのような運転ができるはずがない
InfernoのVM、Disの設計について。 まだ読んでいないのだが、聞くところによるとレジスタベースのVMらしい。 個人的にはParrotやDisのようなレジスタベースのVMには懐疑的なのだが、 JITを仮定すると高速化できるのかな。
一度まじめに勉強したいものだ。
DSL (Domain Specific Language) のデザインについて。 というか、言語デザイン一般に適用できる原則のような気がする。
たとえば以下のような「原則」が面白かった。
一読の価値あり。
でも、この内容、以前にも読んだことがあるよなあ。 あ、LL1メーリングリストのアーカイブか。引用だって、ちゃんと書いてあるじゃん。
Chad FowloerのBlogより。
ナイスなアイディアを持つRubyistを集めて、アイディアを磨き、実装してみるような集会を開くため、 RubyCentralがお金を出そう、という試み。
今まで、RubyGems、Ruby DNNS、scanf.rbなどがこのような集まりで誕生してきたが、このほど正式にそういう集まりを支援することになった。 RubyCentralは寄付控除の資格も得たし、 このような「正しいお金の使い方」をいろいろと検討している。
でも、日本からの旅費はちょっと難しいかもしれないなあ。
IBMによって、オープンソースソフトウェアを対象にする限り、特許を主張しないという宣言。
IBMによれば、Open Source Initiative（OSI）によるオープンソースソフトウェアに現在または将来適合する予定のソフトウェア開発に従事しているか、そのソフトウェアを使用しているいかなる個人、コミュニティー、企業にも適用されるとしている。この宣言によりIBMは、IT業界全体で「特許共有」を行う仕組みの基礎固めをしたい考えだ。
実際の宣伝文句とは異なり、実際に寄贈を行うわけではない。 もっとも、たとえほんとうに寄贈を行いたくても現状では「オープンソースを代表する団体」は存在せず、 受け皿がないわけだが。が、この動きをきっかけに そのような(先日のエントリのOpen Source Collectiveのような)受け皿を作り「特許共有」を行うことも現実的になってくる(可能性がゼロではないかもしれない(笑))。
とはいえ、やはり特許のようなものは、持たざるものがいくらあがいても、 持てるものであるIBMのわずかな動き(公開されたのはIBMが持っている膨大な特許のうちごく一部*1)にさえ、 かなわないというのは「世の中の仕組み」を見せつけられたような気がする。
しかし、OSI準拠(「予定」を含む)ソフトウェアだけが対象ということは、 この特許を使いたいためにオープンソース化するという動機を生む可能性があり、 オープンソース陣営としてはありがたい。
結論としては「IBMは対外活動が上手だなあ」というものだ。 オープンソース陣営に対してイメージ向上に非常に効果的な手を適切に打ってくる。
では、IBMで働きたくなるかというと、契約条件の関係で、とてもIBMでその気にはならないが。
いずれにせよ、企業体としてはそのような適切なアクションが取れる存在になりたいものだ。 うちの会社は決して上手とは言えないからな。
*1 IBM所有の特許の一部しか公開されなかったことについて文句はない。むしろ当然の判断だと思う
−−開発者の一部はSunに対し、Java仮想マシンの実装をオープンソース化するよう求めてきました。そうしなかった理由は？ Solarisをオープンソース化する理由は、Javaにも等しく当てはまるように思えるのですが。
マクニーリー氏 最初からJavaコミュニティープロセスが存在したから、というのが主な理由です。Java Community Process（JCP）には900を超える企業と組織が参加しています。そこにあるのはコミュニティー開発の問題だけではありません。オープンソース化がどんな問題を解決するのか、私には確信が持てないのです。オープンソース化により、どんな問題が解決されるのでしょうか？ われわれは実際にそれを見出そうとしています。われわれはJPCを調整、修正することに満足しています。今でも独力であらゆるJava技術をオープンソースあるいはプロプライエタリで実装することは可能です。認証プロセスもあります。オープンソース化で何が解決されるか、われわれは本当に確信がないのです。現時点で壊れていないものを修正するようなことはしたくありません。
えーと、Java言語仕様とSunのJVM実装の問題をわざと混同するのはいかがなものかと思うのだが。
Java言語の仕様を管理するJCPの存在は「SunによるJVM実装をオープンソースにしない理由」にはならない。 もちろんSunには「SunによるJVM実装をオープンソースにしない理由」があって当然だし、 オープンソース化する義務など微塵もないのだが、 それでもなお質問の答えにはなっていないような気がする。
がんばってください。
島大、縄手研の新年会。今年は最終年度なので(ええっ、もう？)、論文をどうするかとかいう話もする。
これまでのあらすじ(笑)
XMLは「Javaアプリケーションのスクリプト言語」としての地位を、知らぬ間に獲得しているようだ。 今やXMLは広く受け入れられている。 しかし、私にはXMLは「濫用」されているように思われる。
正直なところ、今さらあれこれ言ってもしかたがないとは自分でも思っているのだが、 やはり技術が不適切に利用されているように思える局面を見ると口出ししてしまうのだ。
しかし、さすがの私もXMLが全面的によくないと思っているわけではない。 元々の目的、つまりマークアップ言語としては十分な機能と仕様を持っていると思うし、 そういう目的に利用されているのを見て、どうこう言おうとは思わない。 自分ではきっと使わないだろうけど、それは別の話。
しかし、データ表現の手段としてのXMLには、いくつか欠点がある。 人によっては「どうでも良い」と思うだろうし、実際、そう思えるからこそXMLが選択されているのだろうが。
その欠点とは、まず第一に「冗長なこと」である。
私はXMLの冗長なところがいいのかな、と。冗長だから人間が誤るのを訂正してくれるわけです。
とあったが、私は全く同意しない。
ある人間が入力したXMLファイルに間違いがある。それは少しも珍しいことではない。 人間は誤るものだ。で、その誤りを検出する方法は、結局は以下のいずれかではないだろうか。
さて、重要なのはこのいずれもがXMLの冗長性、つまりSGML風の<xml>〜</xml>的タグに依存しないということである。ということは、このタグによる冗長性は単に無駄ということではないだろうか。 あのタグに利点があるとしたら、私に思いつくのは「テキストに埋没しない」ことだけであり、 つまりマークアップとして使う時にしか意味がない。
Paul Grahamを引用するならば「簡潔さは力」である。ということは、「冗長性は悪」である。 こと言語に関する限り。よって、XMLは優れた言語ではありえない。
「人間は書かない」、「人間は読まない」から、という反論を見たことがあるような気がするが、 「人間は書かない」、「人間は読まない」データならば別にXMLである必要はない。 ただ、現状ではライブラリが揃っているので安易な選択であることは認める。
もうひとつ、私には欠点に思える点は、XMLは型のない言語である点である。
古代には言語はタイプレスであった。アセンブラには整数しかない(最近のは浮動小数点数もあるけど)。 その数が、単なる整数なのか、アドレスなのか、あるいは文字を表現しているのかは、 コンテキストあるいはその数を処理するプログラムによって決まったものだ。
しかし、それは人間にとっては都合が悪いので、計算モデルとして型が導入された。 BCPLは「型なし」であったが、Cでは型が導入された、というように。
スクリプト言語の世界では、長らく型(と人間性)が軽視されてきたので、Awk(数と文字列に区別がない)、 Perl(静的型(スカラーとアレイとハッシュは静的に区別される)と型なし(スカラーには型の区別がない)のハイブリット)やTcl(根源的には全て文字列)のような「型なし言語」が生き残っていたが、それらすら、オブジェクト指向の導入などでなんらかの「型」を取り込んでいる。
このようにプログラミング言語の世界では、長い長い時間をかけて苦労して「型なし」を追放してきたのに、 ここでいきなりXMLが「型なし」を復活させてくれているのだ。なんてこった。 XMLはスキーマなしでは、どの属性が数値なのか、どのデータが文字列なのか区別することはできない。 できるのは「ノード」と「テキスト(文字列)」の区別だけだ。
もちろん、XML SchemaやらRELAXやらを導入すれば型の表現はできる。 しかし、「スキーマなしで操作できる」のがXMLの良さではなかったのか。 DOMでデータを取り出してきても、その(型の)解釈は個々のプログラムに任せられてしまう。 要するに、アプリケーションのロジックの中に分散して埋没してしまうということだ。
せめて、古典LispのS式程度(ノード、整数、浮動小数点数、文字列、シンボル)程度の型が、 スキーマなしで表現できれば、こんなことにはならなかったのに。これを濫用といわずして何を。
Sick (YAML for Ruby) の開発者としても知られるwhy the lucky stiffからメールが来た。
全文を引用する。
Hi, matz.
I recently started a Ruby blog which is growing quickly. Lots going on, lots to talk about. However, I'd really like to find a fresh voice from Japan to join in. I think many of us outside of Japan are dying to hear more about what is happening there. And I'm sure many Japanese Rubyists are struggling to get their work translated.
Since you are immersed in the Ruby scene, I'm wondering if you know anyone there who would like to blog in English. I'm looking for someone who can uncover neat software, translate important information from your blog, and perhaps even help us to understand some of the Japanese tech culture.
I think it could be a great opportunity for a Japanese blogger to be heard by an international audience and to make friends outside of Japan.
Thankyou so much, matz. My warmest good luck to you.
_why
要するに、
ということだ。だれか、挑戦する人はいないだろうか？ そんなにいっぱい書く必要もなければ、完璧な英語を使う必要もないと思う。 少々の勇気とちょっとの時間でけっこうなことがなしとげられそうに思うのだが。
いかがでしょう。希望者は私にメールするか、ツッコミで連絡を。
Webを眺めてたら、ふとしたことから前の会社でやってたプロジェクトの報告書に行き当たる。 懐かしい。
1997年に前の会社を辞めてるから、この報告書は私が辞めてから書かれたものだよな。 実はこのGPMEの一部にはRubyが組み込まれていたのだが、今となっては誰が知るだろうか。
というか、この時の成果っていったい今どうなってるんだろう。 全然使われていないような気がするんだけど。だとしたら、もったいない。オープンソースにしておけば。
RedHandedから。
このページを作ったArmin Roehrlは、自著である 「Programmieren mit Ruby」 (ISBN 3-89864-151-1)で、各章ごとにやたら面白い引用を付けていた(献本されたのを眺めてて、そこだけは英語だったので分かった)のだが、こんなページを持っていたとは。
私の言葉が結構載っている。こんな面白いこと書いたっけか(自画自賛)。 いずれにせよユーモアは重要だよな。
ブラジルからメールをもらう。 要約すると
というような内容。どうやら、
Ruby is a complete, full, pure object oriented language: OOL. This means all data in Ruby is an object, not in the sense of Python or Perl, but in the sense of Smalltalk: no exceptions. Example: In Ruby, the number 1 is an instance of class Fixnum.
という内容がブラジルのPythonエバンジェリストのお気に召さなかったらしい。 この文章を書いた時点では確かにそうだったんだけど、 そういえばnew style classとかが導入された時に、整数とかも含めてすべての「オブジェクト」はなんらかのクラスの「インスタンス」になったんだっけか。
で、調べてみる。やはり実際にPythonを起動するのがよいだろう。 irb相当が直接実行できるのは便利だ。
# python Python 2.3.4 (#2, Jan 5 2005, 08:24:51) [GCC 3.3.5 (Debian 1:3.3.5-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> type(1) <type 'int'> >>> int <type 'int'> >>> class Int(int): ... pass ... >>> Int() 0 >>> Int(256) 256 >>> type(Int(256)) <class '__main__.Int'>
確かに。ちゃんとintのサブクラスも作れる。じゃあ、intクラスにはどんなメソッドがあるのだろう。 確かPythonはdocstringがついてるって自慢してたな。
>>> print int.__doc__ int(x[, base]) -> integer Convert a string or number to an integer, if possible. A floating point argument will be truncated towards zero (this does not include a string representation of a floating point number!) When converting a string, use the optional base. It is an error to supply a base when converting a non-string. If the argument is outside the integer range a long object will be returned instead.
あれれ、変換関数のドキュメントだよ。おかしいな。
では、リフレクションを使って確認しよう。
>>> int.__dict__ <dictproxy object at 0xb7e2944c> >>> int.__dict__.keys <built-in method keys of dictproxy object at 0xb7e29464>
うーむ、わからない。ループを回せばよいのかな。
>>> for i in int.__dict__.keys: ... print i ... Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: iteration over non-sequence
だめだ。結局、ソースを読んで確認した(ここでドキュメントを探さないところがアレだけど)、 <type 'int'>(クラス)には唯一 __getnewargs__ というメソッドがあるらしい。
>>> 1.__getnewargs__()
File "<stdin>", line 1
1.__getnewargs__()
^
SyntaxError: invalid syntax
あらら、そうか。「1.」は構文解析できないのか。
>>> (1).__getnewargs__() (1,)
これはたぶんシリアライズかなにかに使うんだろうな。 うーむ、勝手が違って使いにくい。
あ、riに対応するpydocってプログラムがあるんだっけ。
% pydoc int
Help on class int in module __builtin__:
class int(object)
| int(x[, base]) -> integer
|
| Convert a string or number to an integer, if possible. A floating point
| argument will be truncated towards zero (this does not include a string
| representation of a floating point number!) When converting a string, use
| the optional base. It is an error to supply a base when converting a
| non-string. If the argument is outside the integer range a long object
| will be returned instead.
|
| Methods defined here:
|
| __abs__(...)
| x.__abs__() <==> abs(x)
|
| __add__(...)
| x.__add__(y) <==> x+y
|
| __and__(...)
| x.__and__(y) <==> x&y
|
| __cmp__(...)
| x.__cmp__(y) <==> cmp(x,y)
|
| __coerce__(...)
| x.__coerce__(y) <==> coerce(x, y)
|
| __div__(...)
| x.__div__(y) <==> x/y
|
| __divmod__(...)
| x.__divmod__(y) <==> xdivmod(x, y)y
|
| __float__(...)
| x.__float__() <==> float(x)
|
| __floordiv__(...)
| x.__floordiv__(y) <==> x//y
|
| __getattribute__(...)
| x.__getattribute__('name') <==> x.name
|
| __getnewargs__(...)
|
| __hash__(...)
| x.__hash__() <==> hash(x)
|
| __hex__(...)
| x.__hex__() <==> hex(x)
|
| __int__(...)
| x.__int__() <==> int(x)
|
| __invert__(...)
| x.__invert__() <==> ~x
|
| __long__(...)
| x.__long__() <==> long(x)
|
| __lshift__(...)
| x.__lshift__(y) <==> x<<y
|
| __mod__(...)
| x.__mod__(y) <==> x%y
|
| __mul__(...)
| x.__mul__(y) <==> x*y
|
| __neg__(...)
| x.__neg__() <==> -x
|
| __nonzero__(...)
| x.__nonzero__() <==> x != 0
|
| __oct__(...)
| x.__oct__() <==> oct(x)
|
| __or__(...)
| x.__or__(y) <==> x|y
|
| __pos__(...)
| x.__pos__() <==> +x
|
| __pow__(...)
| x.__pow__(y[, z]) <==> pow(x, y[, z])
|
| __radd__(...)
| x.__radd__(y) <==> y+x
|
| __rand__(...)
| x.__rand__(y) <==> y&x
|
| __rdiv__(...)
| x.__rdiv__(y) <==> y/x
|
| __rdivmod__(...)
| x.__rdivmod__(y) <==> ydivmod(y, x)x
|
| __repr__(...)
| x.__repr__() <==> repr(x)
|
| __rfloordiv__(...)
| x.__rfloordiv__(y) <==> y//x
|
| __rlshift__(...)
| x.__rlshift__(y) <==> y<<x
|
| __rmod__(...)
| x.__rmod__(y) <==> y%x
|
| __rmul__(...)
| x.__rmul__(y) <==> y*x
|
| __ror__(...)
| x.__ror__(y) <==> y|x
|
| __rpow__(...)
| y.__rpow__(x[, z]) <==> pow(x, y[, z])
|
| __rrshift__(...)
| x.__rrshift__(y) <==> y>>x
|
| __rshift__(...)
| x.__rshift__(y) <==> x>>y
|
| __rsub__(...)
| x.__rsub__(y) <==> y-x
|
| __rtruediv__(...)
| x.__rtruediv__(y) <==> y/x
|
| __rxor__(...)
| x.__rxor__(y) <==> y^x
|
| __str__(...)
| x.__str__() <==> str(x)
|
| __sub__(...)
| x.__sub__(y) <==> x-y
|
| __truediv__(...)
| x.__truediv__(y) <==> x/y
|
| __xor__(...)
| x.__xor__(y) <==> x^y
|
| ----------------------------------------------------------------------
| Data and other attributes defined here:
|
| __new__ = <built-in method __new__ of type object>
| T.__new__(S, ...) -> a new object with type S, a subtype of T
なるほど。勉強になった。やたら、「__」が目立つけど、演算子がメソッドとして実装されているのね。 いつのまにか。ソースではどこに対応するんだろう。 ただ、他にはまったくメソッドが定義されていないので、 事実上「インスタンス」としては使えないなあ。 今まで通りの「オブジェクト」とさして変わりはないような気がする。
ま、少なくとも
ということは明らかになったわけだ。件のページは修正するか。
分かったこと。私はやっぱりPythonに向いてない。 いや、Pythonがわるいってわけではなく、ただ私の脳があまりにもRubyに染まり過ぎているということなのだが(当たり前か)。
ちなみに、上記と同じことをRubyで調べようと思えば
% irb irb(main):001:0> 1.methods => ["%", "between?", "send", ...略...] irb(main):002:0> 1.class.instance_methods => ["%", "between?", "send", ...略...] irb(main):003:0> Fixnum.instance_methods => ["%", "between?", "send", ...略...]
などの方法で直接的に調べられるし、あるいはriを使って
% ri Fixnum
------------------------------------------------ Class: Fixnum < Integer
A +Fixnum+ holds +Integer+ values that can be represented in a
native machine word (minus 1 bit). If any operation on a +Fixnum+
exceeds this range, the value is automatically converted to a
+Bignum+.
+Fixnum+ objects have immediate value. This means that when they
are assigned or passed as parameters, the actual object is passed,
rather than a reference to that object. Assignment does not alias
+Fixnum+ objects. There is effectively only one +Fixnum+ object
instance for any given integer value, so, for example, you cannot
add a singleton method to a +Fixnum+.
------------------------------------------------------------------------
Includes:
---------
Precision(prec, prec_f, prec_i)
Class methods:
--------------
induced_from
Instance methods:
-----------------
%, &, *, **, +, -, -@, /, <, <<, <=, <=>, ==, >, >=, >>, [], ^,
abs, div, divmod, id2name, modulo, quo, size, to_f, to_s, to_sym,
zero?, |, ~
としてもよい。
なんと。しかし、母集団が男子200名しかないので、1位でも8人。 ほんとに意味があるのか。統計学的にはどんなもんなんでしょう。
Enterprise Watchより。
おそらくIBMが500件の特許をオープンソースに公開したことに対応する、プレス発表から。
ソフトウェアには、権利と製品そのものの2つのコンポーネントがあるとし、「特許は新製品を生み出す根源、ドライビングフォースとして無視できない。これは商用ソフトの世界では中心的な考え方として確立されている」との考えを述べた。
発明を公開させる代わりに一定期間独占的な権利を保証し、 発明(とその公開)に対するインセンティブを付与する、というのが特許の目的であるので、 「新製品を生み出すドライビングフォース」としての側面がないわけではないだろう。 また、その考えがマイクロソフトが所属している「商用ソフトの世界」で中心的な考えであることも否定しない。
しかし、本当に特許は「ドライビングフォース」として有効なのだろうか。
もちろん、苦労して発明した内容が真似されたい放題では発明意欲が下がる、というのはあるだろう。 しかし、逆に苦労して開発したソフトウェアが、 (実際には真似したわけではないのに)「そのアイディアは私の特許だ」と訴えられれば、 私だったら開発意欲が激減する。
おまけに特許は独占権なので、権利者は自分の特許に対して
ので、権利期間中はそのアイディアに関して事実上無限の権利を持つことになる。
つまり、「自分のアイディアが真似されない」という権利は、 逆に「自分の開発を阻害する」権利を他人に与えることと同等である。 なんとなく、大国が核兵器を抱えてにらみあった冷戦の構図を思い出す。 あの頃も核兵器に対して「抑止力である」と主張していたよなあ。
さて、この場で平野氏はオープンソースについても興味深い発言をしている。 こちらはCNET Japanの方が詳しい。
また平野氏は、オープンソースソフトウェア（OSS）と商用ソフトウェアの連携についてもコメントした。同氏は、両ソフトウェアをうまく連携させるためには、同一のルールに基づき、他者の知的財産権を尊重する必要があるとし、実効的な相互運用性の実現と、業界横断的な協業関係を構築することが重要だとしている。「商用ソフトウェアとOSSが知的財産によって連携することが必要だ」（平野氏）
ただ、OSSとの連携においては課題があると平野氏。それは、OSSの多くは知的財産権の検討を経ずに開発されており、他の知的財産権との連携を念頭においたプロセスが欠如していることだ。また、Linuxなどで採用されているGNU GPL（General Public License）が、特許に対してライセンス料を支払わずに配布するという方式を取っており、知的財産権との連携をむしろ阻止する考えであるためだ。このような問題はあるものの、平野氏は「これは制度の問題に過ぎないので、お互い知恵を出し合うことで解決に向かうのではないか」としている。
ええ、お互いの頭に銃口を突きつけあうような生き方はしたくありませんから。
とはいえ、平野氏の言う「商用ソフトウェアとOSSが知的財産によって連携すること」とか、 「お互い知恵を出し合うことで解決に向かう」ことで得られる「解決」とはどのようなものか 興味深い。私には知恵が足りないので、 「持てるもの」であるマイクロソフトに一方的に有利な「解決」を考えちゃうんだが。
あるいは、IBMのやり方を他のオープンソース関連企業(たとえばOSDN参加企業)も行い、 オープンソースの特許トラストを形成するとか？
追記
同様の内容がGroklawでも論じられている。
目新しい内容は
くらいか。オープンソース特許トラストができたら、マイクロソフトをはじめとする「旧体制」陣営はイヤだろうなあ。でも、それは「毒をもって毒を制している」わけだから、オープンソース側にも抵抗のある人は多そうだ。
定期訪問。普段なら私一人が出雲に出かけるところだが、 今回は妻の希望で家族全員を連れて出雲支部に出席する。 定期訪問の場合、聖餐会の最終話者の責任があるのでちょっと照れ臭いのだが。
お話のテーマは「世の光となる(マタイ 5:13-16)」。今年のステークのテーマである。
Linux Magazineの連載最終回の原稿が切羽詰まっていたりして、 あまり十分な準備ができなかったのだが、 それなりにスムーズに話ができた。妻にもほめてもらえたし。
しかし、私ってば、子供のときからだが「準備が足りないなあ」と不安を感じた時の方が結果が良かったりするんだよね。 学生時代の期末テストなどでも「しっかり勉強したぞ」って感じた時よりも、 「現実逃避ばっかりだったなあ」と感じた時の方が成績が良かったりしたし。 こういうのが重なって、地道な努力が身につかない現在の性格が形成されたような。
それは、ともかく。
６人も出席が増えたので出雲支部の人(特に支部長さん)は喜んでいた。 うちの子供たちもそれぞれにちょうど良い年齢の気が合う人がいたようで、 それなりに楽しかったようだ。
私も楽しかった。充実した日曜日だったように思う。
妹の誕生日であった。なんにもしなかったよ、まずいな。
実は私は子供のときの記憶があんまり残ってなくて、 買ってもらったおもちゃのこととかあんまり覚えてなかったのだが、 改めて写真を眺めてみると
などを持っていたことを思い出した。 完全に忘れ去っていたパッケージをあける瞬間のこととか何十年かぶりに思い出した。 懐かしい。
ていうか、結構いろいろ持っていたのね。
Linux Magazineは2月8日売りの3月号が最終号です。ということは、 私の連載も最終回というわけですね。今日は最終回の原稿を書いてました。 テーマは『ネタのタネ』。今までどこから『探訪Ruby』のネタを引っ張ってきてたかどうかを暴露するって 趣向です。暴露って言っても、全然たいしたことはなくて、 結局いくつかのサイトとメーリングリストを紹介するだけなんですけど。
で、二晩ほど夜なべした結果、今日とうとう完成しました。 朝5時まで原稿書いてるのを「夜なべ」というのもどうかとは思うんですが。
で、完成記念に今までの連載一覧(これは最終回にも載るものの抜粋です)。
03年12月号 第1回 Rubyの国へようこそ/オープンソースのビジネスストーリー 04年 1月号 第2回 テスト第一主義/ オープンソースと特許 04年 2月号 第3回 Wiki Wiki/日本Rubyの会 04年 3月号 第4回 Blogの世界/Rubyの未来 04年 4月号 第5回 アスペクト指向/ごみ集め 04年 5月号 第6回 RubyとEmacs/Emacsによる開発 04年 6月号 第7回 Instiki/歴史は繰り返す 04年 7月号 第8回 テンプレート/プロトタイプな世界 04年 8月号 第9回 DBM/メールリーダの新アプローチ 04年 9月号 第10回 tDiary/挑戦！言語塾 04年10月号 第11回 Webアプリケーションの基礎/Lightweight Language Weekend 04年11月号 第12回 Webアプリケーションの基礎(その2)/汝は人狼なりや？ 04年12月号 第13回 Webアプリケーションフレームワーク/Ruby Conference 2004レポート 05年 1月号 第14回 マークアップ・マークダウン/名前重要 05年 2月号 第15回 ダイコン/文字コードの憂鬱 05年 3月号 最終回 ネタのタネ
先日の続き。
佐渡さんが「こっちにも書いて」ということなので、あっちに書く。
ま、そういうことで。
追記
あっちはツッコミ欄もリンク元もないんで寂しいなあ。
高校の後輩のくろももさん(特に本名は秘す)が帰省のついでにわが社に訪問。 社名が長すぎる当社に「ネ研」なる愛称をつけてくださった。
それはそれとして、外部にはとても書けない(オープンソース関連の)あんな話やこんな話を聞いた。 実に興味深い。
4797328541 アマゾンからBjarne Stroustrupの『4797328541』についてのダイレクトメール。私は0201543303をStroustrup本人から(しかもサイン入り！)いただいているのだが、やはり日本語の方が読むのは楽だし、しかも今回、日本語版のために書き下ろされた「C++過去から未来へ」なる章がついてくるらしい。ちょっと魅力か。
アマゾンのページを見ると「岩谷 宏 (翻訳)」。がーん。これは...。
やっぱ原書読もう。
GuidoのBlog、第4段。
「Redux」は(後置して)「帰ってきた」という意味だから、訳すと 『帰ってきたPythonのオプショナルタイプチェック』というところだろうか。
要旨は、以下の通り。
Pythonの型指定の新文法
def foo(a: t1, b: t2) -> t3: "your code here"の意味を
def foo__(a, b): # The original function "your code here" def foo(a, b): # Typechecking wrapper a = __typecheck__(a, t1) b = __typecheck__(b, t2) r = foo__(a, b) r = __typecheck__(r, t3) return rにしてはどうか。この場合、__typecheck__()はモジュール作者が自分で定義できる。
うーん、第一弾、 第二弾に比べて、 ずいぶんおとなしくなってしまった感はぬぐえない。
なんか、がっかり。
特に良くないと思うのは、「新文法」の持つ「意味」が、 __typecheck__()関数の定義によってさまざまに変化することだ。 あるモジュールではisinstanceof()チェックが行われ、 別のモジュールではまったく同じ外見でadapt()が行われ、 また別のモジュールではsignatureによるDuckTypingチェックが行われるかもしれない。
このような「多様性/柔軟性」は私の視点からは悪である。 「文法の意味は変化しちゃいけない」というのが私の信念である。
他人を批判するばかりでは生産的でない。 もし仮に将来のRubyに型チェックを導入するとしたら、 どのようなものにするか、と問われると、今すぐに具体的な答えは出ないのだが、 現在Cエクテンションが使っているようなものに近いものになるのではないだろうか。
RubyのCエクテンションでは、構造体の型が一致している必要があるため、 DuckTypingではすまないケースが多々ある。そのような場合、
という手順で型チェックを行っている。RubyでTypeErrorを見かけるのはだいたいこのような状況である。 ところがRubyレベルでは(DuckTypingが容易なので)このような仕組みがないので、 型の違いはメソッドがない(NoMethodError)によって検出される。 この辺を統一する「なにか」がほしいなあ、とはずっと思っているのだ。
具体的なアイディアはないんだけど。
ソフトウェア開発の生産性の話。
しかし、不思議なことにソフトウェア産業では、この「怠け者」に一人前の報酬を支払っていることが多い。場合によっては「怠け者」の言い分を真に受けて、「怠け者」の方が報酬が多くなることもある。なぜなら、他の人より長時間働くことになり残業手当が多くなるからである。この業界を知らない人にとっては信じられないことかもしれないが、これは事実である。
そうそう。時間で働くのは間違っているよね。 だから、8年前、うちの会社ができる時、 「残業手当はなしにしましょう」と提案した。 おかげでうちの会社は今でも残業手当がない(正確には「みなし残業手当て」が全員に支給されている)。 おまけに完全裁量労働制だから、仕事をこなしている限り、 何時間働こうが自由である。厳密には労働基準法がどうこうとかあるけど、 少なくとも運用上は完全に自由である。
じゃあ、従業員は怠けるか、というとそうでもなくて、 むしろ一生懸命働いている。時には私生活まで犠牲にして。 かえって上司が止めないといけないくらい。
つまり、本当のプログラマは面白い仕事には寝食を(忘れて)没頭するということなのだろう。 良い環境と良い仕事を提供することこそが鍵であると思う。
共有可能なTodoを実現するWebアプリケーション。 まだ使ってないんだが、便利だという声も聞く。
しかし、もっと驚くべきことはRubyOnRailsを使って実装された、 このWebアプリケーションは、わずか579行しかないという点だ。
ちょっとRails勉強してみようかなあ。
先日届いたままほったらかしてた論文集をやっと読みはじめる。
面白そうなのがたくさんあるが、今日はこれ。
Object-oriented Encapsulatoin for Dynamic Typed Language N. Schaerli, A. P. Black, S. Ducasse pp.130-149
この論文で言う「Encapsulatoin」って、一般に言う「カプセル化」とは違うものなのかな。 十分に理解できなかった。もうちょっと考察してみよう。
We have presented our model in terms of the language Smalltalk and illustrated it with various examples. We believe that it is equally applicable to other dynamic object-oriented languages such as Ruby.
ということなので、Rubyにも適用できるのかもしれない。
他に面白そうだったのは
A Unified Theory of Garbage Collection D. F. Bacon, P. Cheng, V. T. Rajan Super and Inner -- Together at Last! D. S. Goldberg, R. B. Findler, M. Flat
など。他にもいくつかあるが、全部理解するまでには時間がかかりそうだ。
ハッカーたるものは、日々みずからの環境を改善すべくハックするものである。
今日の(というか昨日から今日にかけて)のハックは、migemoとtdiaryである。
migemoのローマ字入力はヘボン式と訓令式の両方に対応しているが、 あいにく私の入力方法は「きゅうり改」である。 そこでromkan.rbを置き換えて「きゅうり改」を解釈できるように改造した。
既存のローマ字変換と「きゅうり改」の共存はできなかったのが、残念だ。 ま、ハックだから。
tdiaryの方は、リンク元や検索元に対して「rel="nofollow"」を追加した。 あと、コメント中のURL→リンク変換にも追加。
松江と米子の間、安来市には白鳥ロードと呼ばれる農道がある。 この道の両脇にある水田には冬の間白鳥(コハクチョウ)が越冬しにくるのだ。 なんでも白鳥の越冬地の南限らしい。 そこで子供たちと安物の双眼鏡をもって見学しに行った。
水田には何百羽ものコハクチョウが群をなしていた。中には編隊を組んで飛ぶものもおり、 なかなか壮観であった。
その後、米子市の水鳥公園に。(全国で5番目に大きい湖である)中海に、 カモをはじめとする水鳥が集まっている様子を見学できる。 もちろん白鳥もいた。
これまた壮観であった。
帰りに弟のアパートにあいさつしてから帰る。
家族で松江ワードに出席。 わりとおとなしくしていた。
妻は第二話者の割り当て。「良い御言葉で養う」というテーマ。 なんて難しい。ところどころで私を引き合いに出すのが恥ずかしい。 でも、いいお話だったよ。
集会終了後、娘たちはコーラスの練習。 今度の大会では歌を披露するらしい。
先日の「Python Optional Typechecking Redux」で、
特に良くないと思うのは、「新文法」の持つ「意味」が、 __typecheck__()関数の定義によってさまざまに変化することだ。
と書いたら、「丁稚な日々」で
Rubyのfor文におけるeachメソッドの立場と、GuidoたんのこのOptional Typechecking機構における__typecheck__メソッドの立場って、あんまり変わらないような気がするんですが、どうなんでしょう?
- 同じ。Rubyのfor文はよろしくない例である。
- 違う。これとあれとは別の次元の話である。
- その他。
どれなのかしらん。
と突っ込まれていた。正解は2番。
for文におけるeach(caseにおける === でもいいけど)は、 eachは「各要素に対して繰り返す」という共通の「意味」を持つことが、 仕様と実装(既存のクラスのeachはすべてそうなっているという意味で)で示されている。 多態というのは「実装は違うが意味は同じ」であるからこそ成立する概念だ。
一方の、__typecheck__()だが、こちらはまず第一に多態ではない。 「オブジェクトに適した動作」を選択する「オブジェクト」がないのだから。 また、「モジュールごとに適した型チェック」なるものも存在しない。 「モジュール作者が望んだ型チェック」ではあるだろうが。
また、もっと悪いことに「型チェックする」という「大まかな意図」こそ指定されているが、 それが意味するものが、
であるかは、決められておらず、逆に「好きなのを選んで」と任せてしまっている。 これでは共通の「意味」があるとは認められないだろう。
Paul Grahamの新作。川合さんによる訳。
共感を持った言葉:
実際のところ、もし16歳のシェークスピアやアインシュタインが君と同級生だったとしたら、たぶん彼らは才能を現しているだろうけれど、それ以外は君の他の友達とさほど変わらないはずだとぼくは思う。
こう考えるのは、おっかないことだ。彼らがぼくらと同じなんだとしたら、彼らはすごいことを成し遂げるためにものすごい努力をしたってことになる。そう思うのはこわいから、ぼくらは天才というものを信じたがるんだ。ぼくらが怠けている言い訳ができるからね。もし彼らが、魔法のシェークスピア属性やアインシュタイン属性のせいで素晴らしいことを成し遂げたんだとすれば、ぼくらが同じくらいすごいことをできなくてもぼくらのせいじゃないことになる。
そうなんだよ。「彼らは違う」というのは簡単だけど、実際はそんなに違わない。
今、ぼくは素晴らしい仕事をした人を何人も知っているけれど、みんな同じなんだ。自分を律するということをほとんどしない。延ばせることはぐずぐず先に延ばすし、興味のないことをやらせようとしても全くの無駄だ。そのうちの一人ときたら、自分の結婚式に出席してくれた人へのお礼の手紙をまだ半分しか出してない。結婚して4年経つのに。もう一人は、メールボックスに26000通のメールをため込んでる。
あはは。私もよく妻から「あなたって全然自制心がないのね」って言われてる。
自律心が全くのゼロだったら困るよ。走りに行こうかなと思うくらいの自律心は必要だ。ぼくも時々、走るのが面倒だなあと思うけれど、一度走り出せばあとは楽しめる。そして何日か走らないと具合が悪くなる。
そうか、「走りに行こうかなと思うくらいの自律心は必要」なのか。 体重も増加傾向だし、走ろうかなあ。
しかし、川合さんは、ばりばりプログラムも書くし、翻訳もうまいし、すごいなあ。 梅田さんも注目している。
「知られざるRuby 2.0のリリース」という話ではなくて、 Chris Pineのところに二番目の娘(Rubyちゃん)が産まれたという話。
ちなみに、Chris Pineの長男は「Cくん」だそうだ。
一昨年のOSCONに会った時、「娘が産まれたらRubyって名前にする」って言ってたけど、 本気だったらしい。
一番おかしかったフォローアップは
Congratulations to both of you!
The post was really neat and funny... thank goodness you don't program in PYTHON! ;-)
であった([ruby-talk:127818])。やっぱ、リアルで「Pythonちゃん」はマズいだろう、いくらなんでも。
ことの発端はO'Reilly ONLampのCurt Hibbsの記事であった。主にWindowsユーザを対象にRuby on RailsをMySQLのインストールからはじめて丁寧に解説する記事。
これが本家スラッシュドットに取り上げられた。
さらに、PHPとMySQLで実装されていた音楽配布サイトCD Babyが、 Ruby on RailsとPostgreSQLで再実装することを決定するニュースが。
その結果、RailsのRubyGemのダウンロードが1月21日の一日だけで935を記録。 同日、One-Click Installerのダウンロードも1499を記録した。
予想以上のインパクトだ。
元々は、Linux.com分室に書いた記事だが、こちらにあまりにたくさんコメントがついたので利便性のため、こちらにもコピーすることにする。
「GPLの見直しが進んでいる」が、その詳細は明らかになっていない、という話。 GPL3についての新しい情報はなにもないが、 それぞれの人が勝手な立場からいろいろ期待していることは分かる。
Sughrue Mion法律事務所に所属する弁護士のFrank Bernsteinによると、... 特許に関する問題が解決されれば、オープンソースソフトウェアの（発展の）貢献者であり顧客でもある企業にとっては、GPLがさらに利用しやすいものになる可能性があるという。
オープンソース文化を啓蒙する非営利組織Open Source Initiative（OSI）会長のEric Raymondは、「ソフトウェア特許に関する厄介で崩れかけた少数寡占体制がより深刻な被害をもたらす前に、それを解体する方法を見出す必要がある」と述べ、さらに「仮にGPL Version 3がその一助になるのであれば、（同ライセンスは）大変貴重な存在だ」と語った。
オープンソース提唱者のBruce Perensは、特許権侵害訴訟に関する罰則が、単に問題のソフトウェアの使用禁止から、フリーソフトウェアと分類される全てのプログラムの使用禁止へと強化されることを期待しているという。「次期版GPLに、例えば、ある人物が特定のフリーソフトウェアに関する特許権を行使したら、その人間のフリーソフト使用権が消滅するといった、相互防衛条項が盛り込まれることを期待している」(Perens)
Eric RaymondやBruce Perensが、Stallman以上にGPLを「武器」として使いたがっているのは、 興味深い。
しかし、私の予想では、いろいろなしがらみからそのような「劇的な変更」は行われず、 現在の条項の明確化が行われるのがせいぜいだと思う。
GPLにはこんなことが書いてあるしね。
9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
現在の精神を満たしつつ、新たな「制約」を加えるのは容易ではないだろう。
さて、仮にGPL3が登場したとしよう。 現時点ではどのようになるのかまったく明らかにされていないので、 どのような条項になるのか予想することさえ困難だが、 それは現在のGPL(GPL2)よりもある部分では制限が厳しくなるかもしれないし、 別の部分では制限が緩くなるかもしれない。
さて、それは現在すでにGPLが適用されているオープンソースソフトウェアにどのような影響を及ぼすか。
多くのGPLソフトウェアにはこのような注意書が書かれていることが多い。
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
つまり、このソフトウェアを修正あるいは配布する際のライセンスとして、 GPL2かまたはGPL3の「好きな方」を選ぶことができる、という意味だ。
このライセンスを受け取った人のうち、 GPL3の方が制限が厳しくなる部分が(あるかどうかさえ現時点ではわからないけど)気に入らない人は自らにGPL2を適用することができる。 逆にGPL3の方が制限が緩くなる部分があり、その方が都合が良い人はGPL3を適用できる。 が、その場合でもそのソフトウェアのライセンスの条件が「either version 2, or (at your option) any later version」であることには代わりがない。 この条件だとGPL3が「自動的に適用可能になる」が、「自動的に適用される」わけではない。
だがしかし、これだけ外部からいろいろ言われていると、 「将来のFSFの行動を信頼できない」と思う人もいるかもしれない。 私は２０年以上の実績を信じるけど。
そういう人は「このバージョンのGPL」とか「添付したGPL」とかを明示するとよいだろう(Linuxはそうしている)。 個人的にはそれによってえられるメリットは多くはないと思うけど、 それによって「心の平安」が得られるのなら、それはそれで良いと思う。
「分室」からコピー。
今回はNIIKEINET IT newsから。
米サン・マイクロシステムズは25日、高性能コンピューター用の基本ソフト（ＯＳ）関連特許1600件を無償公開すると発表した。世界中の技術者に特許を自由に使ってもらい、情報技術（ＩＴ）製品・サービスの開発を促し、市場を拡大するのが狙い。
喜ばしいことだが、どのような手続きで公開されるのかをきちんと見極めたい。この記事によれば
専用のホームページを開設、簡単な契約手続きさえすれば、誰でも関連特許を閲覧・利用できる。
ということだが、この「契約」が曲者だ。
追記
つまり、IBM流の「OSD準拠ならOK」という基準ならオープンソース全体に対して益になるが、 下手な制約(たとえばCDDLだけとか、もっと悪いのはOpenSolarisだけが対象とか)がつくと、 益になるどころか害になるケースだって考えられる。公開手段の公表を待ちたい。
追記2
やっぱり「CCDLだけ」だった。ま、どういうふうに使うかはSunの勝手だとは思うけど、インパクトとしても実益としても価値は激減だな。
Guido van Rossumによると、 Rubyは「seems like an accident attempt in cleaning up Perl」なんだそうだ。 言ってくれるな。
ま、Guido自身がコメントを出さねばならないほどRubyのプレゼンスが向上したことをすなおに喜ぼう。 それに、こっちも「__typecheck__は良くない」とか書いてるしな。
Guidoって割とRubyに対して警戒心を持っているようで、OSCON 2003でもわざわざRubyトラックにやってきて「Ruby guys misinform about Python」とか発言したらしい。私はその場にいなかったんだけど。
追記
いろんなコメントがついている。 いや、「accident」でも「excellent」でもどっちでもいいんだけどね。
GPLについてコメント欄で議論してたら、すっかり更新が滞ってしまった(書いているのは３１日)。
来週の木曜日・金曜は、翔泳社でDevelopers Summit 2005（デブサミ2005）が開催される。
私は「オープンソーストラック」の「なぜ「オープンソース」でうまくいくのか？--後編：まつもとゆきひろが語る「オープンソース的開発手法の現実」でしゃべることになっている。まだ風穴さんと打ち合わせが終わってないんで、どんな内容について話すのかよくわからないんだけど。でも、きっとGPLの話とかではないに違いない。そういうのは弁護士の先生に聞いてください。
実際には開発体制とか、コミュニティ運営の話になるのではないかと思う。 ツッコミでの「聞きたい話」とかのリクエストは歓迎するけど、 風穴さんがしきると思うから、要望にこたえられるかどうかはわからない。
あと、木曜の夜、私(とかずひこくんも？)と一緒に食事したい人も募集する。
Jim Weirichからの
We will be introducing Ruby to our XP Users group in Cincinnati next week. I thought it would be fun to create a list of "Ten Things Every Java Programmer Should Know About Ruby" to help the transition. I've got a number of things in my head, but would love to hear ideas from the mailing list.
来週
コネチカットシンシナティのXPユーザーグループでRubyについて紹介するんだけど、 「Javaプログラマが知っていたほうがいい１０の事実」なんてリストを作るといいんじゃないかと 思うんだ。リストからの提案歓迎(超訳)
というポスト。
これから一大スレッドが発生する。とりあえずリストメンバからの提案は、 Jimのta-da listにまとめられている。 っていうか、１０どころじゃないんだけど。
そこから派生して
などの話題が爆発する。
Francis Hwangの「Coming to Ruby from Java」も参考になる(かも)。
「オブジェクト指向は一見すばらしいアイディアのように見えるけど実用上はそうでもない」という主張。
ま、オブジェクト指向ファンを自認する私でも万能だと思っているわけではないから、 彼の主張は理解できないでもないのだが、それは「向いていない局面もある」という意味だと理解していて、 今さら利点について議論の余地はないと感じていた。
そういうところに、この主張はかえってものめずらしい。 でも、どっちかっていうと２０年前なら珍しくなかった議論がなんかの偶然で「生き残って」しまった、 という印象かなあ。
「OOP Criticism」というページまで作って、 一生懸命オブジェクト指向プログラミングを否定する熱意はとても理解できない。 かつてオブジェクト指向に過大な期待をして、「万能でない」ということを発見した落胆が動機になっているのかなあ。
「OOPは実用的なケースでだめ」と主張する割に、彼の「Challenge」ではオブジェクト指向ソリューションの方が見栄えが良く、それに対して「不完全な解に過ぎない」などといちゃもんつけているのが美しくない。それって結局大差ないってことじゃん。 さらに、彼が「より良い手法」と提案する「Table Oriented Programming」が全然魅力的に見えないし、オブジェクト指向よりも汎用性が低そう。
そう感じるのは、私がオブジェクト指向プログラミングに「毒され」すぎているからだろうか。
子供たちの小学校の文化会(のようなもの)。演劇や発表などなど。 それぞれの発表を見たが、がんばっていた。
高学年になった娘たちの同級生にはもはや大人サイズの子もいる。 妻より身長高いんじゃないか。幼稚園のころから知っているだけにびっくりする。 ヒトの子の成長は早いわ。
4274065979
以前お世話になったオーム社の編集の方から献本をいただいた。ありがたい。
この本にはずっと縁がなくて
など「すれちがい」が続いていたのだ。
せめて「Matzはまだまだマイナーなんで、Blurbは編集会議で没になりました」とか、 「コメントを求めた次の日からバケーションだったんで、3日後にコメントをもらったのは遅すぎでした」とか フォローがあったら、こんなにいじけないのに。
なんて愚痴っているけど、この本はいい本です。 ハッカーとして成功したいなら、こんな「にっき」読んでないで、この本を読むべきです。
次女が風邪っぽいので車2台に分乗して教会に向かい、 次女、三女と妻は聖餐会だけで帰る。
すっかり忘れていたのだが、長女は若い女性のミーティングがあるということで、 長男を一度自宅に連れて帰る。結局２往復もしてしまった。
慌ただしい日ではあったが、聖餐会の話は心に響くものがあったし、 帰ってからもそれなりになごやかに過ごせたので良かった。
先日、懸念を表明したSunの特許開示だが、 PUBPATも異議を唱えているようだ。
PUBPATは、「Sun社の発表は関連の法律書類と比べてあまりに広範囲だった。Sun社の特許に対して一般（開発者）がどういった権利を持ちえるのかという疑問が残る」と指摘する。「Sun社があとになって特許侵害を追求することができてしまうのかどうか、オープンソース・ソフトウエアの開発者にはっきりと説明するべきだ」（PUBPAT）
PUBPATは意見書で、「どのライセンスを適用すれば安全にSun社の特許を利用できるのか」「Sun社は第三者が記述したソフトウエアに対して特許権の主張を放棄するのか」などの質問を挙げたほか、同社と米Microsoftとの関係が特許やオープンソース・コミュニティに与える影響についても懸念を示した。
PUBPATは開発者に対し、「Sun社の言葉に惑わされないように注意するべきだ。実際に許可される以上のことをSun社が与えてくれていると勘違いしてはならない」と忠告している。
まったくもってもっともだ。
「Matzにっき」はPUBPATを応援します。
うちのコメント欄でGPL3についての議論が続いている。が、あんまり熱が入り過ぎて、 結城さんにも「長くて読めない」と言われている。
今回の議論で登場した危機の具体的な例というのは、私の知る範囲内では
くらいしか出ていないと思う(特許についても危険性がほのめかされていたが「具体的」とは思えなかった)。 これらは確かに具体的ではあるが、正直なところ、間違ってもこれを「現実的な例」とは呼べないと思う。 たとえStallmanがバスにはねられても、FSFがそんな「発狂」した行動を取るとは思えない。 まかり間違ってGNUソフトウェアが「誰かのもの」になったとしても ライセンスは過去に遡って変更できないから、フリーソフトウェアとしてのGNUソフトウェアがなくなることはない。また、フリーソフトウェアにとってあるソフトウェアが途中からフリーでなくなるというような 「攻撃」は過去頻繁に起きてきたたことだ(たとえば最近だとsourceforgeが思い出される)。 FSFがGNUソフトウェアの権利を保持することで、そのような危険性がほんの少し上がるとしても、 FSFが権利関係の調停で忙殺されるデメリットに比べたらゼロに等しい。要はバランスだ。 こんなことをいちいち心配するくらいなら、天から隕石が落ちてくることを心配する方がマシだ。
もうちょっと現実的な例が出てこない限り、 素人同士がいろいろ意見を突き合わせても、 世間に与えるインパクトはゼロに近く、 FSFになんらかの影響を与える可能性もほとんど期待できない。 「茶飲み話」以上の建設的な議論にはならないんじゃないだろうか。
ところで、先週末になってやっと思いついたのだが、 FSFは将来のGPLに対して本当にフリーハンドなのだろうか。
GPLの第9条にはこうある
9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
つまり、新しいGPLは現在のGPLに対して「similar in spirit」であると宣言されている。 であれば、FSFは新しいGPLを「GPLの精神の合致したもの」とする (たとえば単純なBSDライセンスにするような類の変更を行うことはしない)、 と約束していると考えてもよいのではないか。
その結果、将来のGPLがライセンサ(ソフトウェア権利保持者)の視点から、 「現在のGPLの精神と類似でない」と感じられたら、 「それはlater versionとは見なさない」と(後から)宣言できるような気がする。 権利がFSFに移行しているGNUソフトウェアの場合と違って、 単にGPLを適用しただけのソフトウェアの場合には、 FSFは様式を定義しただけの第三者なので、強制力は持たないはずだ。
「契約としてはいいかげん」というのは認めるけど、 「双方誠意をもって対応する」なんて平気で書いちゃう契約も結構見かけるし、なにより、 少なくとも日本の法律ではGPLはまだ「契約か、権利の不行使宣言か」すら弁護士でも判断できないレベルのはずだし。
より明確にするならば、「any later version, unless the author refuses explicitly」とでも書くか。 特にお薦めはしないけど。