言っちゃった
その「ユーザ事例」の一つに私は居ます!!名前は消されましたけど('A`)
あと、RawSPU,SPUThread,spursのうち、SPUThreadだけがどうにも中途半端なもんで、後はスレッド切り替えが頻繁に起こるていうたらこれはspursしかないだろう、という思考過程での推測です。まあ自作モジュールとか自作spursを作っている可能性もありますが。
あと、勘はとっても大事ですが勘だけじゃやっぱ天才にしか開発できないんで誰だって或る程度は試行錯誤のフェーズに入るわけなんですが、いかにそれを楽にできるか、それがフレームワークなるものの役割の一つかもな、と思ったりするわけです*1。
ちょっと話は飛びますが、
http://www.ce-lab.net/ringo/archives/2007/02/12/
曰く
yahoo pipesが証明したことは、
1 データに対して、十分にメタデータが付いていること
2 メタデータの付け方が十分に標準化されていること上記をある程度以上のレベルで実現すれば、
視覚的プログラミングは可能になる、ということだ。
これは、「yahoo pipes」の文字列を「カプコンのＭＴフレームワーク」に置き換えても成り立つのです。
Game Watchではフォーカスされていなかったのですが、CEDEC2006での講演の際に開発者が述べていた点でプログラマ的に非常に大きなポイントがありました。
それは、次の２点です。
- ＭＴフレームワークから編集可能なオブジェクトは、特定のクラスから派生して作成すること
- 編集可能にしたいプロパティ(変数)「は特定の方法で作成すること(メンバ変数なのか、基底クラスに変数管理用コンテナがあるのかは不明)
こうすることで、ＭＴフレームワークがオブジェクトを認識し、オブジェクトの編集可能なプロパティに対するＧＵＩが自動的に構築されるそうです(講演のメモは残っているのですが解釈が間違っているかも知れません)。講演者は、「とにかくメタに物を作っていくこと」を強調されていました。
また、ＭＴフレームワークの特徴として構造化されたマルチスレッドタスク管理があるのですが、CEDEC2006ではこのマルチスレッドタスク自体をＧＵＩで編集するデモを見せていました。普通、マルチスレッドの処理単位の管理というのはソースコード上で行うものです。しかし、MTフレームワークはＧＵＩでそれを行っていたのです。
ＧＵＩがどの粒度まで実装のプロパティをいじれるのかは分かりませんが、これこそまさにビジュアルプログラミングというものなのではないでしょうか。
視覚的プログラミング、というのはハードコーディングの手間を極限まで減らした環境である、という側面を持つと思います。ハードコーディングが少ない環境すなわち、試行錯誤のコストが激減する環境、そう見ることはできないでしょうか?
とにかく、変化することを前提においた開発スタイルが、規模が巨大化していく世界では必要なのではないか、と、そう感じています。ネガティブな事例を書くのは私のスタイルではないのでこの辺で止めておきますが、やっぱり不毛なことに苦しむのは不毛だよな、と思うわけです。それこそQNaNのように不毛は伝播していきますので。
そして私の某事例は、次世代における試行錯誤のコストを減らす為の一つのあがきでもあったりするわけなのでした。
ふらふらとポイントがずれてつかみどころの無い話をぐだぐだと書いてしまいました。ちゃんと相手してもらってるみたいなので、こちらからもリンクを貼らせてもらいます。
