|
3D Fellows Conferenceの開催日も決まり、着々と事態は進行していますが、なんかチャットの様子をみていると「みんなすごいのもってきそうなのでデモは辞退」という人が目立ちます。
まぁ話が出てから開催まで数週間しかないのでそんなにすごいものが見れるとは思わないほうがいいでしょう(だいいちオフ会だし)。
私も製作中の途中経過をスクリーンキャプチャして大々的(笑)にトップページに掲載しとりますが、実際に見てナァンダと言われないための牽制としてここで内容を述べておきますと、はっきりいって、いまの段階ではまだプログレッシブ・ランドスケープの焼き直しです。
ただちょっとロボットが飾りとして登場しているに過ぎません。さらにネタをばらすと、ロボットの位置も極めて適当に設定してあり、なにより重要なのは、地表の起伏を無視してロボットが存在することです(つまり本当に飾り)ということで、私の展示を楽しみにしている方はいまのうちにガッカリしていてください(がーん)。
ただし、前のランドスケープに比べて、画質が少しアップしています。これは隙間をふさぐ努力をしたためです。また、空には雲がアニメーションするようになってます。FinalRealityのバレバレの雲よりはバレバレでないつもりですがどうでしょう。まぁ見る人が見ればバレバレですが。これからもうちょっと内容を濃くするつもりですが、突貫工事なのでどこまでできるかわかりません。それは来場してからのお楽しみということで(でも楽しみにされると困ります)｡
ってなワケですが、それとは全く関係なしに、神聖モテモテ王国の３巻が出たので買ってきました。
モテモテ王国というのは、「神に約束されたナオンと彼ら親子だけの密あふるる約束の地」で、その建国を目指して謎の宇宙人ファーザーとその息子かもしれない深田一郎ことオンナスキーが日夜闘うという壮大な（？）物語です。
このマンガの面白いところは、とにかくその作品全編に溢れる語彙の数々。とくにファーザーの台詞は考え抜かれていて、表面的な面白さに止まらず、知識の深淵までギャグに使うという知的なギャグマンガです(本当か？)。
特に、機動戦士ガンダムねたや政治ネタはもとネタを知っていれば爆笑すること必至。腹をかかえて笑い転げます。
ああしかし、このマンガを読んでいると、どこからともなくそんなもん読んでるからモテないんだよという声が聞こえてきてドキッとします。
モテたいという願望は心理学的にいうとなんざんしょ。モテたくない人はいないと思いますが、私はそれらは全て「コミニュケーションを求める性質」と理解しています。
というわけで今日はコミニュケーションについて考えてみたいのです。
|
|
|
果たしてなんでいまさらまたここで宗教的・哲学的な議論を繰り返す必要があるのか疑問に思う方もいらっしゃることでしょう。これらのことについては既に昨年の夏あたりで一応の決着を見て、しばらく放置された話題でした。
しかし、コミニュケーションの断絶というのは、いまさら私が言うまでもないことですが、これからの社会を築いていくうえで最も問題視すべき要素だと思います。
私は政治家ではないし、強い権力や影響力を持つ人間でもありません。しかし、社会の一員です。ですから私は私自身の問題として、この社会的な根元悪である、コミニュケーションの断絶について考えておく必要があり、またそれが私にとってより良い方向へ私自身を導く礎となると信じているのです。
「コミニュケーションの断絶」などと大袈裟な言葉を使ってしまうと、「俺には関係ないや」と思ってしまいがちですが、実はこれは実に生活に密着したところにある根源的な問題なのです。
右の写真はWindowsプログラミングで使うAPIの一覧をまとめた本です。みただけではわからないかもしれませんが、ライトハウス英和辞典よりも厚く、大きい本です。
プログラムを組まない方にはわからないかもしれませんが、この本がこれだけ大きいというのは、私にとってはハッキリとした恐怖として映ります。
私はWindows95上でのプログラミングをはじめてもう２年になりますが、いまだにWindows95の全貌はつかめませんし、DirectXを使わないプログラムは書けません。Windows95に用意された機能を全て使いこなすには、この本だけでは足りず、これと同じかこれ以上にぶ厚い本を読破しなければ、それに必要な最低限の知識ですら得ることはできないのです。
人間のやること、できることには自ずと限界があります。そして既にWindowsというものは、一人の人間が把握できる規模を遥かに超えた存在なのです。
どこかの雑誌のWindowsNT5の記事でNT5では数千万行に及ぶソースコードが使われているようなことが書かれていましたが、それはむしろ賞賛すべきことよりも、問題視すべきことの方が大きいのではないでしょうか。
既になんども繰り返し言われていることですが、このままＯＳが複雑化の一途を辿れば、必ず崩壊する時がやってきます。誰も全貌を把握できず、誰も管理できない、道具の域を逸脱した、渾然とした存在です。
その原因となっているのが、つまり私がさきほど「コミニュケーションの断絶」と呼んだものなのです。
他の部位を知らず、全体を見通すことができない。なぜならそれらはあまりにも複雑に入り組んでいるからです。
プログラム言語の歴史はコードのコミニュケーションの歴史と呼んでもいいでしょう。人間が理解しにくいマシン・コードから、それをアルファベットに置き換えたアセンブリ言語へ、そして計算をしやすく、ルーチンワークを簡単にしたFORTRAN、gotoによる条件分岐の見通しを改善するための構造化プログラミング言語、複雑化した構造を簡素にし、コードの再利用性を高めようとしたオブジェクト指向言語・・・・しかし最新のオブジェクト指向(もどき)言語といわれるC++でさえも、このような問題を解決する絶対的な手段とは言い切れません(無論、全てオブジェクト指向で設計され、実装されればいくぶんマシです)。
私がオブジェクト指向的アプローチの問題として最初に感じたのはクラス・ライブラリです。
MFC・・・マイクロソフト・ファウンデーション・クラスライブラリは、非常に高度でよくできたクラスライブラリですが、残念なことにそれを容易に使うには、かなりの熟練が必要とされます。
クラスライブラリを使う際は、使用するクラスについての知識だけでなく、その基底クラスすべてについて一通りの知識が要求されます。
つまり、クラスライブラリを使いこなすということは、クラスライブラリを構築するにひとしい作業になるのです。
特に、MFCほど階層が深いクラスライブラリではその問題は大きくなります。
反対に、Direct3DのRetained Modeなどはクラス化のうまく処理された例でしょう。
Retained Modeでは全てのオブジェクトはDIRECT3DRMOBJECTの派生クラスであり、全ての可視要素はDIRECT3DRMVISUALの派生クラスです。たった２段しかないクラス構成ですから、このことは理解を早めます。
むしろプログラマはDIRECT3DRMOBJECTとDIRECT3DRMVISUALについて知っているだけで、新しい機能が追加されたとしても、それがDIRECT3DRMVISUALからの派生クラスと解れば「ハハン、AddVisualして使うんだな」と一撃で理解できるわけです(もっとも、私としては同じ仕組みでライトや子フレームも設定できたらより素晴らしいだろうとは思っていますが)。
ドキュメンテーションの重要性についてはことさらここで強調することではないのですが、やはり初期のDirect3Dのサンプルはコミニュケーションというものについてつくづく考えさせられる代物でした。それでもそれが単なるコードであったおかげで、順を追って読むと、その内容がほぼ完全に把握できるのが唯一の救いですが、もっとマシなやりかたはなかったのかと思います。
しかしクラスライブラリは便利なことこのうえないのはもはや議論の余地はありません。実際、クラスライブラリは多くの無駄な作業から我々を開放してくれる福音でもあります。
さらにC++の持つテンプレート機能ですが、当初この有用性がまったくわからなかったものの、去年の暮にオブジェクト・プールをテンプレート化してみて有用性がよくわかりました。しかしなんというか、どうも中途半端な機能です。
便利といえば便利なのですが、テンプレートを濫用することによって、プログラムの意図がぼやけてしまうのではないかが心配です。つまり、テンプレートをはじめとするC++の先進機能の問題点は、ソースの一部分を見ても全体をつかめないことに問題があります。これもある意味では「コミニュケーションの断絶」といえるでしょう。
木を見て森を見ず、とは良く言ったものですが、プログラムというものはときに森をひとつまるごと作成するようなものです。そこで前々から思っていたのですが、プログラムをハイパーテキストで作ることはできないものでしょうか。
当然のことですけれども、プログラムというのはそれ自体がモジュール構造をなしています。関数の下には関数があり、さらにしたにはまた関数があります。アセンブリ言語になってしまうまでは下があるわけです。
それと、プログラム全体のモジュール構造を照らし合わせながらプログラムを書ける環境は、やはり必要だと思います。
しかし、似たような機能はクラスブラウザとしてすでにVisualC++やSmalltalkなどには実装済みです。
ところがこれだけでは全く要が足りてないのも現状です。
なぜでしょうか。実はいまのC++言語というのは、それ自体オブジェクト指向を名乗りながら、オブジェクトのことなどなにも考えていないからに他なりません。
既存のプログラミングスタイルでは、オブジェクト指向を合理的に表現することは不可能なのです。
なぜなら、オブジェクト指向におけるオブジェクトとは[1]自立して動作し、[2]内部変数を持ち、[3]他のオブジェクトと通信するものだからです。既存のプログラム言語には関数呼び出しと返り値という概念はあっても、自立した二つのオブジェクト同志が通信するという珍妙な概念はありえません。
それを無理にC言語風の枠組みでとらえようとするから、オブジェクトが他のオブジェクトと通信する(メッセージのやりとりを行う)にはまず他のオブジェクトへのポインタをもっていなくてはならないという全く理不尽な仕様になっているわけです。この、「ポインタをもっている」という考え方自体が既にオブジェクト指向とは似ても似つかないわけで、たしかに「他のオブジェクトを識別する」ことは必要ですが、それがイコール「ポインタで指定する」となってしまうと、話が微妙に摩り替わってしまうのです。
極端な例でいえば、ゲームをオブジェクト指向的に作る場合、弾オブジェクトが「当たった！」メッセージを送りたい相手はポインタではなく、位置関係で決まる場合の方が多いでしょう。それをポインタに対しておくるというのは滑稽です。
また、オブジェクト同志で送ることのできるメッセージがなぜか「実装時に」規定されているのも考えてみれば奇妙な話でしょう。送る方としては、相手が聞こうが聞くまいがメッセージは送れるのが常識というものです。
つまりこんなところにも、実は見えざる「コミニュケーションの断絶」が生まれていたわけです。言語仕様を読んでからプログラミングする癖のある方は、いままで全く疑問に思われていなかったかもしれませんが、オブジェクト指向という考え方自体には、ポインタで特定するようなものは一切ないことに注意してください。
逆にいえば、オブジェクト指向プログラミングとは、もはや手続きのプログラムではなく、コミニュケーションのプログラムとなります。クラスを規定し、オブジェクトを規定し、それらの間でやりとりされるメッセージを規定するスタイルのプログラムはもはやプログラムではなく、デザインと呼ばれる分野となるかもしれません。
いまの言語に決定的に欠けてると思われるのは、あるクラスがどのような使い方をされるか規定する方法がまったくないということです。
たとえばCBulletというクラスとそれを継承したCWeaponというクラスがあったとして、それがプログラムのどの場所でどのように定義されていたとしても、CBulletとCWeaponクラスの中身を見てみなければそれらの違いや役割、その関係はまったくわかりません。
そしてCPlayerが弾をうつときはCWeaponを生成するのかCBulletを生成するのかすら、コードのある一部分をみただけでは判断できないのです。
さらにいえば、それらは全く同一のレベルで扱われてしまうという問題もあります。CBulletであってもCWeaponであっても、どちらも即座に同じように new演算子を使って生成することができるのです。
自由度が高いのはC言語の良いところですが、オブジェクト指向的側面を台無しにする天敵でもあります。そしてC言語の自由度の高さは、真にハードウェアに即したプログラミングを可能にする場合にのみ有用だったことを思い出せば、C++言語の使われかたのなんと無法なことか。このことひとつとっても、C++言語がいかに無法な言語かが伺えます。
これからはオブジェクト指向ではなくてコミニュケーション指向、と言い直したほうが良いのかもしれませんね。そしてもっと真剣にこの方法論について議論されるべきではないでしょうか。
既にちまたには幾多のオブジェクト指向設計論が溢れていますが、果たしてそれが全てのプログラムに受け入れられる共通の道筋でしょうか。私はそのどれもが不十分なものと思います。
それらは現実の実務の中で生まれてきた方法論ですから、たしかに即戦力としてはいいのかもしれませんが、もともとオブジェクト指向的側面が欠陥だらけのC++言語を、使い方をシステマティックにするだけでエレガントなものに変えていくのは極めて困難だと思います。
むしろ、オブジェクト指向そのもののスタイルを定義しなおし、C++言語にかわる新しいコミニュケーション指向的な言語を創造していく時期に来ているのではないでしょうか。
といっても、私自身C++言語ですら使いこなしているとは言い難いのでえらそうなこといってすみませんというかまぁどうでもよいことなのですが、そんなことを考えながらプログラミングしています。
|
|
|
|