Rubyに関して、私にはささやかな夢がふたつある。
ひとつはふらっと入った田舎の本屋(スーパーとかに入ってる)でRubyの本を見かけること。 コンピュータ関係の本を揃えてるところではもう珍しくはないが、 まだ小さい本屋では見かけない。LinuxやCGIの本は置いてあるので、もう少しかな。
もうひとつは、うちの子(か親戚の子)が授業でRubyを使うことになって、 「先生、Rubyはうちのお父さん(おじさん)が作りました」ということ。 これはちょっと遠そう。
それはさておき。
今日、NHKの『クローズアップ現代』見ていたら、地震研究者のコンピュータの画面が映っていた。 液晶ディスプレイのとなりにはコンピュータ書籍が並んでいて、 『プログラミングPerl(第2版)』と『はじめてのPerl』が映っていた。
「ああ、Perlな人なんだなあ」と思い、興味を引かれて一時停止してよく見ると、 なんと『たのしいRuby』も映っていた。他の本の上に置いてあったので、 より頻繁に参照していただいているのかもしれない。
ありがたいことだ。
kwatchさんから「よくわかりません」というツッコミをもらいました。
「プログラマーのためのプログラマー日記」の最終日*1にも同様のことを書いておられたのを読んではいたのですが、 「もう少し解説してほしい」と頼まれれば、書くしかないでしょうね。
まず、「数学の概念とあまり合致しない」という点ですが、それはたぶんあまり重要ではないと考えています。 私が数学苦手なせいかもしれませんが。
そもそも数学の概念を持ち出しちゃうと、 プログラミング言語の代入って許せないものじゃないですか。
x = x + 1
とかありえないわけですし。よって数学における変数や代入のイメージに厳密に沿うと、
という関数型言語みたいな代入と変数しか許容できないような気がします。
え？ 「そういう意味じゃない、そこまでは言ってない」ですって？
そうでしょうとも。では、「数学における変数や代入のイメージ」とはどんなものでしょう。
変数とは「関数のパラメータ」か「一時変数」であり、 「値(計算の途中結果)」に後で参照できるために名前をつけたものでしょう。 また、代入とは「値」に名前をつける行為です。
つまり、これは名札モデルです。 kwatchさんの直観とは反対に、名札モデルは数学の概念に合致しているわけですね。
たぶん、kwatchさんは「数学における変数や代入」という言葉で違うものをイメージしていらっしゃるとは 思うのですが、そのイメージは普遍的なものではないかもしれません。
「同じ説明は箱でもなりたつだろう」という指摘があるかもしれません。 もっともです。
問題は箱は名札と違って名前と強く結びついていないと言う点です。 現実世界の箱はむしろ入れ物としての性質が強く、変数よりもオブジェクトに近い性質を持ちます。 実際にCやC++では箱はオブジェクトです。
これを変数の説明に使ってしまうと後でオブジェクトと変数の区別が難しくなるんじゃないかと 心配しているんです。余計な心配かもしれませんが。
追記:
なんかフォローもらってますね。残念なことにどれもよくわかりませんでした(脳力が足りない？)。
Lisp だと箱に相当するのはシンボルでしょうか?
伝統的なLispのグローバル変数はそうでしょうね。
しかし、たとえ伝統的Lispでもローカル変数だと環境リストに格納されちゃうんで、 実装も名札モデルですよね。
「値に名前をつけたものが変数」というのは変ではないでしょうか。 実行時のある時点の文脈においてはそのように見えるかもしれませんが、 私の感覚だと「仮の名前(変数名)をもつ、後に与えうる未来の値が変数」というか。。
えー、なんで変なのかな。プログラム上のどこの地点で考えるかによるのでしょうか。 「仮の名前をもつ、後に与えうる未来の値」ってことは宣言した地点で考えているように 思われるのですが、Rubyには宣言はないしなあ。
名札モデルだと、代入っていうのは、名札を付け替えるのに相当するのでしょうか？ これって、変数aとbがリファレンスで同じものを指していて、 b=1としたときに、aも1になるような場合の説明が難しいのではと思います。
えーと、C++にはリファレンスがあるのでそういうことが起きますが、 「もっと良い言語」であるRubyではそういうことは起きませんよね。 今は、Rubyの変数の話ですから、C++のリファレンスについて考える必要はないと思います。
CやC++の変数は確かに「箱＋名札モデル」で説明するのがよかろうとは思いますが。
*1 「プログラマーのためのプログラマー日記」、終わっちゃったんですね、残念。
まだ終わらない(苦笑)。
...その名前は＜値への名づけ以前＞、つまりコードを書いただけの段階でも存在するような気がしますし、...
いや、プログラムは台本のようなものですから、実行時世界には存在しないんです。
登場人物が台本の内容に言及してしまうと、 舞台はスラップスティックになってしまいます。 そういうメタな話は(たまには面白いですけど)やっぱり反則に近いですよね。
「関数のパラメータ」や「一時変数」というのは、あとから 値を利用できるように箱にとっておく、つまり箱モデル そのものと思っており、名前をつけるという感覚がまったく ありません。
いや、まあ、人の持つイメージは想像以上に多様だということでしょう。 私の数学のイメージは「紙と鉛筆」です。 途中結果は紙に書きなぐられた数または式です。 これが他のなにかとごっちゃにならないように名前をつけておく、 というのが私の「数学の変数」に対するイメージですね。 たとえば z = x + y を考える時、私は「xとyという箱から値を取り出して、両者を足した値をzという箱に入れる」ではなく、 「x + yという式にzという名前をつける、今後zを見たらx + yのことだと思う」とします。lazyですね。
余談ですが、私の数学科の友人の恩師は「数学者には紙と鉛筆があれば良い」と言って、 コンピュータに否定的だったそうです。間違えないから消しゴムは要らないんですって。
kwatchさんが「箱」をイメージされるということは、 紙と鉛筆よりももっと新しいデバイスのイメージを持っておられるのでしょう。
というか、もうこうなったら初心者相手に実験するしか ないですね。
- 名札モデル
- 箱モデル
- IDを入れた箱モデル
初心者の選び方で全然違う結果が出そう。
C++について学ぶなら「箱＋名札モデル」が良いと思います。 ポインタについて学ぶ時には「IDを入れた箱(＋名札)モデル」ね。
しかし、今はRubyの話ですから、そんなもってまわった話をしなくても、 名札モデルで十分だと思います。
個人的にはRubyでlet x 100のような記法があれば 名札モデルの説明でしっくりくるのですが。 これなら、代入でなく命名、変数ではなくて名前 という用語で説明しやすい
えーと、なにか私の主張を誤解しておられるかもしれません。 私は「(Rubyにおける)変数とは結局は名前に過ぎない」と申しております。 ですから、「代入は命名、変数は名前」です。
ところで、Rubyって、複数の変数が同一の実体を指すこと無いのですか。参照渡しなんかも含めて。 複数の変数が同一の実体を指すことができると、それはそれで便利ですが、 Rubyではそうできなくなっている理由は何なのでしょう？
もちろんあります。ないのはC++のリファレンスに相当する「複数の名前で同じ変数を指すこと」です。
C++と比較するとRubyは一段少ないんです。
C++: 名前->箱->オブジェクト Ruby: 名前->オブジェクト
背景となる(言語が見せようとしている)モデルが違うんで、 同じモデルを使うことは良くないかも、というのが今回の話のもとなのです。
「名札」で違和感があるのは，「ary = Array.new」は「ある配列オブジェクトにaryという名前をつけた」ということですが，この「名前のないモノに名前をつける」ということが，あんまり日常では起きないからではないかとも思います。子供に名前をつけるときぐらい？
いや、プログラマの日常にはよくあるんじゃないですかね。
名前をつけることはもうすでに日常なのです。(笑)
ちょっと古いが、黒須教授のUser Engineering Lectureより。 CGIのためにPerlを使おうとしたら複雑スギ、Lispの方がよっぽどユーザビリティが高い、というような話。
CGIプログラムを自分で書く必要がでてきたので、Perlの解説書を読み始めたら、プログラミング言語の使いやすさについて改めて考えさせられた。これまで10種類近くの言語を使ってきたことがあるが、新しい言語に接するたびに、なんでここをこういう仕様に設定したのだろう、という疑問を抱いたものだった。プログラミング言語を設計する人は、ロジックの面では有能かもしれないけど、それを使う人間に対する配慮に欠けているんではないか、という思いを強く持ったわけだ。
基本的には言わんとしていることは分かる。 「プログラミング言語は使う人のことを考えていない」というのはよく感じることだ。 特にLarryはそういうところには気を使わない、というか、慣れればよいと思ってるみたいだし。
元々、言語設計者はユーザインタフェースやユーザビリティの研究者ではないので、 その辺の知見が足りないというのはありそうなことだ。
では、黒須教授はどのような言語が良いと思っているかというと、Lispなんだそうだ。
これまで使ってきたプログラミング言語のうち、私が一番気に入っている言語はLISPである。ある意味で大変原始的な言語であるだけに、とても自由度が高く、強力で、魅力的な言語だと思う。
(中略)
こうした単純さは、プログラムの理解を容易にすることに役だっていると思われる。
ここでLispとはなんと通な。
その後、Perlの仕様に対する文句とかが並ぶのだが、 Perlの仕様の話をしている最中にいきなりContent-Typeのフォーマットの話が出てきちゃうことは論外としても、 全体を通して読み終わった後、奇妙な違和感が残る。なんだろうか。
まず第一に「Lispはプログラムの理解を容易にしない」という点だ。
Lispは確かに単純だ。自由度も高い。強力で魅力的だ。「美しい言語」と呼んでもいいだろう。 しかし、だからといってLispで書かれたプログラムが他の言語以上に理解しやすいかというと そんなことはない。むしろはっきりいって読みにくい。美しいと使いやすいはかならずしも一致しない。 このことは根っからのLispファンであるPaul Grahamも認めている。
なぜLispのプログラムが読みやすくないかというと、理由はいくつかあって
などがあるだろう。ここ数十年積み上げられてきたプログラミング言語の伝統に沿っていないというのもあるかもしれない。もちろん、Lispはそんな伝統ができる前から存在していたのだが。
第二に、プログラミング言語は確かにインタフェースであるが、他のインタフェースとは少々違うかもしれない点だ。
インタフェースである以上、ユーザビリティの良し悪しがあるのは当然のことだ。 最初にいったようにユーザビリティにあまり配慮していない部分を持つ言語があまりにも多いのも事実だ。
しかし、他のツールのインタフェースが、ボタンを押す、メニューから選ぶ、というような非常に限られた 選択肢しか提供しないのに比較して、プログラミング言語は条件判断や繰り返しを含む異常に柔軟な指定ができる。 また、その表現すべき「仕事」も他と比べると圧倒的に複雑だ。 その結果、プログラミング言語自身も、大規模で、複雑で、習熟に時間のかかるツールである。 そういうツールのユーザビリティは、 「誰にでも使いやすい」を目指すいわゆる普通のユーザビリティとは違うかもしれない。
なにより違和感があるのは、プログラミング言語デザイナーの数を考えると、 本来この文章の対象になるべき人物(で日本語が読める)のは指折り数えるほどではないかと。
とはいうものの、ユーザビリティの専門家によるアドバイスを受けて設計されたプログラミング言語ってのも 見てみたい気がするなあ。
Debianのパッケージとして登場したアドベンチャーゲーム。ScummVMが必要。 海外では有名なゲームらしい。 私は普段はゲームをしない人なのだが、ちょっとためしに。
しかし、溶鉱炉から脱出した時点で、なにをしてよいかわからず早々に挫折してしまった。 そういえば、南青山アドベンチャー(古い...)も挫折していたような気がする。
えー、しかたがないので、googleして攻略情報を入手。ぜんぜん謎解きになってない。 こんな謎解けないよ。やっぱりゲームには向いてないらしい。
先日完了したプロジェクトの打ち上げに参加。
先方の会社の技術者の中には会ったことのない人もいたので、自己紹介。
まつもとといいます。 このプロジェクトでは... うまくいってる？、と声をかけたり、 後から暖かく見守ったり、 プロジェクトをネタに雑誌にXPの記事を書いたり、 宴会に参加したりしてました
結局、なんにもしてないじゃん。
みなさん、お疲れさまでした。次もあるそうですので、引き続き。
ステーク大会で、半日うちをあけてメールをチェックするとPOPサーバが反応しない。
調べてみると、1400通以上のSobigメールが届いていて、スプールが200メガを越えているので、 POPサーバが異様に遅いということのようだ。今時200メガ程度でこんなに待たせるPOPサーバも できが悪いとは思うが(solid-pop3dというもののようだ)、 用もないメールが大量に来る現状もなんとかしたい。
とりあえず、 なかださんのとこ経由で、 sobig_killer.rbを入手。
勘弁してくれ。
2日め。今度は家族を連れて新見に。
いろいろいい話を聞いた。残念なことはせっかく良い話を聞いても、 たいていは数日もすれば忘れてしまうということだ。 心(と霊)の奥底には残っていることを期待して。
集会終了後、子供たちは会場の噴水で水遊び。びしょ濡れになっていた。 今日は暑かったし、子供たちは会場でおとなしく我慢していたので、 ストレス発散になったようだ。
このことを見越して着替えを持ってきていたつもりだったが、 下の二人はしっかり忘れてきていることが判明。 裸のまま連れ帰ることになる。
で、うちに帰ってメールをチェックするとPOPサーバがまた反応しない。
調べてみると、1600通以上のSobigメールが届いていた。もういや、こんな生活。
これだともう、POPサーバが反応しない。何分待ってもだんまりで返事を返してこない。
仕方がないので、movemailで一度スプールを空にして、手元のマシンにコピーしてから、 分類する。手順は
サーバ側 movemail /var/spool/mail/matz mbox ローカル側 scp <popserver>:mbox /tmp/mbox formail -ds promail < /tmp/mbox
分類が終わったらmboxを消しておく。 ああ、めんどくさい。とりあえず寝ている間に同じことが起きないように、サーバ側のcrontabに sobig_killer.rbを仕掛けておく。
明日はフィルタを作ろう。
父: いやあ、いらないメールがいっぱい来て困るよ。 子(６歳男): だした人にいらないっていえば？ 父: 出した人も知らないんだよね(以下、ウィルスについて説明) 子: じゃあどうするの？ 父: 要らないメールだけ捨ててしまうプログラムを使ったんだ。 父: でも、これもまだ面倒で。自分でわざわざ捨てないといけないから 子: だったら、自動的に届かないようにできないの。 父: できるよ。今日、そうしようと思ってたんだ。
というわけで、フィルタを用意。 基本的にはsobig_killer.rbを削っただけなのでお手軽簡単。
#!/usr/bin/ruby
SOBIG_SUBJECTS = <<END.split("\n")
Thank you!
Re: Thank you!
Re: Details
Re: Re: My details
Your details
Re: Wicked screensaver
Re: That movie
Re: Your application
Your details
Re: Approved
END
SOBIG_SUBJECTS_R = Regexp.new('^(' + SOBIG_SUBJECTS.join('|') + ')$')
header = STDIN.gets("\n\n")
size = STDIN.read.size + header.size
exit 1 unless header =~ /Subject: (.*)\n/
subject = $1
if subject =~ /RAV AntiVirus scan results/
exit 0
end
if (310000 < size || size < 100000) and
not header =~ /^Content-type:\s*multipart\/mixed/i
exit 1
end
if SOBIG_SUBJECTS_R =~ subject
exit 0
end
exit 1
あとは、.procmailrcに以下のルールを追加する。
0HB: * ? /usr/bin/ruby /home/matz/sobig_filter.rb sobig
勇気があれば(？)、「sobig」の部分は「/dev/null」でも良い。 実際には私はそうしている。これで迷惑なメールを見ないですむ。
nobusunからツッコミをいただいたが、ちょっと考えさせられるものがあった。
LISP が読みにくさは、慣れの問題ではないでしょうか。
うむ。しかし、「慣れ」については、いくつか気になることがある。
まず第一に、Lispを知って数日の人に「Lispわかんない」と言われた時の反応としては、 「慣れの問題」というのは適切かもしれないが、 私はLispに関して決して初心者ではない(上級者だとも言わないが)。 数千行のLispプログラムを継続的にメンテしていたこともある。 それでもなお読みやすいとは思えない人に「慣れの問題」というのは不適切ではないかと。
第二に、ユーザビリティの話をしている時に「慣れ」の話は反則ではないだろうか。 人間の適応能力はすばらしいものがあって、どんな悪いものでも、 強固な意志をもって、ある程度時間をかければたいてい慣れることができてしまう。 しかし、そんな「慣れる苦労」を少なくしようという試みがユーザビリティではないだろうか。
では、「慣れ」の問題を排除して考えると、はたしてLispは使いやすいか。
nobusunは以下のように述べておられる。
すくなくとも Scheme については以下のように思います。
- 表現の種類がすくなくても、抽象化力が強いので、「冗長」というよりは「簡潔」である。
- データ部分とコード部分を区別しないでいいのは利点。
- 閉鎖的というのは、最近の実装にはあてはまらない。
- マクロについては、たしかに別の言語を許すようなものですが、簡潔に書くためには便利。
- 本来複雑なプログラムを如何に抽象化するかが、読みやすさにつながる。抽象的な表現力がつよい言語で記述できるほど読みやすくなる。
Lispの冗長さについてはPaul Grahamの「Being Popular」(翻訳)にもある。端的には
a = b[x,y]
と
(set! a (aref b x y))
の違いだ。 この冗長さは細かいことではあるが、プログラマに与える精神的な負荷という点では無視できない。
「データ部分とコード部分を区別しなくていいのは利点」というのは、 マクロ以外の点では成立しないのではないかと思う。 そして私はユーザビリティの観点からはマクロに否定的だ。
では、言語のユーザビリティはなにによって決まるか。続きはまた明日(おいっ)。
まず、ともさんのツッコミへのお返事。
Windows に未だ慣れることができない私としては、『「慣れる苦労」を少なくしようという試みがユーザビリティ』というお言葉には同意できないかも。
えーと、論理がよく分かりませんでした。私もWindowsには慣れることができてませんが。 この文を解釈すると「Windowsはユーザビリティが高いはずだが、慣れる苦労は大きいぞ」 という意味に読めるんですが、それはfalse assumptionかも。
それはともかく、ABC 順とかあいうえお順のキーボードとかは初心者対応かもしれないけど、ユーザビリティは高くないと思います。
ええ。「初心者にも優しい」と「初心者だけに優しい」は混同してはいけませんよね。 今回はプログラミング言語のユーザビリティについて考えていますが、 プログラミングが本質的に複雑で、その結果プログラミング言語も習得にそれなりにコストがかかるものである以上、 「初心者(だけ)に優しい」ユーザビリティは不要だと考えています。
ところで、中置記法が前置記法よりも読みやすいのは数学教育のせい、即ち、慣れの問題じゃないでしょうか？
違います(きっぱり)。これは「常識(or 伝統)を活用する」という立派なテクニックです。
「慣れ」との違いは個人的かどうかですね。どんなツールでも慣れることはできますが、 その「慣れ」は個人にとどまります。しかし、数学的記法のような広く使われ受け入れられているものは、 個人の範囲を越えてユーザビリティ向上のために用いるに足る「常識」として利用できると思います。
次にshiroさんのツッコミへのお返事。
ひとつだけ、ユーザビリティの議論は、どういうユーザを対象としているかを明示しておかないと無用の混乱を引き起こすと思われますので、そこは何卒宜しく。
もっともです。
ですが、正直なところプログラミング言語のユーザビリティについては客観的に評価を行うために必要な 研究などの蓄積はないと思います。ですから、現状では「私にとってはこうするのが良い」と提示し、 それに賛同するか、反対するかで議論を深めていくしかないと思います。
あえて対象を明示するならば、「現代的なコンピュータ(と数学)の基礎知識を持っているプログラマ」でしょうか。 より具体的には「わ・た・し」です。
先日、「南青山アドベンチャーも挫折した」と書いたが、 その後、記憶をたどるとどうやら私が遊んだ(そして挫折した)のは、その1年前の 表参道アドベンチャーだったようだ。
で、googleすると攻略法が。 コマンドを見てると懐かしい....。
当時Googleがあったら挫折しなくても済んだよなあ。 もっともそれではちっともゲームにならないような気もするが。
それはともかく、攻略法であらためてストーリーを読むととてつもなくつまらない。 こんなくだらない(失礼)ことにのめり込んでいたかと思うと 過去の自分に対して怒りを覚える部分もあったりして。
昨日の続き。
まず言語のユーザビリティを考えるにあたって、ふたつほど明らかにしておかねばならない点がある。
第一には、言語のユーザビリティの定義だ。 ここでは言語のユーザビリティを以下のように定義する。
この二点に優れた言語をユーザビリティが高いとする。 もしこの二つが矛盾した場合には、(私だったら)後者を取る。
次には「万能の言語はない」という点だ。
プログラミング言語はたいてい設計者の予想を越えて適用範囲が広がる傾向があるが、 しかしあらゆる分野に完璧に適合する言語もなければ、あらゆる人にとって使いやすい言語もない。 ある局面では非常に便利な機能が、いつも役に立つとは限らない。
それゆえ、トレードオフについて考慮する必要がある。 たとえば、ある言語がある分野について別の言語より劣るとしても、 その劣る分野がわりと特殊で、 日常的に使う領域では別の言語より圧倒的に使いやすい場合、 しかもその分野によく適合するために普段の使いやすさを損なう可能性があるならば、 今のままにしておいた方がトータルのユーザビリティは高いということになる。
さて、これを前提としてLispを考えてみよう。
なぜLispを題材にするかというと、Lispが優れた言語だからだ。
Lispはながらく生産性の高い言語として、ある種の「秘密兵器」の地位を保持してきた。 Lispの生産性はなにに由来するのか、それは(私の感じる)Lispのわかりにくさとどう関係しているかを 明らかにすることで、可能であればLispよりもユーザビリティが高い言語、 いいかえれば「Lispの生産性を持ちながら(私にとって)わかりやすい言語」が 存在しうるか、もしそうであればそれはどのような言語かということを明らかにしたいと考えている。
Lispの生産性の高さの原因はなんだろう。
くらいだろうか。
最初の4つは最近の動的言語も備えているものが多い特徴だ。 もっとも、真の「統一的なオブジェクトモデル」を実現している言語は意外に少ない。 最近の言語だとSmalltalk(は最近じゃないか)、Ruby、Python(はちょっと苦しい、改善されつつある)くらいか。
「ダイナミズム」は説明が必要だろうか。つまり動的にクラスを定義したり、 プログラムを拡張したりする機能だ。 これがあると実行時にプログラムの振る舞いを変更したり、実行中にデバッグしたりするような 離れ技が使える。
Lispに特徴的な点は後のふたつ、つまり「S式」と「マクロ」である。 S式はつまりプログラムとデータが同じフォーマットであることを意味し、 マクロは文法をユーザが好きにプログラムできることを意味する。
これらは生産性に寄与するか。わかりやすさにはどうか。
私の考えでは、最初の答えはYes、後の答えはNoである。
これも昨日述べたが、S式は冗長である。専用の文法を用いた方がコンパクトな記述になるし、 その文法を学習するためのコストはさほど高くない(よっぽど変な文法でなければ)。
それを取り返すための武器がマクロである。 マクロを使えば自分専用の制御構造も簡単に定義できるし、 関数としては抽象化できないものも抽象化できる余地がある。
つまりLispはS式による冗長さを文法をプログラマブルにすることで克服しようとしているわけだ。 そして生産性(≒記述のコンパクトさ。Paul Grahamによれば)の向上という点ではある程度成功していると言えるかも。
ではわかりやすさについてはどうだろう。
あるプログラムがわかりやすいかどうかは、私の考えによれば、 「あるコードを見た時にその意味を理解するコストが低い」かどうかで決まる。
Lispはこの点では不利だ。
S式の単純さは読み下す時のヒントが少ないことを意味する。 すべてがS式なので、ここはデータ、ここはロジックという情報もプログラムの字面からは得られない。 ヒントが多ければ良いというものでもないが、あまりに少ないのはつらい。
また、生産性の向上に寄与したマクロは、任意に定義されたユーザ言語を定義することと等しいので、 このプログラムが利用しているマクロについての十分な知識がなければ、 コードの構造も理解できないことになる。
結論としては、
であり、タチの良い動的言語であれば、Lispと同等の生産性を、よりわかりやすく実現できる可能性がある、 というものだ。
ま、Rubyの設計者の私の結論としては妥当なものだろう。
さて、これは私の結論であるが、別の意見を持つ方も当然いらっしゃるだろう。 これをきっかけに議論が深まればよいと考えている。
強力で美しいにもかかわらず、Lisp がまつもとさんにとって読みにくい原因は、まつもとさんの中にあるプログラムのモデル(思考パターン)と、それを記述する言語としての Lisp との相性が良くないのだと想像します。逆に私にとって Scheme の方が読みやすいと思うのは、私の持つモデルと Scheme との相性がよいということです。
これはどうなんだろう。 私はかならずしも「(私の)思考パターンとLispの相性が良くない」とは思わない。 私は上で「思考パターン」という概念を用いずに、 「Lispは(私の定義する)ユーザビリティにとって不利」ということを示してみた。
「データ部分とコード部分を区別しなくていいのは利点」というのは、「関数指向のモデルを持つプログラマにとっては」ということです。
これもよくわからない。もしこれが事実だとするならば、なぜHaskellやMLはS式を用いないのだろうか。 逆にLispは関数的にも書けるがその実体は単なる手続き型言語だし。
はあ、自分のもつ思考パターンとの相性が良いことと言われても、それって結局「私、この言語が好き」ってことじゃないですか。
それでは議論がちっとも深まらなくって、(私にとっては)意味がないです。
で、たぶんセマンティックスとシンタックスを別々に考えないといけないんじゃないかと思います。 これを明示しなかったのが失敗だったか。
今の私はシンタックス(記法)のことだけを考えています。 言語のシンタックスがその言語の使いやすさにどのような影響を与えるか、ということです。
ですから、私が「データと関数を区別しない」というのは当然「データの表現とロジックの表現が同じ(S式)」という意味です。nobsunがどう解釈されたのかは知りませんが。
記法の問題について十分に考察した後で、もしかしたら「オブジェクト指向型と関数型のユーザビリティ」のような セマンティックスのユーザビリティの話に進むかもしれませんが、それは未来の話。
追記:
nobsunがきれいにまとめてくださいました。
ところで、nobsunはもしかして「nobsunさん」と表記すべき？
しかし、こんなことをやっている場合では無かった。〆切が3つ、さらに英語のプレゼンの準備までひかえている。 ちょっとあせり気味。
キリキリしたからといって仕事が進むわけじゃない、時間よりも発想の問題なんだから、 と自分に言い聞かせ、温泉に入ることにする。なんだか久しぶり。
しかし、タオルやら着替えやらを自宅に忘れてくるというおおぼけぶりを発揮し、 抜けていることをまたもや家人に露呈してしまった。６才児に「しょーがないなあ」と言われるのは 屈辱感がある。
えー、三連休の初日ということで家族サービス。 この夏は寒くて泳ぎにも行かなかったので、プールへ。 子供たちは泳いだり、ウォータースライダーで遊んだり。 私は基本的にお湯につかっていた。
〆切前にこの余裕の行動は...そうです。逃避ってやつです。
レポートは提出した。
私は「Lispのマクロ」が悪だなんて言いません。あれはあれで便利なものです。
でも、「普通の人」に対するユーザビリティを下げる可能性があるとは思います。 だから、「普通の言語」には要らないかもしれない。
要はトレードオフですよね。使いこなすのが難しいが強力なものを目指すか、 普通の人が普通に使うぶんには使いやすいものを目指すか。
私は、Lispを研究することで
などを知りたいと思っているだけで、Lispがだめとか、Lispを変えようとか思ってるわけじゃないです。
だからLisp好きは自分の立場を擁護する必要はありません。
朝から会議。〆切が迫っているのに..(以下略)。こればっかり。
でも、レポート以外は全部自分が引き受けたことなので、文句を言う相手がいない。 愚痴を聞かされる妻はかわいそうかも。
疲れたので原稿には手をつけず寝てしまう。
娘が「おばあちゃんに会いたい」と言うので昼食を両親と一緒に。 敬老の日なので、なのかな。
もっとも、母親にうっかり「おばあちゃん」なんて声をかけようものなら、
あんたのおばあちゃんじゃない
と怒られてしまうのだけど。まあ、今時の60代はあんまり年寄りに見えないよね。
私がまだほんの小さかった頃に祖母と写った写真があるのだが、 この写真の中の祖母はほんとうに「おばあちゃん」って感じだった。 が、今計算すると当時の祖母は今の母よりも若いことになる。 うーむ、白黒写真や和服のせいではないと思うのだが。
で、昼食はバイキング。焼肉、寿司、スパゲティ、ラーメン、うどん、etc. 今日は体重のことはあまり考えないでおこう。
昼食後は子供を連れて公園に。ひとしきり遊んだら、すっかり疲れてしまった。
原稿..(以下略、笑)
よそで議論するのもなんなので、こちらにもって来よう。
まず、shelarcyさんの意見:
またマクロを間違いなく使えるようになるのと、オブジェクト指向を身につけるとどちらが難しいでしょうか？ もしマクロを使いこなす難しさがほぼ同等あるいはオブジェクト指向より容易であるなら、今のところはマクロを普通の人が使う言語に組み込んでも構わないのではないでしょうか？
私に限って言えば、オブジェクト指向を身につけるのが難しいと思ったことはないが、 マクロを間違いなく使うのはいまだにできないので、 答えは明らかだろう。(笑)
もっとも、これはフェアな比較ではないと思う。 パラダイムと言語の一機能を同格にするべきではないからだ。
繰り返しになるが、私はLispのマクロをどうこうしようというわけではなく、 新しい言語を設計するとして、その言語にマクロを追加することについて ユーザビリティの観点からのトレードオフを明らかにしたいだけだ。
Lispマクロの利点については理解しているつもりだ。
しかし一方で、
という点がある。
だとすると、プログラムを書くフォーマットとして「S式＋マクロ」と「より普通の構文」の いずれかを選べと言われたら、私はマクロをあきらめて普通の構文を選ぶ。
と、ここでshelarcyさんはこう来る。
あと、もう少しツールの存在に目を向けても良いのではないでしょうか？ 例えば、初心者には絶対にマクロを使わせたくないというのであれば、設定をいじらなければマクロを使えないようにしたり、ライブラリをインストールする形でしか使えないようにするといったような障壁を置いたり、ある種のマクロをフィルタする仕組みを持っている処理系(きちんとした形でマクロを使えるようになるまでテスト以外でマクロが有効にならない……っていうのは流石に実現が難しいでしょうけど)、S式についても XML のエディタのようにソースはS式だけど表現上は別の記法でそのまま編集できるのモードとS式で表示・編集できるソースモードを切り替えて使うことのできるエディタなどを想定して、そういうものがあれば受け入れられるかどうかという議論がなされないと実質的なユーザビリティから乖離してしまう恐れがあります。もっとも、本当はテストした方がいいのですが。
おっしゃることはもっともだ。 私は言語屋なので言語そのものに強くこだわってしまう傾向があるのを見透かされている。 IDEとか嫌いだし。
ただ、過去の言語の歴史の中で「ソースはS式だけど表現上は別の記法で」というアプローチは それこそ星の数ほど行われてきたのだが、生き残ったものはほとんどないという事実は、 私に「言語はその記法が重要である」という原則を教えてくれているように思う。
マクロという問題に限定すると、やっぱりS式を隠してはマクロのパワーを損ねると思うので、 ここであげられたようなツールではマクロとユーザビリティの両立は難しいのではないだろうか。
で、マクロが役に立つケースのかなりの割合は、高階関数で実現できる。 Rubyでは限定された高階関数が呼びやすい文法(ブロック)を導入することで、 ある程度支援しているつもりだ。
だから、
Ruby はイテレータなどで工夫しているなと思うのですが、繰り返し以外の用途でイテレータを使っている例などを見ると、マクロっぽい使い方をしているように思えるのですが、...
というotaさんのツッコミは鋭い。
それからshiroさんは、
このプログラム片の外側で、near, far, lerpといったマクロやグローバルな束縛が定義されたとしても、このプログラムの意味は変わりません。
(中略)
しかし、予約語の場合、例えばnear, farという識別子が予約語に追加されたとたん、上のようなプログラムは破綻します
と予約語の増加とマクロを比較しての優位性を述べておられる。
このマクロの良い性質についてあまり意識していなかったので、教えていただいたのはありがたいのだが、 予約語が安易に増えるような言語はそもそもユーザビリティの観点からは最低だと思うので、 比較の対象にはならないのではないかと。
ただ、その前に述べておられる
プログラムの読みやすさ、書きやすさを決めるひとつの重要な属性は、あるプログラム片を目にしたときに、その意味に影響を与える範囲が限定され得るということ、したがってその範囲さえ見ていれば、プログラム全てに目を通さなくてもそのプログラム片の持つ意味が完全に理解できること、だと思います。
という意見には完全に同意する。今後もこの原則は心にとめて行きたい。
〆切について愚痴ばかり書いていたので、心配されていた方も、もしかしたらいらっしゃるかもしれませんが、 一応ちゃんと終わりそうです。
まだ、あとふたつほど残ってますが、これもなんとかなるでしょう(希望的観測)。
東京に移動、東京事務所でインタビューを二件受ける。
午前中は日経バイト。11月号で「オープンソースの行く末」という特集を組むそうで、 オープンソース開発者のひとりとしてインタビューを受ける。
など。11月号の発売日は10月22日の予定。
午後は経済産業省からの依頼で三菱総研の比屋根さん(と同僚)とテックスタイルの風穴さんから。 内容はかなり重複している。
インタビューの結果は(名前がわからない状態で)公表されるそうだ。 また、風穴さんは独自に雑誌記事を書く予定。
４時間ぶっ続けのインタビューは体力的につらい。体力ないの。
日帰り。松江へ。
推薦する本を尋ねられたので何冊か挙げたのだが、 『4844317210』だけは 「古典ではないだろう」という理由で採用されなかった。残念。
私があげた残りの「名著」は以下の通り。
うちの隣の息子さん(5歳)は『4844317210』の著者 あおきさんにそっくりだ。
ふたつめの原稿も無事しあげたが、完成したのが朝４時だったため、 午前中はまるまる寝てしまう。もったいない。
で、残るはJAOOのプレゼンの準備なのだが、 いっこうに進まない。まあ、まだもうちょっと時間があるのでなんとかなるかな。 なるんじゃないかな。なるといい..な。
妹の子が泊まりに来る。異様に元気のいい子なのだが、ひとばん無事に過ごせるかしら。
高林くんが始めたソフトウェア特許MLに参加する。
なんか、自分が如何にいいかげんな知識しかないかを再確認する。 もうちょっと調べないといけないかなあ。
現時点での私の意見は「特許なんてない方が良い」なんだけど、現実的ではなさそう。
「読んだものの記録」において、 ソフトウェア特許の議論について懸念が 表明されている。
非常にまずい
今までのパターンどおり、ソフトウェア特許は悪です。period。で終わる可能性が高い。口上にきわめて問題がある。バランスが取れた議論が出来そうにない。
(中略)
ただ、これ(自分の発明はすべて公共なもの、という崇高な思想)を全面的にソフトウェアに適用したとき、あまり嬉しくない社会が待っているとしたらどうか？ 少なくとも我々は資本主義の世界に生きていて、少なくとも特許という社会制度は社会制度は100年以上も有効な(ここでは実効性があると言う意味)システムとして機能して来たのだ。すくなくとも、特許がソフトウェアに対して、どのような取り扱いをしてきたのかぐらいの調査と、その資料は、口上に入れて欲しかった。その上で、ソフトウェアに対しての特許制度を否定するというのであるならば、よかったのであるが。
himiさんの懸念はある意味もっともだ。
しかし、口上にそれが必要とまでは思わない。 口上にそこまでの準備を要求するのなら、気軽に議論をはじめられないと思う。
それはともかく、 私としても「ソフトウェア特許は悪です。period」という単純な結論は希望しない。 現時点では、ほかの多くのフリーソフトウェア関係者と同様、特許、特にソフトウェア特許に関して否定的な印象を持っている(というか、特許が過去100年以上存続したのは厳然たる事実としても、その間ずっと有効であったかどうかということには疑問を持っているのだが)。
しかし、私の知識が足りないための思いこみや誤解の可能性は排除せずにいたいと思うのだ。
よって、「特許がソフトウェアに対して、どのような取り扱いをしてきたのか」という情報は常に大歓迎だ。
ところで、「自分が開発したソフトウェアでゲットリッチ」という希望に対して 特許は本当に有効に働くのだろうか。
あるいは「自分の発明でゲットリッチ」という希望に対してはどうだろうか。
上記のように気軽に書いたらご本人に反応していただいた。読まれてるって怖いわ。
私が、この話で、口上というか導入を気にするのは、プロパテント、アンチパテントの括りに入れられるのがとっても怖いということも、理由の一つに挙げられます。実際、高林さんの文章は、誰がどう見ても、アンチパテントの枠内に入れられてしまうと思います。
その意味でも、ここで何らかの有益な議論を起こしたいのならば、なおさら特許自身の事前調査が必要だと思います。
えーと、たぶん私とhimiさんでは「議論」という単語に期待しているレベルが違います。
himiさんの議論は、賛成側・反対側ともに十分な知識をもって、 どうあるべきか、今後どうしたらよいかを「議論する」というレベルだと思います。 実に実りあるレベルで最終的にはそうあるべきだと思います。
しかし、私が言ってる「議論」はそういう知識の収集や情報の提示も含めたやりとりを考えています。 だからきっかけになりさえすれば、口上そのものは中立である必要を感じてませんでした。 レベルが低くてすみません。
「そんなのは議論じゃない」、「先人の考察を無視する気か」というお叱りを受けそうですが、 この機会に人々の関心を集め、情報を集積したいと考えています。
というか、私自身が「そもそも特許とは」という知見を形成したいという魂胆が透けてみえてますね。
ちなみに、100年以上有効であったというのは、usefulの意味ではありません。 U.S.で特許法が成立したのは1790年にさかのぼり、その間、ずっとeffectiveであったことはそれほど疑わしい事実ではないと思います。もちろん、 usefulであったかどうかには疑義がたくさんあると思います。
あと、effectiveとusefulの対比については、私、英語が苦手で*1よくわからなかったのですが、usefulが「役立つ」だとすると、 「有益ではなかったかもしれないが、特許制度そのものは100年以上成立し続けてきた」という意味ですか？
ああ、「実効性」ってそういう意味でしたか。 いかん、日本語もちゃんと読解できないらしい。
こんなに効率が悪いのにもかかわらず、企業が特許取得に投資する理由はなんなのか? このことはよくよく考えてみる必要がある。
それが私の一番知りたいところなんです。これが理解できれば、私にも特許の意義が理解できると思います。
*1 なのに来週英語でプレゼンするんだから、まったく
昨日から泊まりに来ている姪が元気よく遊んでいる。 2才児にはコンピュータが大変珍しいらしく、PCを開けていると邪魔しに来る。 当然、プレゼンの準備はできない。
自宅にいても騒がしいだけなので、近所の水族館に出かける。 宍道湖周辺の生物を集めた小さな水族館である。 まあ、気晴らしになった。
夜は夜で、Linux Magazineの原稿が足りなかったぶんを書き足したり、 明日の日曜日の準備があったりして、さっぱりプレゼンは進まない。 まあ、いままでもこうやって〆切に追われてもなんとか片づけてきたので、 最終的にはつじつまを合わせられると思うけど、プレッシャーとストレスは高まる。
ところで、こんなことして原稿書きばかりしてるからRiteとか進まないんだろうか。
笹田さんが仮想マシンの実装でdirect jumpとswitchの比較をやっておられる。 このdirect jumpで
#define NEXT() goto *((void *)(codes[pc]))
となっている部分を、ラベル直後で
#define NEXT0() addr = (void *)(codes[++pc])
実際の処理後の分岐では、
#define NEXT1() goto *addr
とすることにより、Pentium IIIでは最大2割くらい速くなるみたい。え、そんなに？
勉強になった。
今日は米子の訪問の割り当て。お話は「先祖の救いと神殿」について。 山口の姉妹から聞いた話、というネタを披露したのだが、弟には妻の話であったとわかったみたい。
監督さんと話したり、いくつか連絡をしてから帰る。
出発前だということで、実家によって父親から祝福を受けた。 文字どおり族長の祝福だな。
JAOOに出席すべく移動開始。成田で一泊。 でも、東京で泊まった方が楽だったなあ。
「議論のレベルのことを言いたかったのではありません」ということは、また読み違えたのですかねえ。すいません。
しかし、
確かに、普通の技術的なmatterであるならば、そういう素朴な問題提起は、たいした問題にならないのかもしれません。しかし、今回の場合は、企業間、国家間で、まさにドンパチやっている問題に対して、きわめてnaiveな(あえてこの言葉を使う) アンチパテントの主張を使って議論を呼びかけたのです。これが、日々、企業でソフトウェア技術者として生きているであろうと思われる参加者に対して (だって今は資本主義ですから)、ある種の踏み絵---ゲットリッチ(ほんとうにいやな印象を与える言葉)のために卑俗な独占欲を持つのはおよしなさい---を迫るのではないかということについて、認識が、あまりにも足りないのではないかと思うのです。
という懸念についてはまだよく理解してません。
結局、「アンチパテントの主張を使って議論を呼びかけ」ることで、 「参加者に対してある種の踏み絵を迫る」ことになり、 議論の場がアンチパテントな人だけが集まる場になってしまい、 結局「(ソフトウェア)パテントは悪」というその場限定のありきたりな結論が出てしまい、 議論が深まらないってことでしょうか。
でも、議論を呼びかけた人が明らかにアンチパテントだからと言って、 「参加者に踏み絵を迫る」ことになるとは考えていませんでしたし、 実際あきらかにそうなっているという印象は持っていません。
Wikiに集まった情報も役に立っていますし、議論のきっかけはともかく有意義な動きではないでしょうか。 私を含む参加者が特許そのものについてまだ知識が足りないことが目立つのはありますが。
私自身は「アンチパテント」という立場に決めているわけではありません。
というようなレベルです。ああ、やっぱりnaiveすぎ？
成田空港は去年シアトルに行った時に使ったきりだったのだが、 WiFiが有料化してたりしてせちがらい。普及したというのも考えものだ。 たった数時間のために24時間のアクセスパスを買う気にはならないしなあ。
成田空港からエール・フランスAF275便でまずフランス・パリ・シャルル・ドゴール空港へ。 機体はB747-200。一番後から二番目の席で二席占有して眠れたのはラッキーだった。 スチュワードがDan Sugalski似だった。
今回は(ようやく)プレゼンの準備をしたり、寝たりしてたので映画は見れなかった。 もっとももともと面白そうな映画ではなかったのだが(『Down with Love』と『たそがれ清兵衛』)。
この空港は広い。成田の5倍くらいあるんじゃないだろうか。 さんざん歩くことになるが、羽田と成田の距離を考えると妥当かも。
次にAF1250便でコペンハーゲンへ。機体はエアバスA320。
コペンハーゲン空港で迷う。ここは前回に来た時もさんざん迷った。 ユーザビリティに問題があるんじゃないかと思う。 時刻が遅いせいもあるが、国際線ターミナルから国内線ターミナルまでの長い通路にはだれもいない。 無気味。
コペンハーゲンの国内線ターミナルも無線LANが有効だった。意外。 でも、ここも有料なのだった。
コペンハーゲンからオーフスへ。スカンジナビア航空SASのSK3449で。 機体はATR42/72(どっちだろう)という聞いたこともないプロペラ機。 定員は50人くらい？ 席は自由に選んで、というおおらかな運用。 乗客に飲み物を配った後、コックピットにも飲み物を運ぶスチュワーデスというのもおおらかな。 わずか25分で到着。
オーフス空港からホテルまでバス。馬鹿でかいバスなのに、なぜか乗客は私一人。 タクシー気分で運転手と話しながらオーフス市街まで４０分。 オーフスでは今週はバドミントンの国際試合もあるそうだ。
ポートランドで信号が面白かったので、今回は信号も気をつけてみよう。 デンマークの信号は赤から青になる前に一瞬黄色に変わる。 スタートが機敏にできるかもしれない。
バスの中のサインがユニーク。「禁煙」はまあ普通として、 そのとなりの「禁アイスクリーム(だと思う)」、とか「禁ソーセージ(だと思う)」は デンマークならでは、なのだろうか。となりのビンのサインは 「禁アルコール」かな。画像は後日アップロードしたい。
で、ホテルに着いたのが夜中の12時。自宅を出発してから３６時間後。死にそう。
プレゼン原稿表示用のマシンとして、古いリブレット30を持っていっていたのですが、 ホテルに着いた後、充電するべくACアダプタをコンセントにさすと「ばちっ」という音とともに 部屋のブレーカが落ちました。 真っ暗。実際にはヒューズが焼き切れてたみたい。
フロントに電話して、ヒューズを交換してもらってから確認すると、 リブレットのACアダプタは100V専用でした。デンマークは240V。 負荷がかかりすぎてACアダプタが焼けたようです。 これでリブレットは(すくなくともデンマークにいるあいだは)おしゃかです。
Let's NoteもVisorもExlimもアダプタは100〜240V対応だったので、 きっとリブレットもそうだろうと油断してました。
えー、海外ではプラグの形状だけでなく、電圧にも気をつけましょうと言うお話。
JAOOっていうのはデンマークのローカルなコンベンションだと思うのですが、 どういうわけか講師陣が異常に豪華です。
今日見かけた人々は(みかけた順)
まだまだ有名人に会えそうです。ううっ、例によってかなりミーハー。
C++はさらに拡張するそうです。すごすぎ。
ホテルの部屋でデンマークのテレビを見ていると、 海外、特にアメリカの番組をそのまま持ってきているものが多いようだ。 見かけたのは『Charmed』、『Sex and the City』、『Discovery Channel』など。 どれもデンマーク語でクローズドキャプションのようなチープな字幕がついている。 字幕が気になって英語に集中できない。 ロゼッタストーンでも解析している気分。
前回来た時(2年前)には英語のみ字幕なしという番組も結構あったと思うのだが、 今回は見かけない。
番組の中にはデンマーク独自のものもあるのだが、それほど発展しているようではない。 わたしが見かけたのはコマーシャルばかり。 まあ、人口もさほど多くないはずだし、外国に依存するのも無理もないとは思うのだが、 それならなおのことJAOOは謎だ。なんでこんなコンベンションが存在できるのか。
Simulaがスウェーデン生まれということで(あ、C++のBjarneもそうだ)、 北欧は全般にオブジェクト指向に対して関心が高いということはあるかも。
夜はオーフス市役所でパーティ。 市長さんだか市会議員さんだかが演説してくださるのだが、 英語は難しいし、聞き流す。オーフスは人口30万のデンマーク第二の都市で...とか話してたみたい。
JAOO学生ボランティアに聞いたのは、 先週コペンハーゲンでやはりJavaやオブジェクト指向に関するカンファレンスがあったのだが、 人が少なくて大変だった、とのこと。そりゃ、次の週にこれだけ有名人が集まる カンファレンスがあれば、そっちに出席するよなあ。
Martin Fowlerに紹介してもらったThoughtWorksの人たちと 話をする。彼らもRubyを使っているそうだ。
うちは人を募集してるんだけど、こない？
勤務先はうちののオフィスがあるところなら、アメリカでもイギリスでもインドでもいいよ
とか、本気なのだかよくわからないような誘いを受ける。
その後、Ward Cunninghamと「immortal wiki」の話をする。 immortalとは「不死」という意味*1で、 つまりサーバがダウンしたり、 運用をやめたりしても存在し続けるような分散Wikiは可能か、とかいうような話。
更新はどうするの、とか、 nntpを使って、各ページをニュースグループと同じ扱いにすればいいんじゃないか、 とかいろんなアイディアが出ましたけど結論は出ず。
「分散ならDoug Leaだ」とばかりにDougを巻き込んで話したんだが、 難しいなあ、で終わってしまった(みんな酔ってるし)。 あまりに眠いので途中で失礼して部屋に戻ったのだが、 後で聞いたらやっぱり結論は出なかったそうだ。
パーティには日本人のように見える人を一人見かけたのだが。話せなかったのが残念。 あと、Bjarneとも話せませんでした。次の機会を狙おう。
*1 immoral wikiという冗談はその場でもありました。
こっちの時間で夜中から早朝にかけてプレゼンの準備をした。 スライドそのものはほとんど飛行機の中で完成していたのだが、 なにぶんスライドを見るだけで英語でしゃべる、なんて真似はなかなかできないので、 原稿を書く必要があるのだ。
いや、実は去年まではスライドとそれに書きなぐったメモだけで勝負していたのだが、 毎回さんざんな思いをしていたのだ。で、OSCONからは英語で講演する時には しゃべる内容を全部書き出すことにした。 聴衆の顔を見ながらはなすのが難しいのが欠点だけど、内容がめちゃめちゃなのよりはマシということで。 もっと早く反省しろよという感じだけど。
で、この原稿を表示しようと思ってリブレットを持ってきてたのだが、 昨日の事故で ACアダプタが死んでしまってどうしようか、と思っていたのだ。
そしたらThoughtWorksのスタッフから 彼の東芝ラップトップのACアダプタを借りることができた。ラッキー。
で、プレゼン。tutorial roomという二番目に広い部屋(200席くらい)を割り当てられたので、 どうしようかと思ったが、あらかた埋まっていた。びっくり。
ちなみに一番広いのがConference Hallでこれは1000人くらい入りそう。 あと、すこし小さい部屋が3つあるのだが、 今回はそれぞれprivate room, public room, protected roomと名づけられている。 Bjarnがくるって言うんで洒落で付けたみたい。 最初「private room」と言われてなんのことかわからなかったんだけど、 protected roomまで見てやっと分かったっていう。
プレゼンテーションは前半は例によって原則と哲学について、 後半は1.8や1.9, 2.0について。後半についてはLL Saturdayで話したのとほぼ同じ。
プレゼン資料はここに置いておく。
まあまあの反応だった。４５分割り当てられてしゃべってる時間が４３分だったので、 あまり計算していなかった割には良い出来だ。
「スライドにRubyのコードがあれば良かったのに」という声があった。 確かに1行のコードもない。 Rubyを知らない人もたくさんいたはずなので、その方が賢い選択だったよね。 毎回、同じことを言われているような気がする。
講演後、Artima.comのBill Vennersからインタビューを受ける。 そのうちArtimaのサイトに載るんじゃないだろうか。
なんだか与太話をいっぱいしたような気がするんだけど、これで良かったのか。
プレゼンも終わり、インタビューも終わり、解放された気分。
Speakerはカンファレンス主催者からディナーに招待される。 食事について心配する必要がないのがこのカンファレンスのいいところだ。
参加した講師陣に聞いてもほとんどの人たちは
とべたぼめ。カンファレンス関係者は食事に気を使った方がいいと思う。 その点でLinux Expo Parisは最悪だった。いや、それ以外の点でも最低最悪だったんだけど。
あと、このカンファレンスは講師陣でも聞いてみたいというセッションが多いのもある。 セッションによっては質問するのはアメリカから来たほかの講師たちばかりだったなんても珍しくないし。
行ったのはイタリア料理のレストラン。 個人的には日本の料理のほうがおいしいと思うけど、まあこれは個人の好みだろう。
とうとうBjarneと話をする。一緒に写真も撮った(ミーハー)。
で、11月にRuby Conferenceでテキサスに行くと話したら、じゃあ前日にうちの大学に来て (彼は今Texas A&M Universityの教授)学生と話しないか、と誘われた。空港まで迎えに行くよ、とも。 望むべくもない嬉しい申し出なんだけど、酔ってるせいじゃないか、と疑ってみたりして。
BjarneはこのAarhus出身なのだそうだ。「俺のホームタウンはどうだ、いいだろう」という感じだった。 気さくな人だ。
「C++のような世界的に重要な言語のデザイナーっていうのはどんな気分」と聞いたら、 「うーん、単なる偶然。そういうものが必要と思って作っただけだから」とのこと。
「Javaについてどう思う」という問いには「興味ない。書けと言われれば書くけど、 技術的には面白いものはないから。あれはマーケティングの産物だよね」だそうだ。 私以上に技術屋だ。ま、それはそうか。
BjarneにPARCでMVC(Model-View-Controller)を考えた人(Trygve M. H. Reenskaug、発音できない)を 紹介してもらった。この方はもうすっかりおじいさんなのだが、中身はすごいぞ。
UMLとかを見てもクラスとクラスの関係を記述している。が、本当に重要なのはオブジェクトだ。 あれじゃクラス指向じゃないか。
に始まって、鋭い指摘が満載でした。Naked ObjectとかModel Driven Approachとか新しめのキーワードも カバーしてるし。
日本にはこんなおじいちゃんいないよなあ。 あと何十年か後に私がそういうポジションを占めればよいのか。
めざせ、コンピュータおじいちゃん。
あー、ほかにもいろいろあったような気がするけど、忘れた。 帰りの飛行機の中で思い出すようにしよう。
出発の日。JAOOカンファレンスは昨日で終わってしまって、 今日残っているのはチュートリアルのみ。 これには参加する予定はないので、ホテルの部屋でインターネット回線を購入(150DKR)し、 午前中はウェブとメール。
午後には出発。まずオーフス駅から空港までバス(60DKR)。 バスは予定時間より微妙に早く出発するので注意。
空港(Aarhus Lufthavn)から、ATR42/72でコペンハーゲン空港へ。 機体は来た時のものよりも大きいので、こっちがATR72なのだろうか。 しかし、なんど聞いてもコペンハーゲンではなく「こぺなげ」にしか聞こえない。
コペンハーゲン空港では家族に少々おみやげを買ったり、ぶらぶらしたり。 おなかが空いたのでホットドッグを食べる。しかし、この旅行でクローネの現金を使ったのは、 空港からの行き帰りのバス代とこのホットドッグだけであった。 おみやげとホテルでのインターネット料金はカード払いだったし。
コペンハーゲンからパリへ。３時間ほど空き時間があったのは辛かったが、 売店をぶらぶらしたりして時間を過ごした。
出発ターミナルでは日本人があふれてる。まあ、日本行きの便が出るターミナルなので 当然と言えば当然なのだが、なんか変な気分。
駄目もとで無線LANカードを差すとつながる。便利なものだ。
現地時間25日遅くに出発。
結構長い時間の旅であったが、ほとんどを寝て過ごす。 機内の映画は『黄泉がえり』で、実は見たかったのだが、 寝ている間に始まったらしく、気がつくと話が全然わからないうちに終わってしまった。 うーむ。後でレンタルすることにしよう。
日本に着いたら夕方6時。なんだか1日損した気分。 まあ、ヨーロッパだと時差がアメリカの半分なのでまだマシと言えばそのとおりだが。
ヒルトン成田に電気かみそりを忘れていたので、取りによってから、今日のホテルへ。
なんだか時差があるんだかないんだか、よくわからない。とりあえず寝る。
今日泊まったホテルは、いわゆる普通のビジネスホテルなのだが、 行きはヒルトン成田だし、向こうにいるあいだも、いわゆる高級ホテルに分類される Radisson SASに泊まってたもんだから、妙に貧相に感じる。当たり前だけど。 贅沢になれるのは速いものだ。
このホテルでは部屋までVDSLでインターネット接続がある、はずだったのだが、 DHCPが認識しない。サーバが返事しない感じ。うーむ。
というわけで、近所の東横インのロビーで無線LANを使わせてもらう。便利だ。 こんどからはこっちにしようかなあ。
羽田からJAS機で出雲まで。なんかひさしぶり。子供がなついてくる。
午後はずっと寝てしまう。向こうでは時差の影響はほとんどなかったのに、 帰りはダメージが大きい。気が張っているせいか、それとも2度目の調整は大変なのか。
追記1
あら、ご指摘通りVSDLはVDSLの間違いです。
追記2
東に向かうってのは時間が進む方向ってことかしら。 だとすると、今回は私は逆で、西に向かった方がダメージ大きかったですね。 たぶん、普段から4〜5時間遅れ気味に時差がある生活なんで、 差が少なかったんでしょうね。
今日は松江に出席だ。用事がないからお客さんしていられるな、と思ったら、 いきなり日曜学校の教師を頼まれる。 日曜学校の時間が始まってから、教師を依頼されたのは初めてだ。 その日の朝という経験はあるけど。今日は新約聖書「ローマ人への手紙」から。
今日は長女の11回目の誕生日である。もうそんなになるのね。 教会から戻るとプレゼントを贈る。今日はきげんがいい。
私は午後、また寝入ってしまったのだが、他の家族はその間にケーキを焼いたりしていたらしい。 夕食後、みなで歌を歌い、ケーキを食べた。
昼間寝過ぎたせいで夜目が覚めてしまった。どうしてくれる。いえ、自業自得です。
松田さんから
まだ判断材料が揃っていない時点で「ソフトウェア特許が悪」と 結論付けるのは早計ではないでしょうか。
というツッコミをいただきました。まったくその通りですが、 私は別に「ソフトウェア特許が悪」であると考えてはいません。
現時点では、ソフトウェアに限らず「特許(現在の特許制度)は悪」かも、と疑っていますが、 結論づけるほどの材料を持っていないことは自覚しています。
ソフトウェア特許は悪だと結論づけているような書き方をしてました？
現時点で、「特許の利点」について私の納得できるような理由を見たことがないというのはあります。 あ、「特許の利点」というよりも「現在の特許制度の利点」と言った方が正確かな。
もともとの理念である
発明者には一定期間、一定の条件のもとに特許権という独占的な権利を与えて発明の保護を図る一方、その発明を公開して利用を図ることにより新しい技術を人類共通の財産としていく
というのは、まだ理解できないのでもないのですが、 現在の特許制度が「新しい技術を人類共通の財産」とするのに役立っているか、 というとかなり疑問だと思います。
もともとの理念を実現できるような特許制度であれば、私は反対はしないような気がします。
フリーソフトウェアに特許がじゃまなのは確かですが、 特許制度が「人類共通の財産」の形成に寄与する目的をきちんと果たすのであれば、 そのことによる一時的な制限は引き受けてもよいと思います。
この辺はストールマンとはちょっと違う点です。
先日受けたインタビューがもうウェブにアップロードされている。すばやい。
全4回のうちの第1回目にあたる。まあ、いつものような内容をいつものように話しているわけだが、 今回は直接顔を合わせてのインタビューなので(英語では初体験)、 今までのインタビューよりもだいぶ充実した内容になっているような気がする。
しかし、Billはずいぶん上手にまとめてくれたので、ちゃんとした英語になっている。 実際にはカタコトで意思疎通できるのがやっとというレベルだったのだが。
ま、読んでみてください。
以前のインタビュー
国産新言語だそうだ。開発元のセブンネットによると、
AQUAは、WEBサーバー用のオブジェクト指向対応スクリプト言語です。
習得が容易
言語仕様を、絞り込むことによって習得が容易なスクリプト言語となっています。 HTMLにスクリプトを、混在記述出来るので静的なホームページを、簡単に動的なページに作りかえる事が出来ます。
オブジェクト指向
言語仕様としてクラスタイプのオブジェクト指向命令を、備えています。 クラス定義で、メンバー関数とメンバー変数を、記述する事によってソフトウェア部品として再利用することが可能です。
セキュリティ機能
とても簡単に使えるセキュリティ専用の変数フィルタリング命令を、備えています。 フォームからの入力値を、容易にフィルタリングして排除することが可能です データを、悪意があるユーザーの行動から守る事が、出来ます。
デバッガ内蔵
スクリプトを、デバッグするために専用デバッガを、内蔵しています。 デバッガで、ステップ実行やブレークポイント設定や強制停止や変数閲覧が可能です。
WEBサーバー拡張対応
WEBサーバーのIISエクステンションとApacheモジュールに対応しています。
ということなのだが、これらの特徴はあまりアピールしてこない。 特にこの言語処理系が有料であることを考えると。
マニュアルを読むと、 なんだか15年前のBASICに戻ったみたい。確かにオブジェクト指向機能は持っているけど。
この言語はいくつもの点で、私の「成功する言語の基準」を満たさない。
拡張可能性
AQUAのプログラムは基本的にコマンドの羅列になるのだが、 その基本コマンドをユーザが定義する方法がない。ユーザ定義関数はあるのだが、 ドキュメントを読む限りでは組み込みとは扱いが違う二級市民である。
フリーな実装
無料の試用版は用意されているようだが、ソースコードは公開されていない。 言語の進歩のために必要なコミュニティの形成にソースコードの公開は(たとえ必須ではないとしても) 非常に有効である。フリーな実装が存在しない成功した言語を思いつかない。
とはいえ、私が間違っている可能性はいつもあるわけだ。 プログラミング言語は非常に寿命が長いため、短期的な評価は不可能だ。 長い目で見守っていきたい。 私の予想に反して大成功しないとも限らない。
ただねえ、言語ビジネスは死屍累々なんだよねえ。
で、AQUAのように(あるいはRubyのように)新言語を作った場合、 こんなところが優れている、というところを示さなければ誰も使ってくれない。
Rubyの場合には「なにができる(what)」という部分で勝負することはやめて、 「どう感じるか(how)」を全面に出している。いかに気分が良いかが重要ということだ。
これはこれでユニークなアプローチだと自負しているのだが、 今日、本屋をぶらぶらしていて、より新しいアプローチを思いついた。
「感じる」では生ぬるい。「私の人生がどうなるか」が重要だ。ということで、 名づけて「開運プログラミング言語」。
曰く、
この言語でプログラミングするようになってからは、上司の機嫌もよくなり、 先日は大幅な昇給までしてもらいました。 また、家庭でもよいことが立て続いて、とってもラッキーです。
その上、なんの気なしに買ったサマージャンボが大当たりです。 これもすばらしい言語を作ってくれたmatzさんのおかげです。
ありがとうございます。
とかどうだろうか。
本言語処理系は世界有数のハッカーが一枚一枚気合いをこめてCD-ROMに焼き込んであります。 風水と中国四千年の伝統と、コンピュータの原理でもある八卦が織り成す超自然的なパワーが、 あなたのプログラミング能力を向上させるだけでなく、 運気を向上させ、幸福を呼び込みます。
てな感じで。なに、どうせ、効果があってもなくても確認のしようがないんだし、 ペンダントとか表札とか壷とかと同じレベルで受け入れてもらえるんではないだろうか。