先日、「南青山アドベンチャーも挫折した」と書いたが、 その後、記憶をたどるとどうやら私が遊んだ(そして挫折した)のは、その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は関数的にも書けるがその実体は単なる手続き型言語だし。
いくつかの問題は解決した。まずは旧マシンの問題から。
以前書いた時計が狂う問題だが、 Thinkpadでも発生したのでハード的な原因ではないことが判明。 いろいろ調べたところ adjtimex パッケージが時刻にドリフトをかけていた。 こんなパッケージいつ入れたっけ。adjtimexパッケージを削除して解決。
次に、Speedstepとサスペンドだが、 うまくいかないカーネルのブートログを、うまくいくカーネルのログと見比べると、 以下のようなACPI関連のものが増えていた。
Sep 10 10:02:14 localhost vmunix: ACPI-1133: *** Error: Method execution failed [\_SB_.PCI0.PCI1.DOCK.IDE1._STA] (Node efa7ef60), AE_AML_NO_RETURN_VALUE Sep 10 10:02:14 localhost vmunix: ACPI-0154: *** Error: Method execution failed [\_SB_.PCI0.PCI1.DOCK.IDE1._STA] (Node efa7ef60), AE_AML_NO_RETURN_VALUE
configはCONFIG_X86_SPEEDSTEP_CENTRINO_ACPI以外全く同じはずなのに、 動作が異なるのは解せないが、ここはあまり追求せずACPIをoffにしたカーネルを作ったところ、 みごと望み通りのSpeedstep ＋ APM suspendが実現した。
しかし、ちょっと試す度にカーネルのフルコンパイルが必要なのはつらかった。 慣れてればもっと上手な方法があるんだろうけど。
ついでだが、これについて調べている途中で見つけた、 tpbというプログラムは収穫であった。画面の切り替え、輝度の操作、ボリュームの操作などを画面に表示してくれる。 Thinkpadユーザはお勧め。
最後、コンピュータとは関係ないんだけど、夕べから今朝にかけて雨が降ったが、 どうやら雨漏りはしていないようだ。 大家さん、ありがとう。
Martine FowlerがRubyを使ってクロージャについて紹介している(日本語訳)
確かにクロージャはすごく便利なんだけど、 Rubyのクロージャはcallメソッドを使わないと呼び出せないので、ちょっと気持ち悪い。 まあ、Lispでもfuncallを使わないといけないので「絶対駄目」というほどではないけど。
とはいえ、SchemeやPythonのような
foo.bar(1)
を「foo.barというメソッドオブジェクトを取り出し、1を引数として呼び出し手続きをapplyする」というような セマンティックスは避けたい。 やはり、これはRuby的には「fooに1という引数とともにbarというメッセージを送る」という意味づけをしたいのだ。
で、考えたんだけど、
というのはどうだろうか。現在、「call」の代わりに「[]」を代用したりしてるけど、 これをずばり「()」メソッドにしちゃうと。そうすると、
fact = lambda{|n| if n == 0 than 1 else fact(n - 1)* n end }
fact(10)
のように書けて気分が良い。
欠点は互換性だ。そんなに凶悪ではないけれども、 ローカル変数名と同じ名前のメソッドがレシーバを省略して呼べなくなる。 あんまり頻繁に発生しそうではないが。
もう一つの問題は大文字で始まる名前のメソッドだ。 Rubyには少数だが大文字で始まるメソッド(Array()とかString()とか)がある。 ローカル変数と違って、定数は定義されているかどうかがコンパイル時にはわからない。
これについてはいくつかの対処法が考えられる。
くらいか。採用するなら、一番きれいなのは最後のものだな。
ただ、Rubyの組み込みの範囲内では大文字で始まるメソッドはクラス名と同一で、 変換を行うものばかりなので最後の案でも問題なさそうだけど、 他で大文字で始まる名前のメソッドを持っているプログラムには、 メソッドの名前を変えるしか対処方法がないのは移行の問題があるかもしれない。
仕様を決めてしまえば、実装はすぐに頭に浮かぶし、たぶん１５分くらいでできそうだ。
もっとも、今parse.yを変更すると青木くんがギャッといいそうなので、 手をつけるのは我慢しよう。
水面下で作業中であった『るびま』こと、『Rubyist Magazine』がとうとう創刊しましたよ。言語をネタとした読み物としてのWeb雑誌というのは、 なかなか面白いスタンスではないかと自画自賛。
とはいえ、私はインタビューに答えただけであとは編集部の皆さんのおかげです。 お疲れさまでした。
追記:
CNET Japanでも取り上げられているぞ。ちょっと感動。
HotWiredにRuby on Railsの記事が載るってのは、 ひとつの時代の流れを感じる。
『まつもと ゆきひろのハッカーズライフ』。 今月はOSS貢献者賞受賞を受けて「ハッカーとオープンソース」について。
でも、オープンソースなんてしょせん1998年に生まれたまだまだひよっこの概念。 しかも、どちらかといえばマーケティング用語である。
なので、タイトルこそ「オープンソースソフトウェア」だが、 実際はフリーソフトウェアについて、特にStallmanとEmacsについて書いた。 私がこういう話をすると、どうしてもGoslingが悪者として登場しちゃうなあ。 彼自身は悪気はなくて、真の悪役はUnipressなんだろうけどね。
今回は2年に一度の衛星放送によるステーク大会。 朝から米子に移動。
山陰側だけでも集まると結構な人数になる。 会場はほぼいっぱい。
直前にプロジェクターのランプが切れたとかで(不運な)、 急遽家庭用プロジェクターで投影することに。 そこまで大画面にすることを想定していないのか、かなり暗い。 私たちの席はかなり後ろの方だったので、人の顔がよく見えない。 なんか近視の人が見てる世界のようだった。 ということは、普段の世界に近いということか、私の場合。
日本向けということで、 日本の文化や歴史に配慮したお話が多かった。 考えてみればアジアの中でも少々特殊だよな。
ただ、予定よりもはるかに短い時間で終ってしまったのにはびっくりした。 2時間あると思ってたよ。はっきりした原因は分からないけど、 なんかトラブルでもあったのかな。
まあ、短くはあったけど充実した内容であったし、 かえって時間に余裕ができたので、それはそれで良かったけど。
今回もメモをとった。後で見返してみないとな。
というわけで、近くにいない妹と弟、それと頭痛で体調不良という妹婿を除いて 一族が実家に集合。えーと、ひい、ふう、...15人か。
一緒にお昼ご飯。子供は運動会並みに駆け回る。 実家は古い家だし、階段が急(75°くらいありそう)なので、 見てる方は心配なのだが、あいつら恐怖心というものがないのか。
もっとも考えてみれば、自分が子供のときはもっと危ないことしてたよなあ。 良くケガしなかったものだ。
いや、してたか。たまに打ち身とか捻挫とか。 親も気が気でなかったことだろう。
今になって分かる親の気持ち。
「フィンランド生まれのLinuxは、我々アメリカ人から技術的優位性を奪うためのヨーロッパからの脅威だ」という話。
最後まで読んでも「冗談だ」とは書いてない上に、 他の(非技術系)エントリもずっと同じような調子(噛みついて、馬鹿にして、侮辱する)なので、 もしかしたら本気なのかもしれない。
だとすると、アメリカ大衆の底力(っていうんだろうか)を垣間見たような気がする。 ダグラス・アダムズも言っていた。
真のバカでも使えるものを設計しようとして人々がよくやるミスは、真のバカのバカさ加減を過小評価することだ。
そういえばアダムズもヨーロッパ(イギリス人)だ。
大変面白い。
問題は担当スタッフが鋭意作成中であるが、 これも参考にできるかも(笑)。
とはいえ、実際の問題はもう少しストレートで優しいものになる予定。
今回はでかいビデオカメラが持ち込まれて実際の撮影である。
しかし、ほんの5,6分の番組のためにいろいろいっぱい撮るもんである。 そういえば、以前『クローズアップ現代』に未踏の件で数分映った時も おおかたまる半日かけて撮影したなあ。
一番感動したのはディレクターの人が持ってきた、 私が中学時代に使っていたシャープ PC-1210*1を持ってきたこと。 父親に借りたんだそうだ。まだ、保管してたのね。
二十数年ぶりの再会か。 電池と液晶がだめになってて、使い物にはならなかったけど、 とても懐かしかった。
*1 実際にはメモリ拡張されててPC-1211相当
まあ、知らず知らずのうちに自分(作った人)の視点で商売しちゃうというのは しばしばあることだ。
面白かったのはここ。 Rubyが「とがった技術」の代表としてのイメージが(OSS業界の外でも)定着してる ということを示して面白い。
「長島さん、このソフトは最新のソリューションを盛り込みました。言語も今流行りのRubyを採用し、オブジェクト指向で・・・。このライブラリが・・・。さらにこの通信で・・・・・・」
「なるほど、なるほど。分かりました。それで、どれくらい販売されているんですか？」
「それが全く売れないんです。こんな良いソフトウエアなのに、どうしてでしょうか」
でも、そんなの関係ねぇ。
パネルディスカッションで印象的だったのは、楽天の森氏も、CTCの小島氏も“Rubyの楽しさ”を強調したことだ。小島氏は言う。「Rubyを使うようになってから、プログラマが幸せそうに働いているんですよ。このインパクトは大きい。朝から黙々とキーボードを叩いている姿は、今日も会社に行くの嫌だなと思うのとは大きな違いです」。森氏も異口同音だ。「エンジニアが楽しそうで仕事が活発になった。Rubyが広がることで日本が元気になればいい」。
うーん、「楽しそう」なんて要素が業務向けの話でできるようになったというのは、 日本のIT業界も変わったと言うべきか。
もし、本当に変わったとして、もし、Rubyがその変化のきっかけになったのだとしたら、 それが本当に事実なら、作者としてこれより嬉しいことはない。
どんな賞よりも嬉しいかも。
Google SparseHashのベースになっているSparsetableのデータ構造。
Rubyのコードを見て、やっと仕組みが理解できた(遅い？)。 大変巧妙にできている。
こういうアルゴリズムやデータ構造を考え出すことができる人ってすごいなあ。
お布団の上で寝られるってすばらしい。昼まで寝てしまった。
海外旅行中はテンション高くなりすぎて(あと、イベントとかでネットにアクセスできない時間があるので、それの穴埋めもあって)、ろくに寝ないで、いつのまにかベッドの上でPCを前に何時間が時間がワープしているようなことが頻発するので、「さあ寝るぞ」という感じでお布団に入ることに幸せを感じてしまう。
あと、お風呂。日本人に生まれてよかった。