著作一覧 |
家に帰ったらでっかいアマゾンのニヤリさん箱があって何かと思ったら、昨日クリックしたカイルベルトのリングだった。
じゃない寺山修司のJavaからRubyを聞きに海のほうへ行った。
途中、長い長いトンネルを抜けたのだが、これの天井が低いのなんのってつい、うつむいてみたり、首を右に曲げてみたりしながらおっかなびっくり歩く。
でも、向こうから来る人はみな、背筋を伸ばしてスタスタ歩いてくる。
で、意を決して威風堂々と歩けば歩ける。指を頭に当ててみると天井まで数cmは余裕があることがわかる。でも、そのうちだんだん足取りがしょぼくれてきてうつむいてみたり、首を左へ曲げてみたり。でも、また向こうからスタスタ胸はって歩いてくる人を見る。そこで意を決して……と同じようなことを延々と繰り返しながらやっと外に出た。
潮の匂いがかすかにした。
制約があると、たとえば天井が低いとか、仮にそれが自分の身の丈に合っているとしても、やはり窮屈だ。本来の能力=歩く速度を保つことすらおぼつかない。
でも、毎日、それを繰り返していれば(通勤コースとかで)、それに慣れてしまいスタスタ快適に歩けるかも知れない。学習ということだ。
青天井の下を歩けば、そんな心配は無用だし、学習コストはゼロだ。
やはり自由はすばらしい。
角谷さんの伝説のライブ(再演)を堪能しに永和システムマネジメントを訪問。どうもありがとうございました。
いやぁ、これはデブサミのセッションとしては異質だっただろうなぁと想像できる。キーノートプレゼンのミソは黒地に部分着色した文字かな、と思ったのも含めて。
プログラミングはおもしろいわけだが、そのおもしろさのうちの相当の部分は書いたコードの美しさによって決まるような気がする。(だからカッコの美学という主張はわかるし、実際のところカラム7の美学もわかるし、逆にインデントを美学ではなく必要に変えてしまうセンスは嫌いなのだがもっとも食わず嫌いの可能性もあるだろうけど)
きれいというのはいろいろ主観に依存すると思う。
最初、こういうのがきれいだと思った。
int axe = 3 ; int exe = 4 ; int longname = 8 ; long lonlon = 1L;が、へたなプログラムほどこういう書き方をしているのを目にして、次の書き方へ移行した。
int axe = 3; int exe = 4; int longnmae = 8; long lonlon = 1L;最初の書き方って、カラム7の美学の文化圏だ。後者の書き方へ移ったときに、おれは多分、自由を少しばかり手に入れたのだと思う。
と思う。
#まとまらない。
と書いた先からそうではない考えもありうるとは思ったが。
百ヶ国語をぺらぺらしゃべれるものの、どの国の言葉をとってもレトリックのひとつも使えなかったり言葉遊びもできないのと、1つの国の言葉の奥義を極めあらゆる表現を自在にできるもののそれ以外の国の言葉は使えない、の違いは良し悪しではなく選択の問題だ。
以下の言明がある。
命題1:Rubyはオープンクラスなので良い(選択多)。Javaはクローズドクラスなのであまり良くない(選択少)。
命題2:RubyはRailsを選べば良いので良い(選択少)。Javaはどれを選べば良いかでまず立ち止まる必要があるのであまり良くない(選択多)。
というのは矛盾しているかどうか。
レイヤーが違うんだから、これらは独立している。したがって矛盾してない、という答えがある。でも、それで終わってはつまらない。
Railsはフレームワークだし、フレームワークは型にはめる仕組みだ。にも関わらず、実際には型にはめられて気持ちいいという感覚はあまり受けない気がする。むしろ、それをベースに好き勝手ができるという感覚のほうが強いんじゃないだろうか。もちろん、そうは言っても枠があって、そこにアイディアを流し込めば楽だ、というフレームワークの基本はきちんと押さえてある。ただ、その枠の組み換えの自由度が高い。そこで、プラグインを作ったりすることになるのだろう。ただし、ある一定の嗜好に対する影響は受ける(規約がもたらすリズムとでも言おうか)。その嗜好に自分の嗜好が合えば実に心地よいということだ。
一方、枠が固く組み合わされているものは、選択後の自由度は少ない。そこで選択だけはできるようになっているとも言える。だから、乱立するんじゃないか?
それに対して、RailsはRailsに収斂する。
ロジックはないけど、あるべきOSSの姿って、これかも。
何でも付け加えることができるゆるさ。周辺があいまいで境界があるんだかないんだかわからなければ、外部から結合されてくるので、だんだん成長する。周辺がかっちりしていてエッジが立っていると、似たようでちょっと違うものが外部に生まれる。
(今、LinuxとBSDという対比を想像した? だったら、これも良し悪しではなく、戦略の問題だ)
土台を提供する方法と、ネタを提供する方法。
さらに、そこにその人が持つ粒度感みたいなものがあるだろう。
Linuxを見て、よっしおれもカーネル作ろう、と考える人もいれば、おおこれは良いからこの上に乗るものを作ろう、と考える人。
Lispを見て、よっしおれも処理系を作ろうと考える人、言語を作ろうと考える人、ライブラリを作ろうと考える人、アプリケーションを作ろうと考える人。
Railsを見て、よっしおれもフレームワークを作ろうと考える人、アプリケーションを作ろうと考える人、プラグインを作ろうと考える人、おれさまActiveSupportを作ろうと考える人もいるかも。
おそらく、効率という点では、オルターネイティブを作ろうと考えさせるのはあまり良いものではない(とは言ってもいずれにしても作る人はいる。器の大きさなのかも。あるいは単に狭量なだけかも。両方かも)。そうではなく、その土台に何かを加えてより豊かなものにしようと考える人を生み出す余地が大きいものが良いのだろう。
#周辺プロジェクトが多いOSSは良いOSSだ、の原理。それに対して、代替OSSが多いOSSには、やはり何か欠点があるのかも知れない。
とりあえず読んでおくのがやはり吉。(萩原さんのは何書いてんだかさっぱりわからないこともあるし、的外れに見えることもあるけど、たいてい数年後には納得することが多い)
ジェズイットを見習え |