トップ «前の日記(2005-12-03) 最新 次の日記(2005-12-05)» 編集

日々の破片

著作一覧

2005-12-04

_ Rubyから何を学べるか?

機械猫さんがRubyから学んだことというエントリーを書かれている。それは

オブジェクト指向の視点の変化

本質に集中する

の2点だそうだ。

このうち2番目の点については僕はそれほど同意できないのだけれど(感覚的な問題だと思うから、理由は別にない。ただDRYにどれだけ共感できるか、あるいはコミットできるかという点がそう感じる分かれ目なのかな、というようには思う。早い話、僕は必ずしもDRYではない。そのあたりが理由なのかも知れないが、僕はJavaで前準備みたいなことを記述していてもそれを本質的ではないと感じないからだ)、1番目の点についてはそう思う理由は異なるのに、同じように感じているので興味を惹かれた。

つまり、この結論の部分だ。

例えば、あるプログラムに対して機能追加をしようとする際にはJavaならば

「このデータをどう処理するクラスを定義すればよいか?」

と考えていました。

しかしRubyの場合は

「このオブジェクトにどのようなメッセージを送ればよいのか?」

という風に考えることが多くなりました。

この違いは微妙に感じるかもしれませんが、僕にとってはとても大きな違いに感じます。

つまりJavaで書いているときには

「クラス=データ+処理」

と考えていましたが、Rubyだとデータと処理が一体となっているという感覚がとても強いため

「興味のあるデータを表している(not 持っている)オブジェクトにどのようなメッセージ(処理の依頼)を送るか」

と考えるようになったのです。

ただ、その後のなぜそう思うのかの考察が違うのがおもしろい。

たとえば、thisとselfという例が挙げられているが、meと(selfはまだ第3者目線だがmeはおふらんすざんす。と突然おそ松くんとかになってしまうのだが、読んでる人はおそ松くんなんて知らないだろうな、とかわかっていても無関係に無駄口が出て来てしかもこんなメタデータ付きで消しもせずに書いてしまうのが日記らしくておもしろい)書くVBだってクラスを意識する(でも、逆にJavaだろうがC++だろうがメッセージだと感じるから、実際には微妙には異なる)。

境界をどれだけ意識するか、というと一番しっくりくるかも知れない。もちろん、Rubyで書く場合であってもカプセル化は強く意識するわけだから境界というのはクラスバウンダリという用語化可能なものとは違う。どちらかというと境界がクラスではなくオブジェクトにあるように感じるというと一番僕の感じ方を正確に表しているかも知れない。

言語機構としてmixi-inでインスタンス変数を触るコードまで後から外部から混ぜ込めるとか、instance_evalで個々のインスタンスを別方向に成長させることができるからとか、も理由のひとつではあるだろうが、もっと最初の部分から異なるように思える。当然、静的/動的より前の話だ。

非生物と生物とか言い出すとインチキくさくなるが、それに近い(上で理由のひとつとして挙げたインスタンス生成後にさらに成長可能かどうかから逆に言葉を持ってきている感が拭えない)。

Java(C++、C#、VBなんでも良い)の場合、プログラミングは戦略的だ。わりと僕は静的なモデルを意識するし、外部インターフェイスは最初に決めていく(UML上ではなくインターフェイス定義ーCならヘッダファイルだし、Javaならinterface、VBならIDL)。それに比べるとRubyの場合、ある程度の規模であってもはるかに行き当たりばったりに書くことが多い。そのほうが書きやすいからだ。そうやって書いている間に命を吹き込まれて勝手に動き出すというオカルティックなプログラミングだけど、この比較は他のジャンルでもあり得るからそれほどおかしくはない。つまり、論述と叙述(論述と無理矢理対語的に持ってきたので、本来の意味とは異なり、ここでは小説、散文、叙事詩のような創作的な文章をさす)の差と言えばより正しい。創作物では主人公とか脇役というようなアクターがいて、作者の思惑を超えたり反映したりしながら勝手に動き出す。勝手に動けば動くほど生き生きとしてきてしかもリアリティが増す。

Javaのプログラムを書いていてオブジェクトが勝手に動き出すなんてことは無い。常にこっちが意識的に動かす。全部、決めてやらなければならない(イディオムにしたがって勝手に動くというのはあるけれど、そういう具体的なコードの話ではなくプログラミングしているときの心の動き、あるいは感じ方の話だ)。ところが、うまく書けてるときのRubyのプログラミングはオブジェクトが自分で勝手に成長したり分裂したりしていくような感じ方を受ける。

#つまり、Rubyはテストファーストしにくい(そういう結論かよ)。

動的/静的の差は実際にはある。コンパイルという過程を通るからある程度のまとまりで記述しなければならないからだ。しかしJavaScriptやVBScriptの場合は、クラスという形でうまく単位化できないからやはりある程度まとめて書く。Rubyの場合だとまとめて書かないわけではないが、より小さい単位で書くことが多いように感じる(が、それは事実ではないようだ)。

#楽に感じるのは、勝手に動くからのようだ。

#さらに考えてみれば勝手に動けるのは、こっちの持っているものを引き出しやすいからだ。したがってプログラミングの感覚をうまく持っていなければ別にRubyを使ったからどうだということは無いだろう。逆に持っていてもそういう勝手に引っ張り出していくスタイルを取ることに拒否反応が出ることも十分にあり得そうだ。その場合は別段利用することにメリットも無いだろう。その意味ではハッカースタイルの言語というのはそれほどは外していないかも知れない。

本日のツッコミ(全8件) [ツッコミを入れる]
_ kikaineko (2005-12-04 11:39)

トラックバックありがとうございます!!<br>実は「生物・非生物の差」など、僕も感じたりします。<br>ただ、それをなんとかコードを示してまとめてみようと思い、かつ僕もRubyとJavaの差って言語機能としての動的・静的より前に大きな差があるなっと思っているので動的・静的な差をあまり出さずに書いてみたらああいう日記になったという感じです。とは言いつつもartonさんのこの日記を読んで、言語機能としてではなく、言語思想としての動的・静的な差が大きいのかなぁっと感じました。(思想って書くとなんか怪しいですね。。。)<br>また僕もrubyがテストファーストとしっくりこないなって思うときがあります。確かにartonさんのおっしゃってるように「勝手に成長する」からやなぁっとは思うのですが、もう少し自分の中で掘り下げてみたいです。(ただの報告かよ!)<br><br>あ、後、おそ末君のイヤミは分かりますよ。笑

_ よしき (2005-12-04 12:39)

「オブジェクト指向」を作ったのが分子生物学を専攻した人で、細胞の概念がそのモデルにある、ということは例によって(^^;)指摘しておきたいような気はします。

_ arton (2005-12-04 22:40)

ばらばらに<br>・ブロックが手軽に書けるというのは大きいですね(と、突然、やっぱりそれかな、と思ったのを書いてみたり)。<br>・実際には何がどう影響しているのかが具体的にわかってくるといろいろ面白い/役に立つと思いますのでぜひお願いします。>もう少し自分の中で掘り下げてみたいです。<br>・おそ松くんわかるのか……すごいな。<br>・あらためて見るとすごい略歴ですね。the design of the ARPAnetってどのくらい関与していたんだろう? http://www.hp.com/hpinfo/newsroom/feature_stories/2002/alankaybio.html

_ sumim (2005-12-05 10:22)

「オブジェクト指向」という言葉は、ユーザーが定義可能なデータ型(抽象データ型)の安全な設計と運用に軸足を置く手法と、“間”(メッセージング)をどうすべきかを問う手法という、主に2つの出自がまったく異なる考え方を渾然一体にして語るのに便利に使われる傾向にある…ということは例によって(^^;)言及しておきたいような気はします。

_ arton (2005-12-05 11:01)

その分類(ALGOL由来と、Smalltalk由来ということでしたっけ?)だと、Rubyで書くときは後者側に立って書く(ようにまつもとさんのデザインによって仕向けられているのかどうかはわからないわけだけど)けど、上で言及している仕事系言語だと前者側に立って書くから、その違いだってことになるんでしょうね。

_ arton (2005-12-05 11:15)

でも僕はどっちにしてもメッセージは意識しているからそう簡単にはわりきれなさそうです。<br>この時に、どちらかというとRubyの場合は無手順プロトコルによる水平分散システムを使っていて、Javaとかはプロトコルがかっちりした垂直統合型のシステムを使っているように感じるということかなぁ。

_ sumim (2005-12-05 13:11)

ALGOL というよりは C++ 由来…ですね。でも、大事なのは言語ではなくメンタルモデル(と、その発案者)ほうなので、それぞれストラウストラップ(あるいはより純化されたものとしてメイヤー)由来と、ケイ由来…というような表現が語弊が少なくてよいかもしれません。 あと、けっして前者か後者かと“割り切る”必要はなくて、どちらをどのくらいメインにするか、比較的どちらに注力できる(注力すべき)言語デザインか…という話のように思います。

_ arton (2005-12-05 18:43)

>割り切る必要はなくて<br>確かに。まあ、実際には向き不向きがあるから割り切って利用したほうがうまく行くとは思います。


2003|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|

ジェズイットを見習え