先日書いた
>というかラーメン屋の例えとかこれ読んでの話?＞KOJIさん

その後KOJIさんに聞いてみた所たまたまの一致だった模様、思考の同時性というか、あるいはある側面であるのかもなぁというカンジかな？
、、、とまぁ一応氏の名誉の為にもフォロー入れという所で(^^;;

----------------

列島暑かったらしいですね、ニュースで色々やってましたが、在宅仕事で現在追い込み中という事もあり、打ち合わせ以外外に出ないので全然実感ありませんでした. というかクーラー効き過ぎの部屋で毛布に布団かぶって寝ていたり(笑) 夜中出たカンジでは丁度良いカンジだなぁという印象だったんですが.

----------------

ダメな話、先日サルゲッチュを買いに行ったのですが、朝11時頃(現在は夜中仕事して昼過ぎには寝てしまう)のガラーンとして大学生すら禄にいないツタヤの店内をプラプラ歩くTシャツ姿の30近いヤローが一人、おもむろにどう見ても子供向けのゲーム、しかも発売日当日のものを手に取りレジに向かう、、、それはどーなんだ、と.

その後仕事の資料を探す為に山の手線の駅付近の本屋で買い物を終えガードレールに腰掛け、昼食時でスーツ姿でごったがえしてきた街中をコンビニで買ったアイスクリームを食べながら眺めて「そろそろ寝るかなー」という気分になったので原チャに乗って帰路につく昼下がり. ついでに昼飯時でガラーンとしてる近所の商店街で生活用品のお買い物「おばちゃんありがとー」みたいなカンジで.

、、、何か凄いダメ人間なカンジで「やめろーおれをそんなめでみるなー」という気分になった1日(苦笑)

それもまた良し(えー

「フリーソフトがソフトウェア産業を滅ぼす」だそうな. 何かいつもKOJIさんに言われている内容と殆ど同じだなぁ(というかラーメン屋の例えとかこれ読んでの話?＞KOJIさん) とか思いながらつらつら. まぁ実際言っている事は実際当たってるでしょうな(笑)

僕はまーアナーキズムの信奉者で自分の楽しみだけを追及する主義なのでこれについては何とも何とも、物事の是非なんて幾らでも後付けで理屈が付けられるものなので、別段これについて何か言うのも意味があるワケで無し、という所.

まーでもただ一つ言えるのは「それでも世界はそう簡単には無くならない」って所だろうなぁ、と. あるいは個人的にはそう思いながらレミングの群れのごとく海に向かうもまた一興といった所か.

# 後個人的には(少なくとも日本の)ソフト業界は一回潰れた方が良いんじゃない(※1)とも思うとりますが、例えソフト業界は潰れてもフリーソフトは残る辺りは再生のネックですな.

※1) 実際これが自分が.NETに期待する所だったり、クライアント系という小さな幅に限定されるものの開発の選択肢としてDelphi/C++Builder系のGUIデザイナを備えたC#/VB.netのデザイナ(VS2005ではC++/CLIでも使えるようになるらしい(※2)は非常に強力で、これによりクライアント作成の選択肢が増える事で例えばMFCとか一つの環境だけに固執しているともはや生き残って行けないような状態になるのはそれはそれで面白いかもしれぬ、という所 (無論僕自身も含めて、ね). そういう意味ではクライアントサイドのJavaにももっと頑張って欲しいのだが. まぁJavaもクライアント系に力入れてきたのは最近だし、.NETも結局はLonghorn(今だとVistaか)が出るまではベータみたいなものなので、そういった意味ではまだこれからかなぁと肯定的に考えてみたり、というかそうなって欲しい所、現状クライアント系のAppなんてほぼC++一択みたいなものだから、もっと楽がしたい、と.(その為にはパフォーマンスの問題がクリアされぬ事には、、、まぁ(笑)

※2) しかしMSのキャッチコピーにある「C++: .NET Framework プログラミング最良の言語」という表記はどーなんだ？と(笑) ただでさえ破綻しているC++を更に拡張するか、と. まぁ実際自分のメインで使っている言語ではあるものの、先日Javaについて色々書いたけど、C++についてはそんなの比では無い位に破綻した(というか破綻しないようにプログラマが自分で独自の使い方を考えなければならない)言語だと思います(笑) この言語のメリットは1つだけ、殆ど全ての種類のプログラムが余計な制約なしに書けるというただ1点のみに集約されるかと.

まぁでも仕様見る限りよくまとめたなぁと思う事しきり、オートボクシングや既存のソースコードの兼ね合い(NULL:=0を仮定したもの、これはこれで問題なのだが)もあるのだろうがnullptrの表記とか、CLR上の他言語との兼ね合いだろうがこのデストラクタとファイナライザの仕様はどーなんだ、とかまぁ色々思う所はあるけど(笑)

----------------

Rubyなんぞちらほら触ってみる、んー何か手続き型言語にObjectの概念を導入したというよりはむしろSmallTalk系の考えを手続き型言語とハイブリッドしたような印象だなぁと. 言ってみりゃクロージャなんだけど、久しぶりにブロックっていうデータ型を見たカンジだったりメタクラスがあったり色々、まぁ余り真面目には触ってませんが(^^;;;

----------------

「PCの高速化を巡る“果てしない追いかけっこ”」これまたまぁそんなものだろうね、とも(笑) まぁ所詮コンピュータ業界の都合なワケだったり、昔のMSXやx68000と比較すると数千倍の速度で動く今のPC、3Dなんかは特殊な分野なので除外して. MSの最近のVisualStudio.NETなんかは何処をどうやったらこんなに重くなるのか、というシロモノだったり、とするとOffice系も自分はかなり昔のものを使っているものの最新のものはもっと重くなってるのかなぁとも思ってみたり.

反面PCの新しい使い方というのは殆ど提示できておらず、そのエンドユーザーのコンピュータを使う目的は10年前と殆ど変わってないし、人間自体もそうそう進歩してない、とするとちょっと寂しくなってしまうなぁ、トカ. なんかね、PC自体が目的ってのはプログラマだけで良いよと思ってみたり、何かやっぱり妙な煽り方をしているようでコンピュータ業界というのもどうにも好きになれない、日経が好きになれないのと同じ理由(笑)

お仕事相変わらず多忙な日々にてLWプラグインのメンテはもう少し先延ばしの予定だったのだけど、たまたまTB_fakeSkinを使って下さってる方のページを見つけて見てみたら、、、何か変な影が出てる(大汗)

慌てて確認して見た所公開してた0.32にSheenパラメータの計算に以前書いた実験中のルーチンが入ってた模様、単純な形状では上手く行くものの複雑な形状では破綻する為実装を見合わせたつもりだったのだが、これまで発覚しなかったのはどうも自分が使ってるバージョンはその後ビルドし直したものだったらしく、該当ルーチンは外してたらしい、、、orz

という事で慌てて更新、内容は以前の計算方式に戻したのみです. 一応影になっている領域についても正確に割り出す方法はほぼ見えているのだけど、オブジェクトがレイトレース的に「ソリッド(※1)」でなければならず、作成に微妙に気を遣わねばならないので、安直さが売りのTB_fakeSkinで実装するかは悩み中、若干計算コストかかるし.

まぁ、実験中の方が良いという方がいたら連絡下さいという所にて. 実際悩み中.

なお一応影まで含めて正確に動作するコードのテスト版をTB_ShaderManのVMアセンブラに変換したもの こんなの見て誰が嬉しいんだ、というカンジもしなくはないが(笑) まぁコイツの中身はこんなカンジという所にて、デバッグ機能で吐き出したものなので関数ごとのスタック使用量の分析前のもの、またラベルは実際にはユニークなシンボルになっているカンジ. ちなみに現状ではソリッドのレイトレをある程度真面目にやる関係で両面オブジェクトのみサポートで機能し背面は勝手に透明になるという仕様、やっぱ分かり難いよねぇ

※1 ここで書いているのはLWのレイトレース計算でソリッドという事、自分自身のポリゴンへの衝突を考えない場合は単に両面オブジェクト(但しそのまま両面だとレイトレースでジオメトリの形状が出る嫌な影が発生するので裏面は透明度100%のサーフェスの方が良い) またBSSRDFのようなシェーディングスポットの周辺の影響を受けるものを計算する場合、LWがその時点でシェーディング計算されるポリゴンを交点検出の対象としない為そのままではおかしな結果になってしまう. これを避けるには別途裏面を表す空気のサーフェスを表現するポリゴンを作成し、元オブジェクトと「マージさせないで」同じ座標に並べる必要がある(マージされるとLWが表裏を同じポリゴンとみなしてしまう為)

またサブパッチの場合は同一レイヤの同じ座標にある頂点は自動的にマージされてしまう為、空気のサーフェスを別レイヤに配置する必要がある. 実際自作のTB_ShaderMan向けのSSSシェーダ(未公開)やOGO氏のOGO_Hikariなどはその方法でSSSのサンプリングポイントを見積っているのだが、これってエンドユーザー的には非常に分かり辛い話なのではないかなぁ、と＞実装を躊躇する理由

2005/07/22追記)
上のアルゴリズム、両面オブジェクトでも何とかなるかと思っていたが、やはり上に書いたソリッドオブジェクトでないと幾つか不具合が発生する模様、はてさて. というかこれを前提にするならfakeSkinで無くちゃんと光源の浸透まで意識したSSSが書けてしまうのだが(笑)

----------------

ちょっとレポートだけ、調べてもらった所では例のTB_ShadowCompなどであったLWの屈折率の扱いの問題、G2やOGO_Hikariなどではやはり独自にTLSを使用してエミュレートしているらしい、ただプラグインの限界として(何度も書くけど、本当はSDKがこの部分を公開してくれれば全てのプラグインで上手く行く)

LW標準のサーフェス->G2のサーフェス

などといった場合や

OGO_Hikariのサーフェス->G2のサーフェス

などといった場合には正常に処理されなくなるらしい、一応これら全てをカバーできるバージョンは作成しているのだが、ユーザーインターフェイスが少々分かり辛いのと、その説明を書くのが面倒な為、もうちょい先送り.

ちなみに前にも書いた通り、現行のLWの屈折率の計算はソリッドな物体では裏面の空気のサーフェスを電卓を使って屈折率を計算する必要が無いだけで、逆に板ポリでガラスを表現する場合に回避不能な不具合が発生する等、特になんのメリットも無い :-<

----------------

後はTB_ShaderTreeが一部のノードのパラメータ追加&ScreamerNet使用時の不具合修正、後は誰が使っているのかという(笑) TB_ShaderManの修正(これはまだ途中)などもあったりするのだが公開はもう少し先、少なくとも今は仕事を片付けねば、、、(多分来月一杯は多忙)
LW8の新機能対応やバージョン特有の問題については少なくともLW8.x系列のバグがちゃんと直ったバージョンが出るまで据え置き :-<

# というか日本でTB_fakeSkin使ってくださっている方がいて少々驚きだったり(笑) 海外では割と評判良いものの、国内はやっぱToon系がメインなのかなぁと思っていただけに(^^;;

----------------

余談、KOJIさん曰く所によると彩のソースはパンチテープにしておよそ7kmあるらしい(笑)

そうそうVS2005にはよく話しているシンボルのリプレースでコードで使用している個所を全部自動で構文まで含め修正してくれる機能やその他もろもろのIDEでの開発補助機能がリファクタリングとしてつくらしーよ、とドキュメントや関連リンク見る限りではC#のみでC++はまたも蚊帳の外みたいな予感がするけど、と何故かここに書いておく.

Javaについて調べててちょっと興味深い文書を見つけた.

2年程前のもので真偽の程は不明だがSunの内部文書だそうな、つまりはSunのエンジニアが「Java使えねー」と言っているような話らしい.
http://www.internalmemos.com/memos/memodetails.php?memo_id=1321
http://developers.slashdot.org/article.pl?sid=03/02/09/1347215&mode=nested&tid=108

日本語での各章の要約紹介
http://groups.yahoo.co.jp/group/jvm-talk/messages/61?expand=1

日本でのこのトピックに対する風評を調べてみた所では「Solaris環境の話でしょ」というような意見もあったのだが、個人的にはそれだけでは無い印象を受けた.

ここの記事に書かれている起動が遅い件については事実とは思うものの、実は左程問題では無いと個人的には思う、というのもJavaそのものの設計思想の根本には関係無い為(商用展開する人にとっては大問題だろうが)

バグ修正が緩慢である点についても同様、これもSunの企業風土における問題でしか無い.

問題はライブラリの拡張性の限界とメモリ消費の部分、これはJavaの比較的粒度の細かいObject抽象化でライブラリを設計し、それが複雑に絡まりあった形でクラスライブラリによる世界を構築するという根本的な設計論に起因するもの.

またそれに絡んだ後方互換性の問題はこの方式のクラスライブラリの設計手法の限界とそれを商用に利用する際に発生するビジネスモデル的問題、そしてこれを解決しようとするとライブラリ拡張性の問題を更に悪化させるという悪循環に陥る事になる.

----------------

まぁ実際自分はJavaをメインで使ってはいないのでこの文書で触れられている細かい内容についての真偽の確証は無い、起動が遅かったり、後方互換性が問題になったり、メモリ消費が大きかったり相互依存したライブラリのメンテナンス性の低さという問題は実際その通りだと思うが.

# 余談だが、メモリの問題などはプログラムの仕方によってある程度解消できるのは確か、ただJavaはその部分が過度に隠蔽されている為、新人プログラマが適当なコードを書いてしまいがちである事、またそれを解消するとC/C++のメモリ管理などより遥かに複雑なVM内部の実装まで意識してプログラムを書かねばならない、という所は正直どうかという気がする.

# 後Javaに関しては「プラットフォーム非依存の閉じたライブラリ」という所が、言語及びライブラリ (今の時代はもう言語=ライブラリになっちゃった部分もあるけど) を恒久的にメンテナンスを続けなければ言語自体の閉塞を招いてしまうというトコロも欠陥の一つだと思ってたり、まぁシステム屋にしたら良い飯の種かもしれないけど(^^;;

----------------

しかし、MSの.NETも同じような「相互依存した粒度の細かいクラスライブラリ」という設計なのだよねぇ、今はまだ出たて、というか少なくともLonghornが出るまでは所詮ベータのようなものなので上記のような問題は表面化してないし、ある程度OSにビルトインされているので起動時間などはそれ程問題は発生しないけど、メモリに関しては少なくとも初期状態では馬鹿食いしているし(C/C++で書くのの4倍程度)まぁ、それ程大きなプログラムを書いているワケでは無いのでそこから長時間プログラムを起動し続けた場合の状態は不明ではあるけど、でも同じような設計思想である限り、潜在的に同じ問題を孕んでいそうな気もしたり.

はてさて、未来のプログラム環境はどうなるのやら、楽しみなような、不安なような(苦笑)

# こうなったら例の有名な「D言語」 IBM辺りが買い取ってちゃんとした言語仕様として出してくれないかなぁ、今のままの状態ではまぁ自分で触ってみた感覚やTANEさんの日記を読む限りでは言語設計で一番マズい後から仕様の問題が発覚して言語仕様を継ぎ足し、みたいなカンジでグダグダだし. 失礼な言い方かもしれないけど余り作者に言語のセンスを感じない気も、、、コンパイラ書きとしては有名な人だけど.

あー、でもIBMってREXXとか作ってた所だっけ、ダメかも(ぇ
訂正、IBMのラボ辺りで買い取って、ある程度設計者達に自由に作らせる方向で(笑)
そういやAPLもIBMのラボでやってたっけ?(オリジナルは別) んー実際自分でもそういうタイプのインタプリタ書いてみた事あるけど、一括演算はやっぱ人間の思考にマッチしてないのかなぁ(とそれ以前にあの独自の記号定義も(笑)

----------------

何かこういうトピックを書くとアンチJavaあるいはアンチObj指向みたいだけど、実際そういう訳では無く、本当に分からないので知りたいという所なんですな. ある程度粒度の粗いクラスライブラリが開発効率に貢献する所は確かだと思うのだが、Javaみたいな(ある意味古典的な)粒度の細かく各モジュールのドメインを切り分ける事無く、全てを表現するべく複雑に入り組んだクラスライブラリが単に開発効率だけで無く、メンテナンススケジュールや拡張性まで考慮した場合に本当に「良い設計」なのかというトコロ、またそれがプログラムの実行される環境を全て独自に定義するようなやり方が本当に有用なのかどうか、と.

なんだかんだ言ってもその辺でライブラリによってほぼ完全に世界まで規定されていて、ある程度まともにこなれる位使われている言語ってJava位のものだし (SmallTalkは更にオペレーション環境まで規定しているけど、あれはコンピュータサイエンスやその後のアーキテクチャには大きく貢献したけど、言語自体としては失敗だし) Javaはある分野で大成功を収め、またある分野では大失敗になっている訳で、ただその成功した分野での要因はこういったJavaのObj指向に対する取り組みの思想とはまた別の部分にあった気もするし、しかしそれを真似て今MSも.NETで同様の道を歩もうとしていたりするワケで、そういった意味でその辺りを真面目に知りたいと思うのですな.

KOJIさん(最近は「兄貴」と呼ばれているらしい(笑) SAIのDLページに自画像が(えー)) なんかとよく議論する話なのだけど、大規模かつモノリシックなクラスライブラリは果たして有効なのか、また先日書いたようなUnixなどオープンソースの開発手法はエンドユーザーまで見据えた時に本当に有効なのか(これは手法以外にそこを構成するプログラマの姿勢も要因になるが、特に複数人のものでは総じて横に広がる傾向にある) 現行のUnixも大規模クラスライブラリも中から風化しているバベルの塔を日々継ぎ足さねばならぬ問題に行き着いてないだろうか、そしてその集合に依存するコンピュータ環境は本当に「良い設計」なのか、よりシンプルな解で現行の複雑化したソフトウェアを作る事は本当に不可能なのだろうか、複雑化した現在のアーキテクチャの中で末端プログラマに人並みの仕事をさせるアプローチの解が果たして本当にそのベクトルだけなのか、ソフト業界のトレンドと言われるものは本当にユーザーをターゲットにしたトレンドなのか、キーワードを変えて同じ事を焼き直しつづけてるのではないか等々.

何か微妙にいびつな気がするんだよねぇ＞今のソフトウェアの姿.
実際複雑化したシステムにおいてはある程度の抽象化がなければ効率的では無い事は間違いないのだけど.
、、、などと書くと時代に取り残された年寄りプログラマのようではあるが(苦笑)

、、、ああ、でも同じ世界を定義する巨大クラスライブラリ(フレームワーク的なもの)を作らせるなら、それを想定したメーカーに作らせる方が下手なユーザーに作らせるよりははるかに正解だとは思います(笑)

----------------

仕事、、、忙しいです、でも微妙に楽しくなってる自分がいたり(笑)

以前から書くべきや書くまいやと悩んでいたのだが、少々気になる出来事があったので表題のものについて自分の思う所など書いてみる事に.

---------------

まず最初に、ある程度経験を積んだプログラマなら、大体はソフトウェアが動くのを見ただけでどのように作られているかは殆どの部分について想像がつく. そういった意味ではここに一般の感覚との若干の乖離があるのだが、プログラムの世界で本当に「画期的」なオリジナリティに出会える例は非常に(僕の感覚としては)少ない.

このオリジナリティの認識の部分も差異があるが、学会発表の論文などで展開される独創性など(これもピンキリだが)と比較する時にそれ程の独創性があるものはやはり少なく、そういった意味ではある程度プログラマなら論理的帰結として行き着く所の必然でしか無いケースが殆どだと思っている.

そういった意味ではアイデアに限定すると、そのアイデアの独創性として尊重すべき所はごくわずかであると考えている、しかし一方でLWのプラグインの開発など、そもそものプログラマ人口が限られており、コンピュータ全体の世界のように無尽蔵に優秀な技術が集まるのでは無い環境では、そのような姿勢がある意味コミュニティ全体としての利益を損ないかねないという事も認識はしている(ここに理想と現実のギャップがある)

しかしこうした「馴れ合い」あるいは「紳士協定」的なものも過度になると問題となると個人的には考えている. 若干ファンには申し訳無いが、その際たるものが現在のUnix文化ではないだろうか.

例えば先日libpngをコンパイルしようとした際にzlibが別途必要と言われてしまったのだが、png圧縮に使われているlz77+Huffman符号化などは単体で作ってもそんなに難しい話では無くソースモジュールとしてせいぜい数百行もあれば簡単なものは出来てしまう.

そういった意味ではこういった行為は「誰かが既に作っているものは作らない」という観点では正しいしプログラマのエゴを傷つけないという意味では紳士的かもしれないが、同時に依存するライブラリを増やす事でプログラム全体としてのメンテナンス性を落としてしまっている.

正確に言うとこのモデルでメンテナンス性が向上するのはユーザーが各モジュールを恒常的にメンテナンスできる状態であればメンテナンス性は向上するが、これをエンドユーザ層をターゲットとして、そういったメンテナンスを除外すると逆に使い難いものになる.

また各モジュールを作成しているプログラマも人間であり、殆どのケースでその実装はデザインとして完全では無い. この状態で「既に有るものは作らない」という話になってしまうと、これは開発者の興味が無い部分については全く改善改善されない事になってしまう. そしてそれが現状のUnix文化がある意味繁栄しながらもエンドユーザ分野では決してWindowsを越えられていないを理由を反映していると思っている.

---------------

と、ここまで書いて疲れた、やはり文章を書くのは苦手だと痛感.

別にこの意見を他人に押し付けるつもりは無い(それこそ傲慢だ) 世の中には様々な多様性があり、幾ら「そうあるべき」と振りかざした所で結果は様々なエゴのぶつかり合いによって世界は構築される、その中で個人が取り得るのは「己が何を信じるか」によりそれに向かって進む事またその結果に対し理想を実現する為に対応する事であり、自分の理想の通りにならない現実に対し愚痴ったり他者に無理矢理個人の理想を押し付け自分の思い通りに動かすような試みはそも論外だと個人的には考えている.

そしてこの態度はそのままそれが自分に跳ね返ってきた場合でもやはり享受すべき内容だろう、何故ならそれなくして進歩は無い為で、またそれでやる気をそがれるような話ならば己がその程度のものしか作っていなかった事に他ならない.

とは言え、例えばこの話にマーケットが絡んできた場合、やはりフリーというのはフェアでは無い気もするのは確か、ある種の技術屋としての理想に対し現実はそこまで強固では無いというギャップがそこにある.

しかし余り悩んでいても仕方が無い、ある意味こういった問題に明確な解は無く、理想や思いは人の数だけあり、世界はその相互作用の中で形作られる、その要素たる個人に出来る事はその中で己の出来る事をやるだけの事、それが自分にとっての解であり、またそれこそ世界を憂うような事こそ正に自意識過剰だろうと思うのだ.

---------------

余談その1)
上に書いた内容はTB_ShaderTreeの以前のGUIの件と矛盾するようだが、あの話で実際自分が最も問題と思ったのは上で挙げているような話では無くGUIの酷似性の紛らわしさ、またそれ以前に自分がShaderManの名を冠する別のプラグインを作っていた事の紛らわしさからAlexei Puzikov氏に迷惑を掛け兼ねないとの懸念があった事が理由になっている.

またTB_ShaderManの名前は昔あったDynamic Realities社(比較的有名なLWのプラグインベンダ)のLWプラグインのShaderManに対し、書籍のサンプルを移植した程度のものを実体の無いRenderManというブランドだけを振りかざし (実際RenderManの最も偉大な部分はシェーディング言語などの高いカスタマイズ性と厳密に考慮されたテクスチャやAA、モーションブラーなどのサンプリングロジックにあるのだが、単機能のプラグインとして落とし込みその他のエンジンをLWのものにしてしまった時点で、その優位性が完全に抜け落ちてしまっている、特にサンプルにあるシェーダアルゴリズムはごく教科書的な内容で他のレンダラと比較して何の優位性も無い) で製品として金を取るという事に対し、技術者のモラルとしての皮肉と疑問提起があり、それが自分にとってShaderManという名前でなければならなかった理由でもある.

# 更に余談だがRenderMan程ブランドのイメージと実体が誤解されているソフトも少ないのではないかと思ったり、個人的な感想としてはRenderManはレンダラというよりは、むしろ3Dのレンダリング環境を構築する為のミドルウェアという方が正しいと思う. 少なくともプログラマ的にRenderMan環境に関与するアプローチでは無くただエンドユーザーとして単品のレンダラとして触っても、ショボいレンダリング結果にしかならず他のレンダラの方が遥かに良い結果を出すようなシロモノ.RenderManのアドバンテージはそこからカスタマイズした時に非常に高度なクォリティにまで拡張できるポテンシャルと、その際のクォリティに対するアプローチをサポートする優れたエンジン(テクスチャ, AA, サンプリング, Displacement, Blur etc.)にあると思ったり.

聞いた所によると国内のPRMANのライセンス販売実績は殆どの場合1社につき1ライセンスとかそういう具合らしい、殆どが話題になっているから買ってみたものの使いこなせずお蔵入りになってしまっているそうな(^^;;

---------------

余談その2)
実生活でたまに技術屋以外の人たちから「それ特許にしたら」という話を言われる事もままあるのだが、この辺が正に技術屋と一般の感覚の乖離でもあるのだろうと思っている.

友人のプログラマとも話すのだが、技術屋にとっては論理的帰結であっても一般の感覚では「素晴らしいアイデア」のように思えるのかもしれない、ただそれはやはり自分の技術屋としてのプライドとして耐え難い部分がある、「ただ思いついた」内容には実は殆どの場合何の価値も無く、それを比類なき完成度にまで磨き上げ、その上で最初のコンセプトを明確に提示する事こそが価値だと思うのだ.

なお更に余談だが(主に企業の)研究者(特に一線を退いた研究の統括の立場にいる人達)とも若干の付き合いがあるが、彼らは専門職であっても比較的「それ特許にしたら」と言われる、まぁ彼らはそれが仕事だし、コンピュータに絡む特許には取ったもの勝ち的な部分もあるのでそれもまたそういうものだろうと思って聞き流していたりする.

# まぁここで文章の便宜上技術屋としてなどと書いたがある意味「〜として」などという定義付けもまた無意識の自己規定でしかなく本質的に無意味ではある、ただあるのは一人の個人として自分がやりたいかどうかというその部分だけが重要だろう ;-)

---------------

ま、ある意味自分はあるベクトルの極端にいる性格の人間で、例え友人であっても「力の無いものは滅びろ、それが嫌なら精一杯もがけ、中途半端な自己満足など何の価値も無い、お前がどう思おうと現実の結果に現れるもの、それだけが全てだろう？」(※1)などと平気で言ってしまうような偏った性格なのでヨタ話程度で聞き流してもらえればという所にて.

※1) これはほぼそのまま以前演劇をやっている友達に言った内容だったり(笑)

# ま、でも何かあった時にこんな事を書かずにおれぬ辺りまだ未熟である証拠であるなぁ(苦笑)

プラグインはお休み、のつもりだったが仕事の待ち時間に少々TB_ShaderManの速度評価をしようと思ってシェーダを読んで他のサーフェスにコピーしようとすると(シェーダファイルにもよるのだが)どうにもLWが不安定になって固まったり落ちたりする.

サーフェスのコピーで発生するのでTB_ShaderManのその部分(実際にはプラグインのSave&Loadルーチンが呼ばれている)にバグがあるのかとも思ったのだが、何処も変な所は見つからない、仕方ないので少し詳しくデバッガで追って行くとプラグイン側のSaveルーチンが呼ばれた後に呼ばれるLW本体のルーチンの中で確保されたメモリがオーバーランしてしまっているのが原因らしい.

TB_ShaderManはVMのコードをそのまま保存データにしてしまっている為、保存されるデータが比較的他のプラグインと比べると大きなデータになるのだが、どうもそれを一括して書き込んだ場合にLW側が上手く保存データの拡張がちゃんとできていなくて誤動作している模様. 試しにバイナリデータを書き込む際に一括して書き込むのでは無く、1バイト単位で書き込むようにするとちゃんと動作した.

プログラマなら大体予想のつく話ではあるのだが、おそらくはLW本体がプラグイン用に用意している保存用ストリームのバッファが足りなくなった時に適当なサイズで継ぎ足したバッファで全てのデータをちゃんと格納できるかのチェックをしないでそのまま処理してしまっているという所が原因ではないかと思う、、、当然SDKにもそんな制限は書いてないワケで、、、まぁメンテの苦労は分かるんだけど(苦笑)

という事で結局LW側のバグが原因、ちなみに最新版でも直っておらず 7.5, 8.3の両方で発生するの模様につきプラグイン開発者の方はご注意を、とは言っても比較的サイズのあるバイナリの塊をそのまま保存データにしているプラグイン位しか顕在化する事は少ないと思いますが (とまぁそれも嫌らしいんだけど :-<

# ま、これもベクトルテクスチャやスペシャルバッファのバグに比べたら回避策があるだけまだ可愛いものではあるのだけど X-<

昨日書いたMSづいているという話、.NETやCOM環境の想定するマルチ言語環境に絡んで色々なスクリプト言語処理系についてもつらつら見ている. (元々言語処理系ヲタクなのですな(苦笑)

スクリプトを取り巻く事情もずいぶん昔とは変わった、昔はスクリプト言語と言えばプログラマの日常的な作業の補助の道具だったのが、今では技術の底上げとして一般的にも使われるようになってきている. 例えばPerlなんかは丁度その移行期をまたいだ言語なんでなかろうか、元々はUnixのテキスト処理やバッチ的処理の為の道具 (実際BBS時代にはログの処理とかでお世話になったし、今でもソースコードのちょっとした加工などに使っている) だったのが、今では一般ユーザーの目に触れるWebページなどを使うのに使われ、サーバ側で大量のインタプリタインスタンスが動作するようなものを要求されるようになっている(※1)

暫く見てないうちにJavaScriptも2.0が発表されている模様、というか言語仕様の根幹 (インタプリタを実装する場合の基本的なデータ構造) に当たる部分がかなり変わってて、最早別言語なんですが(笑) .NETのJScript.NETの拡張ってこれを元にしてたのね.

Perl周りもPerl6を控えてParrotなんてものまで出ている模様.

しかし、本当にそれで良いのか? という気もしてくる. JavaScript 2.0にしてもPerl 6(それ以前にPerl 5の頃から感じてたのだが)にしても、その言語をより万能なものにする為に仕様を複雑化させている気がする(※2)

本来スクリプト言語のメリットは本物のコンピュータ言語では手間がかかるものを、特化型である代わりに手間をかけず実現する所にあるのではないだろうか？こういった言語コミュニティで良く見るパターンなのだが、ある程度言語に「信者(笑)」がつくとユーザーはより高度な機能を要求するようになる、また開発者もプログラマのエゴとしてより万能な言語設計をしたいという思いから言語を拡張しようとする. しかしそれは果たして本当に正しい方法なのだろうか？

実際自分も8bit時代のBASICなどで同じ穴のムジナだった経験があるのだが、最終的な現在に至るまでの経験からすると単一の言語に固執する事は最終的には全くメリットにならない、所詮プログラム言語は道具でしか無い、もっと冷静に状況を見つめる必要があるのでは、と思ってしまう.

# 余談だが個人的に言語処理系の解析ルーチンにバグがあるというのは断固として論外だと思う (ランタイムにバグがあるのはある程度仕方ない) この部分がしっかりしているかどうか (つまりはそこから見える実装者のソフト開発に対する哲学) が個人的にはその言語を信頼するかどうかに繋がっている、プログラマがプログラムを書く上で絶対的に信頼できなければならない唯一の道具だと思うからだ(そりゃOSやクライアントプログラムも信頼できるに越した事は無いが(笑)

# そしてエンドユーザーにとってはそれがソフトウェアそのモノに対してである事もプログラマとして自戒すべし＞自分(苦笑)

---------------

※1) 実際には多量のアクセスがあるサーバでCGIでPerlなどは最早余り使わないし、規模にもよるがエンプラではServlet周辺にシフトしているし(小規模は知らんが)、Windowsの馬鹿チョンはASPがメインだし、フリーコミュニティでもPHPなどの方がよりモダンだったりするが、例えなのでその辺のツッコミは取り合えず置いといて下さい(笑)

※2) まぁJavaScriptなどは対象とするのがプログラマというよりはエンドユーザーに近い層という特異な周辺事情から、この仕様が受け入れられるかどうかは言語マニアとしては興味がある. 型付言語はそれに慣れたプログラマの感覚ではバグを減らす上で非常に重要なものと思う(Lispのような概念のものは除くが) しかし自分もそうだが、初めてプログラムを書いた時の感覚などは大抵忘れてしまっているので、そういった意味では一般的な感覚として型付言語や明確なクラス定義などが一般にどの程度受け入れられるかは興味がある. またオブジェクト指向は本当に一般的な感覚として受け入れやすいのか、など (ある程度の抽象化レベルまでは実際その通りだと思うのだが、Javaのクラスライブラリのようなタイトかつ入り組んだスタイルのものは個人的には一般的な感覚に合致しているとは余り思えない気もしていたり)

最近妙にMicrosoftづいている、HTAやWSHを勉強してみたり、COMの再勉強をしてみたり、.NETの周辺動向を調べてみたり. 実際自分も他のよくあるプログラマのリアクション同様あの会社は好きでは無いのだが、実際発表する技術の着眼点はある程度的を得ている部分があるし、まぁ大抵は既存技術のパクリだが、それでもその改善点などはちゃんと見ているし、そのパクリという話にしても大元を辿ればオブジェクトの環境 (Windowsの場合COMの空間,WindowsDNA構想の中核) としてのシステムや現在のGUIデザインはは遥かSmallTalk (1970年代後半) まで遡るので左程問題でもあるまい、企業としての姿勢も他のビジネスコンペティタに対し後出しジャンケンな傾向はあるものの、それも商売という点では非情なものなのでまぁ仕方なし.

Longhornと64bit化が間近という事もあり、そろそろWindowsの開発にも大きな波が来る予感もするし、でも結局来ないような予感もしている.

少々前から気になっていたLonghornのAvalonについて書かれた資料を読んで見るが、何かインターフェイスとしてはJavaAppletに似ている気もする(セキュリティはMSお得意の証明書でユーザーに責任を負わせる形で逃げるのだろう) あるいはXAMLの役割としてはリソーススクリプトの拡張といった印象を受ける. 鳴り物とは言え実体が見えると何か手堅い話だなぁという印象. ある意味画期的な可能性とも言えるがある意味ありきたり. まぁこのフォーマットの最終出力が人間が可読できないものでも良いのなら (というかある程度以上の規模をもったXMLが人間が読めるものと言い張るのか？(笑)) 今のFlash程度のものは作れるような気もするし、それならどうせなら画像とかのシーケンスにも対応してDirectorとかの地位も奪っていただきたいとも思う. 結局の所タイムラインを持ったFlashやDirectorライクなオーサリングツールがそのままXAMLを吐き出して、ハンドラをC#やVB.NETあるいはJScript.NETで書けば良いだけの話であり(※1) クラスのセパレート実装があればそれで済む話. ある事を効率的に行うのに複数の環境を考慮するよりは単一の環境で済む方が憶えるものが少なくて楽だというトコロ ;-)

※1) とどのつまりリソーススクリプトの中に今まではプログラム側で設定してた細かいプロパティやコード側のハンドラコールバック定義、そしてタグが従来のような生成のテンプレートでは無くインスタンス本体の生成に使える為より透過的になるという所か、後は.NETの大きなメリットの一つであるMixed Language環境で呼び出しが透過的に行える点 (ManagedC++は除く(笑)、、、まぁそれもCOMよりは楽だが)と結合した時に大きなメリットを生みそうな気がする. Flashのように限定したインターフェイスで良いのであればコードをプログラムで書くのでは無く、オーサリングツールのようなものに生成させるのもまた手かもしれない. それがそのままCLRのコードになり、プログラマが書くのはハンドラ程度で済むという話になる.

.NETは結局の所複雑になりすぎたWindowsDNA構想を再設計したようなものなので、そういった意味ではそんなに状況は変わらない予感もしている. 一時の噂では.NETフレームワークがそのままWinFXとして次世代OSの基本APIになるという話だったが、最近の64bit Windows環境の話題を見ていると、どうもWinFXがそのままWin32に置き換わるような事は無いのではとも思ったり (というか完全に置き換える気ならWin64など作る必要は無い気がするのだが). 最近の.NETやLonghorn周辺の開発事情、64bit Windowsの動向などを調べれば調べる程、結局の所WinFXとWin32/64の2本立てになるんじゃないかなぁという気もするのだが、、、はてさて(※2)

※2) この観点は.NETが幾ら優れていようとやはりエンプラ系など定型化したプログラムは良いものの、非定型のものが殆どであるクライアント系プログラムを作るのにこういったアーキテクチャは余り向いてないと個人的には思うのだ、とは言え.NET Framework自体のポテンシャルは大きいので、そういった意味ではクライアント系であっても今のVB6+COMのソリューションよりはカバーする域は広いと思うし、システムの親和性もVBで無理矢理Win32を使う程醜悪な様相は呈さないとは思うのだが (たまにそんな無理矢理VBでやらなくても、、、というコードもあったりするし、やはり技術のトレードオフポイントの見極めはきっちり考えるべきと思う.

# 余談だがC#は鳴かず飛ばずの状態、.NETもエンプラ系はそこそこなもののクライアント系は全然だそうな、そういった意味では昨今のMSのアクションは当初の構想の軌道修正を迫られている様に見える気もしたり.

---------------

# ま、時間が無いという発言も実に意味の無い話、時間なんてものは作るものなので、結局の所それだけのモチベーションがあるかどうかだけの話にて;-)