晴れたのでようやく仕事に、もう12月なのでそろそろ本腰入れて動いた方が良さげ.

先日書いた既存の(クラス機能を持たない)スクリプトをGC対応にする作業は完了、ついでに今までのDLL/COM呼び出しに加え.netアセンブリの実行をサポートしてみた、こんな具合.

a=dotnet("mylib", "MyLib.Foo")  /* mylib.dll内のMyLib.Fooインスタンス生成 */

if(r=a.exec("D:\\")){
    //何か適当な処理
}

まぁ大して難しい話では無く、実際の実行はpublicなアセンブリのクラスをIDispatchでラップして使う方法、内部的にはCorBindToRuntimeEx APIを使用してCLRを内部で起動し、Appication DomainでロードしたアセンブリのインスタンスをスクリプトにDispatchしているだけ、アセンブリは動的に結合されるのでregasmでの登録などは必要無い;-)

しかしCLRを無条件でロードすると初期状態で10MB、アセンブリの実際の実行時は20MB以上食うようになってしまうので、必要に応じてCLRを動的にロードする事でメモリ条件はそのまま据え置きになるようにしてみた (というか.netが馬鹿みたいに食うのも問題だが、、、密結合ライブラリの宿命でもあるけど:-<

それ以外ではGCルーチンも100万個程オブジェクトを生成するストレステストをしてみた所結構GC実行によるパフォーマンス低下(50%程度)が見られたので少々GC条件を改善してみたり.

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

Webを巡回していて見つけたものコーナー

mtasc ActionScript2.0のコンパイラ、Java(ECMA)Scriptのソースからswfを作成可能

へぇ、こんなものもあるんだなぁ、といった所. その方面では結構有名らしい. ざっくりと触ってみた所では、、、うんFlashだ(笑)
処理系としても少し触った限りではかなりロバストで好感が持てる印象(個人的に言語にとって非常に重要な要素だと思う)

Flash独自のタイムラインによる(その他のプログラミングモデルに馴染んだプログラマには)微妙な分かり難さはあるものの、基本的にキャンバスに対しデコレーションする要素を配置してどーこーするモノなのでオモチャとしては楽しめると思う.

ただ粒度の細かいオブジェクトの配置を全てスクリプトでやるのは効率が悪い (その部分は少なくともFlashアプリケーションの方が遥かにアドバンテージがある)のでそういう素材はFlashなりで作って(実際テキストのベクタライズなども考慮するとそんなもの手書きで書くべきではない) それらの素材を組み合わせてより大きな相関関係のあるアルゴリズムを記述する (こっちはスクリプトのような手法の方がアドバンテージがあると思う) のが正しい使い方なのかなぁなどと思ってみたり.

なお日本語を使用する場合はエンコードをUTF8で使用すれば可能な模様.

# ただやっぱりFlashはFlash、安直に作るGUIの製作としては極めて限定された機能しか提供していない. Flashは(買収されてから若干鳴りを潜めたが)エンプラ系のソリューション分野を目指すなら(少なくともこの分野の)「プログラマの大半は綺麗なGUIのデザインセンスが無い」という所にもっと明確に気付くべきではないかなぁと思ったり. そうでない限りはやはり不特定多数エンドユーザー層向けのプレゼンテーション分野向けという域でしか無い気がする;-)

# もう一つの問題は(自前でフレームワークからを書けば良いのだけど)デザインとロジックの分離が不十分である所かも、プログラマが書いたダサいモックアップに後付けでデザイナーが作ったパーツをそのまま何も考えないでくっつければ綺麗なアプリケーションの出来上がり、といった作業分担が現行のFlashのモデルではかなりやり辛い構成になっているように思える.

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

少々TVを見ていて気になったネタ

「新卒で就職できない人は欠陥品」…近大理工学部ＨＰで講師暴言

だそうな、それに対するTVのコメンテーターの発言としては「人を欠陥品というとは何事だ、それにあたらない人も世の中に沢山いる」的な論調であったのだけど、正直どうなのだろうと思ってみたり.

というか実際この講師の書いている内容は「世間で口に出来ない事」であれ事実だろう、その就職できなかった人の実際はどうであれ、そのような人間を欠陥品と(明示的にでは無くとも潜在的にでも)思う人間は世の中に確実に(数10%のオーダーで)存在し、また社員の雇用は企業側にとっても大きなリスク (維持費込みで年額1000万近く、しかも後から使えないと判明しても易々とクビにできない、下手すりゃ一生面倒を見る羽目になる) を持つ現状では、そのようなネガティブファクターが影響し得る事を認識しておく事は間違いでは無い、他人が自分のありのままの価値を認めてくれるなどというのは社会の運営上都合の良いスローガンであって事実では無い.

ここで言われる「欠陥品」としてスタートした人間は少なくとも「会社に一生勤めつつがなく定年を迎える」モデルの社会(高度成長期の一般的な社会通念)ではやはり不利な立場にあり、またそれ故の色眼鏡で見られる事も多い事を認識しなければならない(そう見るべきでは無いなどと言ってもそう見る人間は常に存在する、ここで何かアクションを取るなら「べき論」を振りかざすのでは無く、それらの「現実」をどのように利用するかであろう)

上のコメンテーターの「それにあたらない人」はその中の「幸運な」一例であり大多数の人間は凡百で何の才能も見出さぬままその一生を終わる、厳しいがそれが現実だ、だとするならその限られた枠の中で利益(何が利益なのかは置いておいて)を最大化する為、一生安定した (現状難しくなっているが) サラリーマン生活を選択する事もまた間違いでは無い (それが「面白い」かどうかはともかく) そしてその路線において (努力が常に報われるとは限らない前提では) やはり新卒よりも就職浪人、フリーター経験者の方が遥かに社会的には逆境にある、逆にそうでなくあろうとするならそれを証明する為より多くの努力(必ずしも報われるとは限らない、むしろ報われる方が幸運な例だ)は「最低限」必要だろう.

どうにもこの類の「口に出せない事」と「実際の現実」の乖離を見る度に微妙な違和感を感じるのだよねぇ、、、目をそらすのは簡単だけど結局それは何も生み出さない (飲み屋で愚痴っているのと同じレベルだ) それを現実としてなおかつその中でアクションを模索する方が遥かに建設的だと思うのだが (まぁTVのコメントなんてものは事態の解決を意図するものでは無く適当に番組を流す上での相づちを打つに過ぎない為、上の論調は順当とも言えるけど(笑)

なおこれを書いている私も (厳密には微妙に異なるが) 社会的にはフリーターと殆ど同じような立場である事を併記しておく ;-)

また雨雨雨、ってゆーか何でこのタイミングで降りまくるかなぁorz

という事で陰々鬱々としながら過ごしております、微妙に自分の中の計画が狂うよ、、、まぁ本当にヤバくなったら仕方無いので電車乗りますけど(--#

電車もなぁ、散々嫌な思いしているから出来れば乗りたくない、ってゆーか全ては平均的な日本人の体格が小さいのが悪いのだと思います(笑、いやマジで、、、殆どのものが微妙に不便だし :-P

起きて仕事行こうと思ったら外は土砂降り、、、orz

何かこの所時間あるなぁなどと思っていたが、考えてみるとここ1週間程深夜に雨が降るケースが多かったように思う、大抵明け方には止んでいるのだが、例年冬ってこんなに雨降ったかしらん、などと思いながらもここ数年は毎年のように今年の天気はおかしいね、なーんて話をしている気もする、統計は取ってないので本当におかしくなっているのか、あるいは例外にあたる状況だからこそ記憶に残っており、それが大げさに想起されているのかは定かでは無いが(笑)

ともかく移動が妨げられるので雨は嫌い.

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

今更ながらにAjaxネタ、Webを巡回していたらこんなの↓見つけた.

Ajaxを利用した開発フレームワークBindows

ここの技術情報 - サンプルアプリケーション - アプリケーションランチャでメニューにあるBindowsTest.xmlとかJavaScript+DHTMLでよくここまでやるなぁといった所、またサンプルにあるインラインコンポーネントやらも結構面白いやね(OLEの初期構想などと言わないよーに(笑)

まぁサンプルでも動作がかなりもったりしている(※1)ので、これで本格的なアプリを組んだらどうなんだろう、とかサンプルにあるコードでの記述量を見る限りJavaやC#で書くのと余り変わりが無い、また記述言語がJavaScriptになってしまう辺りである程度以上の複雑なソフトの開発に向いているのか (少なくとも開発要員を集める際にJavaよりは人を選ばないと苦労しそう) といった疑問は色々あるけど(後部分的にレイアウトがズレる個所があったり) 面白いのは面白いやね.

まぁ配布の部分にどれだけメリットを見出せるかという所か、.netも少なくとも大規模配布が必要なクライアント向け(数千〜数万単位)ではVistaが一般化するまでは選択肢に入らないだろうし(業務スパンで考えると後5年程度は無理か?) ここ暫くのフレームワークバージョンのゴタゴタも考えるとそこに落ち着けるかも定かでは無いが.

ただこの手のは小規模の企業向けではアリかもしれんが、日本の事情での大規模クライアント向けでは結構嫌がられそうな予感(笑)

※1) もったりしていると言ってもスクリプトのNativeに対する速度比が1/100であるとして今の2GHzのマシンでは20MHz相当(※2) 少なくともX60000(無印)よりは速いやね、まぁ世にNativeのソフトが存在する限り常にそれとの比較に晒されるワケで評価としては常にその溝は埋まる事は無いというのは某氏の言だけど(確かにある意味真実ではある) 反面僕が去年仕事で作ったエクスプローラ風のアプリ程度ですら未だに日本人でメンテの人間が居ない(&どーしようもないので今度中国に出すのだそうなsigh) などの現状のコンピュータ業界のお寒い開発事情などを考えるとそういう流れもアリなのかなぁなどとも思ったり.

※2) 無論この計算には誤魔化しがある、GUI周りなど直接の操作に関わる部分を高速化すれば意外と(単純な処理に限定してではあるが)人間は1/100程度の遅さなど気にならないケースも多かったりする、無論内部の比較的単純な業務系に限定しての話、画像処理や数値演算などはまず無理だが :-P

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

Ajaxってのもかなり周辺事情によりグダグダなワケで、Google辺りがHTML拡張でのインタラクティブなキャンバス(※3)の仕様でも提唱してみないものかねぇなどと思ってみたり、今の状況なら結構アリだと思うけど. そもそもの設計が無理矢理なので余り美しくないし＞Ajax周りの実現手法

※3) まぁそれこそスクリプトの遅さが露呈してしまいかねない部分ではありますが;-)

停滞中

結局オブジェクトに色々な機能 (特に演算子のオーバーロードやインデクサ) を搭載すると「全てがオブジェクトである」事が自然だという実に面白みの無い結論に到達してしまい少々凹み気味 (ただ全てがObject派生である方が良いかについてはまだ結論は出ていない、cloneなどオブジェクトに対するオペレーションはObjectクラスに存在するのが自然だが、型無しスクリプトではObject派生である前に全てがスクリプト内エンティティであり代入可能であり、ある程度の制約条件を付けるなら異なる型の継承チェーンがObjectに集約されない方が良いのかもしれないといった思いもある為)

今更ながらに「型」とスコープについても再考中、これは自分が普段C++を使っているせいもあるが、やはりある程度以上の規模になると「型」がある方がプログラムとしての見通しが良い気がする、先に書いた仕事のスクリプトでも結局変数を書いている場所にそれが何を指しているかのコメントを書いてしまったし、やはりその方が分かり易い.

変数の自動宣言にも疑問はある、現状にPythonに近い宣言規則を使用しているが、グローバルであったかローカルであったかについて一瞬戸惑う部分も出てきている. 特に代入により自動宣言されてしまう為、不用意な代入に関するチェックが面倒. 色々懸念があった為、既に代入された変数における互換性の無い型代入をエラーとするよう変更してみたり (これはこれで部分的に不便なのだが、文字列を読み込んでそれを数値化して同じ変数に代入する事ができなくなる為)

先の日記に書いたファイナライザの明示的呼び出しにしても、オブジェクトの破棄チェーンがクラスの想定設計により2種発生する事を考えるとデストラクタとファイナライザを分けた方が良いのでは?(C++/CLIのように)という結論に行き着く.

そして結局の所 (C# + C++/CLI)/2といった言語仕様が理想形なのかといった話になってしまう、実に面白みに欠ける :-<

さて.

微妙に煮詰まっているのでGCと関数リファレンスのみを実装したコアに現行の雑用で使っているバージョンのリプレースなどもやっている (こちらは実務的な理由から) いや、真面目な話このレベルのプログラム(せいぜい1000行程度まで)だとクラス要らんケースも多いよなぁ、などとつらつら思いながら、いやまぁあっても良いのだけど、左程大きな要素にならないというか、何とも何とも.

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

公私共に煮詰まったおかげか、ここ10日程無性にゲームがやりたくなる(年に数回あるのだが)という事でラチェット&クランク1〜3(1に関しては2周) デビルメイクライ1,3(3はnormal/hard *2 で4周) を時間がある時はぶっ通しでやっている、よく時間あるなぁなどと思う事しきり.

余談だがDMC3は1周目より2周目以降の方が面白い. 微妙にバランスズレてる気が、、、

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

久しぶりの友人より会社辞めるかもといった連絡があり飲みに行く事に、人それぞれ思いはアリという所か.

色々思い巡らしながらも、ふと己を振り返り全ては今から繋がっているのだよね、などと自戒を込めて思ってみたり、それでも足掻かずに居られぬのが人間の性なのですが ;-)

まぁ行きたい所があれば行くも良し、現状から連なる道を探すも良し、なれど行きたい所を己の中ですり替えてしまわぬよう注意って所、何かを成すより何かについて語る方が楽になっちゃそこで終わりだから ;-)

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

現在の時間周期が夜12時起きの昼2時寝、仕事で表に出ねばならない予定まで8日、時間周期を1日25時間として1時間コンスタントに短縮できれば問題無いが、2時間以上ズレが発生するとマズい(今までの経験では25〜28時間が1日、摂取熱量が少ないとその影響もあって若干遅れ難くなる) という事で少々周期調整に入ります、特に日中の人に付き合えなくなるので容赦されたし＞業務連絡

久しぶりにLAPACKをいじる(といってもCLAPACK、Fortran77なんて忘れてます)、、、思えば大学以来かなぁ、相変わらず思いっきり使い難い(※1)、、、大学時代も結局複雑な計算は必要なかったのでnewmatとNumerical Recipie in Cから引っこ抜いてきたルーチンを使った記憶があるのだけど(笑)

※1) LAPACKは過去延々蓄積された有名な代数計算のライブラリの事、Fortran(現Verは77だったか)でかかれており他の言語で使うにはf2cで変換したルーチンを無理矢理使う、普通のプログラムのライフサイクルからすると化石のようなプログラムだが (ある意味恐ろしい事に) 未だ現役 (まぁ数値演算ってそれはそれでまた独特な世界だし、信頼性の点では最も高いのは確かだけど.

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

以前書いたプリミティブ(ベクトル・行列など)のインスタンスの参照型での問題とコピーの話、全ての左辺値への代入でオーバーロードされた代入演算子(C++とは違う意味、むしろコピー演算子に近い)を処理した所数倍遅くなってダメと書いたが、これを別の左辺値に既に所有されているものに限定するよう変更、ベクトルなどの演算では生成されるインスタンスの殆どが変数に代入されない一時オブジェクトであり、これを常に1回だけしか生成しないようにする事が出来、またメソッド呼び出しのコストも削減できる為速度的には (プログラムの書き方にも拠るが) メリットがあると思われる、試しに簡単な計算ではコピーを生成しない場合の1.5倍程度のコスト (以前は3倍、更に関数呼び出しが複雑になった場合のコストがリニアではなかった) になっていてこれなら結構納得できそうな気がする、、、見落としがなければ(爆、まぁ式の評価シーケンスが分岐するような要素が無い限り大丈夫な筈だけど.

ヨタ話

【こぼれ話】「死に至るハンバーガーはいかが？」＝米の“心臓発作"レストランに新メニュー

8000キロカロリーって(笑) ちなみに人間の最低限の体組織維持の為のカロリーが大体体重x20kcal程度だったと記憶しているのだけど(笑)

まぁでも昨今の神経質なまでの健康志向からすると、こういう楽しけりゃいーじゃんみたいな風潮はもっと増えて欲しいものです、まぁ心臓発作や肺ガンで死んでも自己責任でしょってカンジで、何か最近の流れって余裕無いですよ、みたいな.

ちなみにウチの祖父は今年99才、毎日酒を飲み塩の塊のようなしょっぱい食事を行い、しかもタバコまでガンガン吸うといった具合、耳は遠くなっているもののボケとかも無しで殺しても死にそうにありません、かというと (これは昔の知人の同僚の話) ガチガチの健康志向で生きてても30過ぎでガンで死んでしまう例もあるという事で、まぁこんなもの確率でしかありませんな ;-)

# まぁでも念の為書いておくと統計的は統計なワケで、細胞劣化の過程である確率でガン細胞に変化する可能性は万人にあるワケで、タバコを吸っていると大体統計的な「発生する人には発生する」(昔調べたので詳しい%は忘れた、半数発生率では無いが統計上意味のある値での確率) 値が15年程短縮されるのは事実なのですが(ちなみに私はタバコは吸いますけど ;-)

# でもね、あまり平均寿命延びちゃうとこれから起こるであろう国際的な資源確保競争やらもっと激化しちゃうんだよね、むしろ平均寿命が短い方が社会としての世代交代も活発になる (特に現行の日本の社会はかなり閉塞しているし) 通念的に良い事でも人類という種や社会あるいは地球にとって良いかはまた別問題なのですな、まぁとは言っても自分の身近な人間には長生きしてもらいたいというのがエゴなワケでありますけど(苦笑)

# でもそれを言い出すと人類もまた塵芥のようなモノなワケで、進化過程で人類への流れが作られてからたかだか10万年、直接の祖は数万年前、ただ記録として残る文明の記録は2000〜3000年前、文明の急激な発達はここ100年程度だったりするワケで、それに対し最初の多細胞生物が発生したのは6億年前その直後に捕食型の生物の発生が現在の流れを作ったとも言え、でもその前段階での単細胞生物の時期は数十億年かかっているワケであったり. あるいは時間そのものですら現在の宇宙での起源でしか無いワケで「かけがえのない地球」すらも量子論的には時間の起源が存在しない中で無数に発生し得るビッグバンのある初期組成(まぁこれ重要なんですけど)での1サンプルに過ぎぬワケであります(宇宙「外」については全く不明なのですが)仮に無限にその中で宇宙が発生し得るならそれもまた意味が無いワケであります、とゆーか宇宙が10次元の畳み込みだ(M理論では11次元か)なーんて言われても私みたいな凡俗には何がなんやら、みたいなカンジなのですorz

# そうして考えると数学者や物理学者ってロマンチストだなぁなんて思うワケであります、実社会で良く聞く「自分文系だから」なんて言い草はそういう意味では全く無意味ですな:-P

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

と、ここまで書いて思うんだが上の話に比べると余りにスケールの小さい話なのだけど良く話しているオブジェクトが全てのプログラム空間だって話は結局の所1つの理論・構造で全てを表記したいって言うアカデミックな欲望なんではないかな、と. まぁ上のは理論、プログラムはたかだか方法論、道具にそんなものを持ち出すのはナンセンスだって話も分かるけど(苦笑)

つーと目指すは関数型、オブジェクト型、手続き型などの方法論を内包する大統一プログラミング理論って所なのか?(何か宗教っぽくてイヤだな.

既に構造としての大統一はアセンブラで成されているって話はあるが、、、(ダメじゃん.
(意味論としてはLispに向かうのだとか言い出す輩が出てきそうだ(笑)

いやむしろ細分化によるドメイン特化(DSL)か、などというありきたりの結論に落ち着くもまた良し(えー
(じゃあやっぱマクロは必須か(そしてLisp的に(笑) そしてアセンブラからの実装ベースの流れを意味論ベースの流れで再構築すると(笑)

久しぶりに固有値周りのルーチンをいじろうとしたら勉強した筈の内容をかなり忘れている事に気付く、やりたい事は山程あるのに時間は足らないのは仕様ですか、そうですか.

会社にばっか出てると仕事だけにフォーカスしてる時間が殆ど(個人的には非常に散漫な性格なので煮詰まったらさっさと別の事(プログラムや勉強な事もあればゲームや買い物などという事もある)をやっているうちに煮詰まった所が頭の中で落ち着く)なんで実に効率が悪い、時間は有限だというのに実生活における無駄な要素は余りに多い、すごく面倒sigh.

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

本日の出来事、仕事のプログラムを自作言語で書いたら親方に嫌な顔をされた(多分).

まぁネタとして一度はやっておきたかったので後悔はしていない、うん(えー

だってぇーパーサ書くのにC/C++で書くのとか可変長の不定データ扱うの面倒だったしぃ(語尾上げ、みたいな.

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

普段書く安直な雑用スクリプトよりは少し長め(といっても数百行だが)のプログラムだったのだが、やはり汎用スクリプトでは1/2程度(C/C++比)といった所だろうか、余り効率がよろしくない. 削減される個所も可変長のデータやパターンマッチング程度に限定される為全体の書き方はやはり同じような手続き型になり代わり映えしない、イマイチ面白くないね;-)

クラス機能も同様で、結局ライブラリ粒度のコントロール程度になるし既存のライブラリを「使う」という方法でしか結局効率化は図れぬ.

もう少し何か欲しいんだよねぇ、例えば一括演算タイプの行列言語などでは演算規則の定義によっては↓

のようなXYZのメッシュを生成するのに

x=seqh(-4,4,0.05);
y=seqv(-4,4,0.05);
z=cos(x^2+y^2);

とだけ書けば良い、また100x100の乱数表の0列目が0.4以上で1列目が0.6以下の行を持つ行を0にする場合は

a=random(100);
a=(a[*,0] > 0.4 && a[*,1] < 0.6)? 0 : a;

のように記述する (ちなみに演算規則がパズルみたいになっているので式を一つ書くのに悩み、書いた後でもっと短く書けないか更に悩む(ダメじゃん.

何とか1/10は無理にしても1/4程度まで圧縮できぬものだろうか、、、(って何か目的を履き違えているな)

# 余談だが上の話行列ベースのデータであると結果の組み合わせが2自由度に制約されてしまう、更に安直にする為に全てのデータ構造がn次元のボクセルの組になっているというのはどうだろう、などと考えてみたり、確実にメモリが足らなくなるのでデータ型を式の結合で表し遅延評価とするのはどうか?(いや、まー絶対直感には反してると思うけど;-)

# 更に余談だが書いたプログラムがある程度複雑なデータ構造を扱うプログラムだった為か、部分的にはスクリプト的に型が無い方が楽な個所もあるのだが反面型制約が欲しい部分もある、結構悩ましいね.

# あるいはExcelのモデルを砕いて全ての文が同時に評価され、未定義の変数が発生した時点でその文を停止、別の文を評価して未定義状態が無くなるまで反復するとか、上手く行けば昔のSFとかのコンピュータのイメージのようにコンピュータにデータのみを入れれば勝手に結論を出してくれるようなコンピュータが実現できるかもしれない、、、いやまぁそのままやると連立方程式でアルゴリズムが停止してしまうのだけど(やっぱダメじゃん.

<下らぬ話につき削除>

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

Sun、JavaをGPLでオープンソース化だそうな、SlashDotにも記事が、うーむ、、、GPLねぇ、時にGPLがプログラム利益(not金銭的な意味)の分配の強要に見えてならないのだけど、特に今回のは政治的意味合いが強そうな気がする.

プロプリエタリだけでは「文化」は成立しないのだけど、GPLはGPLで停滞と放棄を意味するような気がしてならないのは何故だろう、、、

# 昔のコンピュータコミュニティの時代はGPLいーんじゃない、なんて思ってたのだけど、昨今色々事情が変わっているので最近はGPLに微妙にネガティブ、何か違うんだよなぁ:-<

# 資本主義vs社会主義的対比では社会主義の欠点は人間が本質的に腐るものだという前提を見失っている事 (いやまぁ日本は社会主義だけど(笑)) にあるのだけど、この場合そういった階層構造は成立しない、でも何故かは分からないのだけど何かが腐ってきているような気がしてならない.

何か会社の人に借りた本とか、友人の近況やら周囲のグダグダ話など聞いているとプログラム(というかモノ作り)ってホント多人数で作るものでは無いなぁなんて思ったりします、例えるなら編み物と同じような作業な訳でしかもその中の糸の1本でも狂うと全体がダメになるという、基本はもう2人以上で作るものでは無いって事です.

しかしそれでは大量生産できないワケで、織物が家内製手工業から業性手工業に移ったように更なる量産が必要なワケであります、そう捉えるとミドルウェアやらオープンソースやらを組み合わせてスクリプトでツナギ程度のプログラムを書き、それを以ってシステムだと称するのはある種の工業化と捉えれるかもしれません. 問題はソフトウェアの場合現状のプラットフォームでは工業化による冗長化がもろにクオリティに影響してしまう所で、これはPCというプラットフォームがそのように作られている為如何ともし難い部分はありますが

そう捉えるならもう企業におけるシステム構築は「プログラムを書かない事」こそが真理でしょうな(いやマジで) その中のエンジニアというのはベルトコンベアのパーツと同程度の価値しか無いワケで、労働条件の向上などは見込めないワケですが(笑) 無論そういう状況での市場の差別化は製品クオリティは何処もトントンになりますからよりサービス的になるワケです、ただこれはコンシューマモデルなワケで、コンピュータ業界の事業の大半を占めるBtoBではより囲い込み的になりパイの流動化は限定されるワケでありますが.

まぁかつて前の会社の友人に冗談で 「まぁでも10年後にはプログラムなんて書くものじゃないとか言ってるかもね」 なんて話をしていましたが、あながち冗談では無いかもしれませんねぇ、すこし文脈が違いますし. 無論自分自身の為には書くワケですけどね、なーんてね(笑) :-P

# 根底にあるのはやはり人間の業というヤツですなぁ、何とも哀れむべし、是非我々愚かな衆生を救う為に弥勒菩薩には予定を56億年程前倒しして頂きたい所存(って最後は神頼みかよってなカンジで :-P

# まぁ冗談はさておき重要なのは意思なんでしょうな、意思だけが人間というモノを人間と称しても御幣無きものたらしめるワケで、無論己を含めて、ね ;-)
よって時に猛省すべし＞自分

# 上に書いた内容は幾分厭世的なニュアンスを含んでいるが、一方では開発者が流出し、コアも中国の外注先しか把握していないような製品を売っていた会社で海外の別会社の製品を買い付け(独占契約ではない)てクライアントの所に持っていった所「おたくでもそういう製品作ってるんでしょ、なんで他所の製品持ってきてるの? そんな状態の会社に安心して任せられる訳ないじゃん」と見事に(案件含め)突っ返された話もあったんだそうな(笑)

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

COM呼び出しのサポートルーチンは結局自前で書く事に、_bstr_tと_variant_t相当の実装だったのだが寿命管理など思いの外面倒だった、んでそれを組み込んで確認した所ではIDispatchやIEnumratorなどの処理も正常に動いている、パーサに引数付きプロパティ用の規則を付けたらshift/reduceコンフリクトが1つ増えた、y.outputで確認する限り問題ないがやはり少々気持ち悪いやね.

まぁ一応軽く調べた所ではメモリやインターフェイスのリークも発生していないので想定通りに動いている模様、これに加え左辺値代入のHookとインデクサ、property機能を追加したので周辺コードがかなりややこしくなった、propertyは便利なんだけど記述が少々面倒だし省いた方が良のかなーなど考え中、Pythonのアトリビュートのようなものも追加してみたがこれは余りに大ざっぱ過ぎるのでオミット.

後は現行オブジェクト扱いにしていない組み込みオブジェクト(文字列,配列,ハッシュ,正規表現)辺りをどうするべきかという所、簡便さを考えると全部クラスにしてしまうのも手(インタプリタ構造も単純になるし)だが少々迷う所.

TANEさんのHPが復活したらしい、というか何でも契約しているISPが夜逃げしたとか、いや、、、そうそうある話では無いと思うのですが(^^;;

とりあえず復活おめでとうございますm(_ _)m

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

コアを改造してメソッドをクラスに属する形で書き換えてみた、またインスタンス変数は全てVirtualを基本としたので実質は1つのインスタンススコープのみとした事で継承時の生成コストも軽減、結果としては継承無しのオブジェクトのインスタンス生成速度でも4倍程度向上、また組み込みクラスとした場合の速度は10倍以上向上した(以前はスクリプト定義のクラスより1割程度しか向上しなかった)

なお継承があっても実質Objectが1階層なのでsuperの参照はクラスに属するpseudo objectを介すようにし、スーパークラスへディスパッチする仕様に変更. メソッドが非結合になる件は関数呼び出し以外の左辺値取得での結合メソッドを暗黙に生成する事で以前と同じ挙動とした.

、、、そしてインタプリタソースの関数呼び出しと左辺値処理周りが恐ろしく複雑なコードになったorz
そして更にこれにCOM呼び出しも編みこまねばならないorz

しかし実用性(オブジェクトが無くても死なないがマトリクスはともかくベクトルが無いと死んでしまうので)を考慮するとこちらの方が良いだろうという所. 何とか年末までには全ての仕様とコアを組み上げたいな.

# VC6->VC7(VC2003Tookit+PSDK)でコンパイルしてみた所10〜15%程度速くなった、やはり最適化を考えるとこちらの方が良いかもしれない、ただ現状VS2003は入れてないのでCOM周りのサポートクラスが無くライブラリの一部のコンパイルが通らない、関連付けがいじられるのを覚悟してインストールするか、あるいは使っている所はVariantの変換だけなので自前で書く方がストレス少ないかもしれない.

先日書いたベクトルやら行列を作った時に処理が重い話、左辺値代入のコピーによるインスタンス生成回数の問題はどうにもならないが、それ以外のパフォーマンスについては結局の所現状の方式でのインスタンス生成の効率に問題がある、インスタンスメソッドがインスタンスの生成ごとに全てnewされてそのインスタンスに格納されている為、この部分をnativeに置き換えてもそれ程効率は上がらない. このような方式を採用している理由は全てのメソッドを指すインスタンス変数があらゆるコンテキストにおいてPythonで言う所の結合メソッド (thisとメソッド関数がペアになったもの、あるいはBorland系C++では__closure) として機能させる為にある.

これをメソッドは実際にはクラスに属するものとし、更にオブジェクトのインスタンス変数はコンテキストに拠らず全てVirtualとするとオブジェクトの生成コストは大幅に軽減できる&Native実装でクラスを実装した場合の速度向上が見込める、問題はメソッドがthisを含まない(関数コンテキストでは現在のthisを参照する)事であり、またfoo=a.methodのような形での代入が実現できない事にある.

まぁメソッドを関数オブジェクトのように参照するのは実際のプログラムでは稀なケースである為 thisにメソッドを明示的にbindする構文を用意するのも手かもしれない、foo=bound( a, a.method )のように (あるいはクロージャを使っても良いが)、、、実に美しくないがorz

、、、Pythonのように全てのメソッド、メンバ参照にselfを付加する方式なら簡単に速度と両立させて実装できるのだが、流石に本末転倒 (そういう書き方を許容できるなら最初からPythonを使えば良いので) どうしたものか.

個人的にベクトル&行列 > オブジェクト指向全般なのだが、それでもメソッドが非結合なのはかなりストレスが溜まる (ソースを見た瞬間に血圧が上がる、いやC++もJavaもC#もそうなんだけど) ので困った所、何とか両立させたいのだが、、、orz

(11/7夜追記)

本当は事務所に出てやらねばならない事があったのだけど、朝から食中りで死んでいて結局何も出来ず、申し訳ない＞関係各位

下に書いたスクリプトでの演算子のオーバーロードの話、試しにoperator=(左辺値への代入)をオーバーロードできる構成で仮組みしてみたが、、、やっぱ遅い. 代入の度にコピーされているので単純なコードでも3倍程度、多分本格的な計算をすると1桁違うんじゃなかろうかorz

演算子のオーバーロードもそんなに早い処理では無い為、これでベクトルや行列を実装しても実用速度で動くのは1次元的な広がりのデータまでで2次元以上は無理 (まぁ3次元以上の広がりのデータになるとC/C++でもきついのだが) せめて2次元処理まではやりたかったのだが、これでは簡単な実験データ(学部レベル程度)の集計(1万件程度まで)や数学のサンプル問題を解く程度で、幾何的な反復を伴うシミュレーションには使えないorz orz

余談だが同じ計算をやらせたら普段遅いなぁと思っている自前のmatlabモドキ (演算展開はAPLみたいな一括型) の行列処理処理系 (総じて基本演算は上の汎用型より5倍程度遅い、データは複素数の可変長行列を基本としており、全て実体コピーが基本) の方が単純参照で5倍、代入コピーを加味するとで10倍以上早かったのはかなり泣けるものがある.

意外と面白かったのは某言語(インタプリタ)のベクトル演算でも同程度の速度(参照のみの場合の比較)になってしまっていた所、逆にバイトコードにコンパイルするタイプの(上の言語と対比される)言語では余り速度低下が見られず、これなら簡易シミュレーションでもある程度Nativeと比較して (インタプリタである事を加味した場合) ダイレクトなスケール感があるなぁといった所.

実に悩ましい、電卓的な用途を否定するつもりは無いが、仕掛けが大掛かり過ぎる気もする、やはり (言語としての直交性をある程度欠いても) ベクトル型程度は組み込みで持っておいた方が良いかもしれない(以前の手続き言語のバージョンでは配列に対する一括演算をサポートしていたのである程度のベクトル計算が代用出来た、パフォーマンス的にも1桁違うし、、、:-<)

下の参照と演算子のオーバーロードのアンバランスの話、データをプリミティブとみなす使い方(C++ではそんなカンジ)では無くデータの計算の為のプレースホルダとして捉えるならアリなのかもという気がしてきた(やっぱ前者と後者では格段に利便性は違うけど:-<

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

相変わらずクラスベースの方も調整中、果たして正しいかどうかはともかく完成させる事には意義がある (ダメだといって投げ出していては細かい所が見えないままになってしまうので実にならない為)

演算子のオーバーロードについて悩む、実装するのは簡単だが個人的私見として参照型のデータ構造での言語に演算子のオーバーロードをサポートさせるのは疑問がある.

class Point{
    var _p[2];

    function Point(x, y){
        _p[0] = x;
        _p[1] = y;
    }

    function operator+(a, b){
        extern Point;   //これ、不便だな...というか間違いの元になりがち:-<
        return Point( a._p[0]+b._p[0], a._p[1]+b._p[1] );
    }

    function toStr(){
        return sprintf("(%f, %f)", _p[0],_p[1]);
    }
}

a = Point(1,2);
b = Point(2,2);
c = a+b;

print( a.toStr() );
print( b.toStr() );
print( c.toStr() );

-----------------------
[実行結果]
(1.000000, 2.000000)
(2.000000, 2.000000)
(3.000000, 4.000000)

、、、と、ここまでは良いのだが


a = Point(1,2);
b = a;  //aを保存したつもり
a._p[0]=10;
print( a.toStr() );
print( b.toStr() );

-----------------------
[実行結果]
(10.000000, 2.000000)
(10.000000, 2.000000)

となり破壊的操作では全ての参照先が書き換わってしまう.

※コンストラクタ及びクラス名の参照がまだこなれていないのはとりあえず据え置き(^^;;

無論aを保存する個所で b = a.clone()と書かないプログラマが悪いのだというのも一理ある、しかし演算子のオーバーロードは複合的なデータ構造がプリミティブかつある程度複雑な演算を要する場合に使うべきものである事 (ベクトル、行列など) と考えると別の事に思考を割いている場合にこのようなオペレーションは記述における意味論として適切では無い(※1) 破壊的操作を全て禁止するアプローチも考え得るが、ベクトルや行列での要素操作を考慮すると余り実用的では無い(というか多分論外だ:-<

、、、思い切って演算子のオーバーロードは切り捨てるか、値型もしくは代入での操作に対して常にコピーを生成できるようなオーバーロード(かなりコストが大きい)を提供すべきであるか(途中演算・関数呼び出しなどが全て非破壊的である事が保証されるならこれでも問題無い)、、、実に悩ましい.

※1) 値型のコントロールが細かく出来るC++の演算子のオーバーロードは非常に重宝しているのだが、これにしても意味論としてプリミティブ以上のものへのオペレーションをオーバーロードすべきでは無いと考えている、以前コードは短い方が良いと書いた事と矛盾するようであるが、あくまで意味論を保った上での話なので、個人的にはC++の標準ストリームでのオーバーロードでさえも不適切な乱用例に見える (ので実際ストリームは使っていない) :-P

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

GC言語において本来ファイナライザは期待すべき内容では無いが、一応言語仕様としてスクリプト終了時に存在するオブジェクトについては全てファイナライザサポートを保証する事にしてみたので、ついでにGC以外でもオブジェクトを明示的にファイナライズする構文など作成、以下の通り

fp=new File();
fp.open("foo.txt", "r", "utf8");
〜ファイルに対する操作〜
fp.close();

delete fp;  <-明示的ファイナライズ、、、というかまんまやね(笑)
fp.eof();   <-以降オブジェクトへのアクセスはエラーとなる

これに伴いファイナライザ内で「復活」したオブジェクトはその後も(再度ファイナライズされないだけで)有効としていた仕様を、ファイナライズされたオブジェクトへのメンバアクセスは全て実行時エラー(例外)とするよう変更、まぁどちらが良いかは分からないが、明示的にリソースを含むオブジェクトをファイナライズしておく事で他の部分で不用意に参照してしまっている場合にいちいちチェックコードを書かなくてもロジックミスが検出できるやもしれぬという所

(一部の知人向け補足) なお例外・エラーによる停止としたのは本来リソースの破棄後のアクセスは実行時エラーでは無くロジックミスによると想定される為、個人的にはロジックエラーについて例外を使うのは賛成だが、実行時例外で大規模ロールバックが不要な局面を例外で扱うのは余り好きでは無いというスタンスは変わらない.

微妙に色々模索中、まずは安直に関数と変数のネームスペースを分けたものに関数参照をデータとするものなんぞ作ってみる、結局コールバックを渡すだけなら(関数を別途定義して良いなら)こういうアプローチもアリかもしれんが、これについて書いても面白みは無いので省略(※1)

更に別なアプローチとして、結局クラスベースを扱うと厳密にクラス設計をしなければならないワケで、プロトタイプベースの可能性も模索してみる、とはいっても別に大した機構は必要無く、現状構造体をサポートして関数をfirst class objectとしているコアにクロージャを付けただけのシロモノ.

function iter(sa){
    idx=0;
    return closure(){ (idx < len(sa))? sa[idx++] : null; };
}

p=iter([1,2,3,5]);
while(n=p())    print(n);

---------------
オブジェクト指向みたいな事をするとこんな具合

function Foo(n){
    this=struct(val=n, method);
    method=closure(){
        print("Foo called: ", this.val);
    };
    return this;
}

obj=Foo(33);
obj.method();
bar=obj.method;
bar();

上のstructがハッシュ(:=連想配列)を作る構文になっている、任意プロトタイプを指定する場合はここを任意のオブジェクト生成関数に代える事で実現可能.

closureとfunctionを分けているのはクロージャの実装が生成環境に対する「参照」(C#の匿名メソッドと同様の結合方式) としており副作用が発生し得る為、不用意な変数変更が伝播しないようスコープの結合を明示的に指定させる意図がある(functionはグローバルスコープとローカルスコープしか参照しない宣言) が少々一貫性に欠ける気もする (これをクロージャと呼ぶかは意見の分かれる所だとは思うけど;-)

ある規模以上の設計では静的なクラスベースの方が過ちは起き難いが、安直に書くスクリプトではプロトタイプベースの方が良いような気はしないでもない(実際自分のスクリプトの用途は非定型のデータプロセッサとしての使用と計算系のチェック用の電卓っぽい使用が殆どで、スクリプトでちゃんとしたアプリを作る事は無いワケだし)

しかし以前クロージャをサポートするとブロックスコープのオーバーヘッドが気になると書いた(従来は必要になった時点で始めてスコープを生成)が、やはりパフォーマンス的には2/3程度まで低下している、複雑なブロックが絡む個所ではよりオーバーヘッドが増える事も予想される辺り少々頭が痛い.

まぁ非常に安直にC++のクラスベースで内部構造を管理しているのに問題があるのも事実だが(苦笑、、、実行時間の殆どはnewのオーバーヘッドの影響が大きく、MSのJScriptと比較しても50%程度の速度しか出ていない、100万個位オブジェクトを生成すると結構速度が気になる:-<

、、、逆にメリットは思いつきでの変更が極めて容易な事にあるのだが(今回のクロージャ実装は1時間程度で終わったし、そういった意味ではC++は(文法腐っているけど)非常に有り難い;-)

# しかし単なるハッシュと等価と捉えるとファイナライザを特定のキーに結びつけるのは少々抵抗がある、しかしDLL呼び出しなどNativeリソースとの結合を考慮するとファイナライザのサポートが無いとかなり不安なので頭が痛い、また構文は少ない方がシンプルで良いが上のようなオブジェクトの生成が直感的かも疑問が残る(これはクラスベースに囚われ過ぎかもしれないが、、、:-<

※1) しかし本当の所を言うとどちらが良いかは分からない、言語の記述は単純であって良く、プログラマの自己満足になるような複雑な機能は必要ないという考え方もある、その方が開発に注力できるという話になる(そういった意味ではCとC++は両極端かもしれない (C++のラーニングコストは最悪だし) また最近のJavaの言語仕様のC#後追いの拡張は敢えて割り切ったシンプルなものを作ったにも関わらず、デザインセンスとして正しいのかどうかは少々疑問が残る気もしないでもない (プログラマはとかく完全なものを作りたがるきらいがあるように思うが、その結果はMSのOfficeのようなターゲット層の大多数が使わない機能まで網羅した醜悪な塊になりがちな気がする(※2)

※2) プログラマにとってプログラム言語というのは思考そのものである為、時に言語マニアはより「クールに」コードを実現する為に90%の人間が不要とする機能(あるいは構文糖)を求めがちという所はあるように思う、まぁこれは言語に限らずあらゆるソフト開発に言える部分もあるが、聞こえてくる意見というのは常に大多数の意見を反映しているとは限らず、むしろ限定的な「声の大きい」ユーザーの意見のみが目立っている「だけ」の可能性も考慮する必要がある、物事に満足している人間はそれを「肯定」するのでは無く単に「何も言わない」、常に母集合との対比を考えねば声の大きいユーザーの機能を際限なく取り入れた挙句散漫な物が仕上がってしまう. 以前どこかでパッケージソフトを開発する時にまず80%のニーズを満たす事を考え次にそれを100%に近づけるのだといった論説があったが、個人的には80%を満たせば良く、残り20%を満たす必要は無いと思う、その20%については別の(その用途での80%を満たす)ソフトを作る方が正解なのではという気がする. 特に日本のソフトウェア業界はこの「声が大きいユーザー」への過剰サービスが逆にグダグダな結果になる傾向が強いように思う. あるいは最近のゲームの続編指向なんかも近いかもしれない(※3)

※3) とは言えJavaの拡張戦略云々に限って言えばむしろマーケティング的戦略の意図があるやもしれぬ、〇×比較表 (これは実社会の実に馬鹿げた習慣だが分かり易いので多用される) で並べた時にC#に劣っている個所があれば(例え現状.NETが鳴かず飛ばずという状態であっても) 中長期的なリスクの懸念を下げる為の戦略とも受け取れるかもしれない、というかエンジニアセンスというよりはどちらかというとそういう政治的な匂いがあるような印象が個人的にはある :-P