Hewlett Packard
LA Timesには、後継者候補として4人ほど名前を挙げていた。Michael Capellasもあったけど、彼が戻ったら結構お笑いだな。
とみざわさん(その4)
たぶん平行線なので、この辺でやめましょう。私はソフトウエア工学屋さんと か設計屋さん、あるいは現場の人の声を自分なりに代弁しているつもりだった のですが、私自身がこの辺に分類されるとも思っていないので。
僕はなるべく人を分類する、というようなことはしないようにしたいと思っている(つもり)なので、ご安心ください。(でも、代弁はしばしば危険ですよ)。
さらに言えば、適当(というのは言い過ぎであるが)に10人つれてきて10000行 数当たりのバグ数をどれくらいいかにできるか、とかを考えている人には、も う「オブジェクト」が何であるかさえ、ほとんど関係なかったりするわけです。
そりゃそうでしょうけど。ここ数日は、オブジェクト指向とは何か、というのがそもそものねただったのです。
ちなみに、われわれのチームでも、また毛色の違う新しい言語を作っているところなので、決してSqueak至上主義ではないです。たまたま今一番便利だから使っているのだ、と思っておいてください。
あと、別に僕は現場(?)の人がみんなxxしなくちゃいけないとかそういう主張をしたつもりはありませんよ。ただ、例えば「継承」がオブジェクト指向では「本質的」(それがないとオブジェクト指向ではない)ということがあたかもすべての人が同意することであるかのように言ったり書いたりすることに対しては、それは真か偽かの命題として見るとそりゃ偽だろ、と言っているわけです。
ですから、「もうちょっとオブジェクト感の違いみたいなものがあるわけなの ですが、「使って1000行くらいのプログラムでも書いてみてください。そうす れば判ります」と言うのを避けてそれを伝えるのは難しいでしょうねえ。」な どといわれても、「何だかんだで100万行を越えるコードがあって、プログラ マも集めて、さらに50万行バラバラにつくって組み合わせてもなるべくひどい ことが起きないようするにはどうすればよいか、というような仕事をしてみれ ばわかります」というのを避けて何かを伝えるのは難しい気がしてくるだけだ なぁ、と思います:-)
これは、僕宛ての言葉ですか?売り言葉チックになってしまっていたので(すみません)、いまさらこれを書いてもそれこそ無意味ですが、僕もつらい仕事のときはC++やJavaでプログラム書きすることもありましたし、100万行くらいのコードベースをいじることもありました(ほぼひとりですけど)。とはいうものの、一緒に仕事をしない限り「わかってない」と言われてしまうかもしれませんが。もともとの主張は「違うと感じている」ということの補強は難しいので、(せめてとみざわさんには)試して見てほしいなということだったと理解してください。
そういうことではなくて、「データ抽象(情報隠蔽)/動的束縛/継承」のように 本質的に重要な機能か?ということが言いたかったので、そのように理解して ください。
情報隠蔽の定義にはゆれはあると思いますが、例えばすべてのfieldが(C++とかの意味で)publicなオブジェクトはオブジェクトではないのか、というと決してないとは言い切れないし、継承はきっと本質的ではないですよね。
最後に私の好きなものの紹介:個人的には、関数型言語にオブジェクト指向を 突っ込んだもの(Objective Caml)をつかっているのですが、このアプローチだ とテクニカルな理由でどうもオブジェクトの部分が結構不思議なことになるよ うなので、いっそのことこれを逆にして、オブジェクト指向(たとえばJavaく らいのもの)をベースにして、関数型言語のうち高階関数と、組み込みデータ 型(タプル、リスト、Unionくらい)とパターンマッチングと、なんとか多相型 をうまくいれられれば多くの人に便利な言語になると思っていたのですが、ま あ、これも上の立場から見れば「ふーん」と言われるようなものではあります。 あ、でも、call/ccはいらないかな:-P
高階関数重要ですよね。後は、メタ機能をどう入れるか、というところが腕の見せ所かも。パターンマッチングも良いです。
最後に、MLで書いたときにも出る感想だと思いますが、100万行のシステムも最初からMLで書いておけば20万行で済んだのに、そうすればそもそもチームのサイズからして違っていてよかったのに、というような感想は持ちますよね、きっと。将来のソフトウェア開発は、より高レベル言語に高レベル言語に移行していくことによって、複雑さを制御下に置く、という方向が正しいと思われます。そういう意味で、今の現場や設計論の話だけではなく、新しい言語の話もさせてくださいね。
とみざわさん(その3)
(この記憶が正しいとすると、)結局、言語を問わず「クラス」のようなものを 欲しくなるもので、このようにみんなが欲しくなってしまうものこそが、非常 に重要だと思うのですが、私が言いたいのは、そのようなものが、 「Smalltalk マイナス 他のオブジェクト指向言語」の部分にはあまり残って いないのでは、ということなのです。いや、こんなのがあるぞ、というのがあ れば是非教えてください。
これはなんだか不公平な数式のようにも見えますが(他のオブジェクト指向言語、というのが他のオブジェクト指向言語全部という意味なのかどうか)、いずれにせよその差の部分にはいろいろと山のような概念や機能が入りうると思いますよ。例えば、call/ccをユーザーが自分で書けるとか。
...というひとつをそっと挙げましたけど、きっとひとつひとつの機能みたいなものを挙げても「いや、それはこの言語でもできる」とか「それができて何がうれしいの?」とかいう反応を呼んでいるような気もしなくはないですね。もうちょっとオブジェクト感の違いみたいなものがあるわけなのですが、「使って1000行くらいのプログラムでも書いてみてください。そうすれば判ります」と言うのを避けてそれを伝えるのは難しいでしょうねえ。
毛玉
アップロードしました。2.2というものをいったん作ったものの、やっぱりもうひと修正する必要を感じたので、最新版は2.3になっています。.sar形式にしてちょっと賢いことをしようとするので、インストールも多分便利になっていると思います。お試しください。
late-binding
late-bindingという概念そのものは別にプログラミング言語に限ったことでもなければ、ましてや前にも書いたように「メソッドディスパッチ」のことだけを指しているわけでもありません。どちらかといえば、「最初からすべてが判るわけではないので、可能なことはなるべく後のほう(普通は実行時を意味する)に決定する」という思想のことです(返事が遅れてすみません、とみざわさん)。
Alanの使うスライドにきれいに説明したものがありますが、どうすればみられるのでしょうね。
設計に関連することでも、イテレーションを繰り返す(変な日本語かもしれませんが)手法だと、詳細を後で詰める、ということは大いにあるので、それもまたlate-bindingと言って良いと思います。