C#でお遊びがてらちょっとした画像Viewerを作っていたのだが、ポコポコ表示 (注: 表示されるのは1枚のみ) していてふと使用メモリを見ると50MBばかり食っている、その後ファイルを大量に入れ替えると大体80MB近傍でGCが走って25MB程度に落ち着く(以下画像を表示し続ける限り繰り返し) ちなみに.NET2.0で作成したアプリの初期消費は20MB程度.

参考までに書くとスタックサイズなどをいじらない場合、初期状態でのメモリ使用量はVC(+場合によってはMFC)のアプリが大体2MB程度、VB6で作るアプリが5MB程度、BCBで作ったモノは大体3〜4MB程度、なおおまけ程度に書くとJDK5で作ったSwingアプリが18MB程度となる.

現在の開発環境は1GB乗せているのでGCの走るタイミングも考慮して複数プロセスを立ち上げない限りは100MB程度は食っても左程問題では無い(IEも多い時では30〜40MB程度1プロセスで食う)とも言えるが、世間には128MBとか256MBとかのマシンもある(※1)ので結構難儀な話、これだと.NETアプリを動かす場合の大体の想定は512MB以上って所だろうか(※2)

、、、やっぱりちと引っかかるなぁ(--;;
C#自体言語的には完璧とはとても呼べるようなものでは無いが、Javaよりは思想的にもC++寄りだし、何気に結構扱い易い、まぁ安直な今の時代のBASICってカンジで (C++と比較して、細かい処理をやらなければ) 非常に楽 (特にOLE周りの処理) なのだが、やはり定着まではまだ時間を要するかもなぁ、んー(※4)

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

※1) なおうちの両親のマシンがXP+256MBなのだが、単体では比較的動くもののアンチウィルスソフト(常にメモリに常駐する)を入れると途端にダメダメに、余りにも酷いので結局アンチウィルスソフトを5種類程買ってきてその中でシステム負荷などでベストと呼べるものを選択して何とかそれなりに動くようにしたが、、、:-<(※3)

※2) 自分の体感だが、自分は常駐型のアンチウィルスソフトなどメモリを食うものは一切入れていない (この辺を入れるとやたら重くなる&場合によっては不安定になる) ので実際はもう少し必要かもしれない、ちなみにFireWallでポートは全部塞ぎ、外部からのファイルは必ずスキャンする、そしてJavaScriptとActiveXは基本Off(Flashなども含め)、信頼できるサイトのみOnにするという具合、意外とこれだけでも変な物は入ってこないもの (それでも怪しい時は自作モニタでプロセスごとの通信ポートの使用状況や通信内容、レジストリなど幾つかのAPI呼び出しをチェックするけど、今の所そこまで変な事になった試しは無い)

※3) ちなみにKasperskyにしました、Nortonは付属のアプリがダメダメ、シャットダウン時にクラッシュしまくるのは(メモリが押している状況でのシステムのサービスの終了時Timeoutの影響もあるかもしれないけど)そも論外のような、、、ちなみに買った後インストールソフトの詳細などネットの情報からパッケージも開けずに破棄したものもありましたが(笑)

※4) 正確には開発効率は大体BCBと似たようなもの、GCがある分自前のクラスのマネジメントはBCBよりも.NETに軍配が上がる反面APIの呼び出しの柔軟さや細かい制御はBCBの方が良いカンジ、最適化の都合上自分的には計算エンジンなどはVC++でDLL化してしまうケースが多いが、これに関しても.NETからDLL呼び出しやC++/CLRでツナギを作るよりもBCBの方が少し楽、それでもクラス互換性が無いのでインターフェイスをCのみに限定するのが面倒極まりないが、、、まぁBCBの方は色々先行きが不安だしココ暫くの製品の完成度もアレだし、今まではWin32自体のサポートだけあれば何でも良かったのが少々WinのAPI自体のターニングポイントにまたがっている事もあってその辺の事情がちと辛い、反面.NETも描画のベースになっているGDI+のパフォーマンスはかなりアレ、かと言ってXP以降でしかサポートされないWPFを使うのもまだ抵抗がある(世間一般の要件としてのサポートサイクルとはズレがあるし) :-<

※5) まぁVCLは全てDelphiで書かれているので、BCBでは既存のコンポーネントの拡張を考えるとダメダメですが、、、Pascalって嫌いなんだよね ;-)

昨日今日と少々思う所がありC#をいじっているのだが、やはりprintf/sprintfが無いのは寂しいなぁ(※1) という事で作ってみた.

Webページに貼り付けるには少々大きいのでDLはココ

内容はprintfの書式指定をString.Formatの書式に変換して実行するものなので幾つか使えない書式 (ソースコードのコメント参照) もあるが、一通り基本的な使い方は可能、DLLを呼んでいるワケでも無くまた全てsafeコードのみなので扱いも軽いかと思う.

具体的な使い方はこんな↓カンジ

using System;
using Printf;

class App{
    static void Main(string[] args){
        std.printf("val : %04x\n", 1582);
        string s = std.sprintf("ch : %c [code=%02x]", 0x42, 0x42);
    }
}

型変換は書式指定に従ってConvert.To〜で適当に変換するので割と適当な引数を与えても大丈夫.

別段大したものでも無いので上のprintfコードの著作権はいつものごとく全面放棄、(いるかどうか知らんけど) 商用でも何でも好きなようにしてというカンジ ;-) なおクラス名のstdはタイプ量が少なくソースコード上でも目立たないそれっぽい識別子というだけなので気に食わなければ適当に書き換えの事、またprintfごときにクラス名が付く事すら気に食わない場合は (多少オーバーヘッドがあるけど) 適当なdelegateを作って突っ込んでおくのも手かと思います (static importみたいな機構があればこんな馬鹿な事しなくて済むのだけど)

、、、しかしJavaもC#もそうだけど、粒度の荒いアプリ全体の構造を扱うのは楽だけど、粒度の細かい処理をやるとどうにもC/C++よりもタイプ量が増えるのがちと辛い、画像処理とかも基盤さえ作ってしまえば (実に微妙な話だが) C/C++の方がタイピング自体は楽な気がする(※2).

※1) 頻繁に.NETを使っているなら.NET Frameworkの書式指定は確かに柔軟で良く考えられていて良いのだが、他にも色々使っているとついつい瞬間には出てこなかったりして書いていてストレスが溜まるワケです(笑) まぁJavaにもprintfが乗った事だしという事で ;-)

※2) 何せ私ゃブラインドタッチができないのでタイプ量が多いというのは深刻な問題なワケであります(えー、 というか意味粒度として1行で済む所を2行以上書くのは万死もしくはトルチョック制裁に値する行為だと思うのですよね、ええ(ぉ

# 何ともC#もいじってて良い言語だなぁと思うワケであります、実行パフォーマンスの問題などもVB6と同程度の水準で良いモノなら左程問題ないし、配布やサポートOSの状況が論外 (バージョンはJREよりも少ないけど、MSのアップデートに依存しているので単体のインストールだけで完了しない事もあるのはある意味JREより悲惨) なので現状自分の分野ではC/C++ > VB6 > .NET > Javaとなってしまう、というか万能さを追い求めると相変わらずC/C++しか選択肢が無い状況、世の情報を見るとJavaすら過去のモノで、やれLLだと盛り上がっていたりするのに相変わらずC/C++位しか安定した選択肢が無い状況はいい加減どうにかして欲しいのですがねぇ、、、sigh.

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

少々前の話にはなるがPaul Grahamネタ 「マイクロソフトは死んだ」

まぁ如何にもUnix系ユーザー的な意見ではある (対比としてJoel Spolskyの視点などはWindowsのパッケージ屋的で2者の文章を対比すると面白い) もののある部分MSの2000以降の方針転換と.NET周辺に自分が感じていた「何やっているんだ、ありゃ」という思いを解説してくれている気がする.

ただUnix系のユーザーが思うほどユーザーはまだ自立していない、Windowsは相変わらずメインストリームであり、パソコン自体に興味の無い人の最も主要なOSでもある、Web2.0を巻き込むAPI戦争では OperaやFireFoxが幾ら頑張ってもそれだけではプラットフォームのパフォーマンスを上げるには至らない、Googleがown browserでも出せばまた話は違うかもしれないが (ただ僕自身はGoogleについても正直疑念を持って見ている)

ただ開発者は確かにWindowsプラットフォームを離れており、Windowsのここ暫くのアップデートの話題といえばセキュリティに絡むものばかり、WindowsのUpdateを行う必要があるのは殆どMS製のアプリを入れる場合のみという膠着状態にあり、レガシー化したWinAPIを刷新しようとした.NETは開発者を惹きつける程の魅力は発揮できておらず、確かにMSは窮地にあるように思える (直ぐ倒産するとかそういう話では無い、昔程の影響力を維持できないという話)

しかしだからこそ怖いとも言える、その結果があの(酷い出来の)VistaであったりOfficeのインターフェイスの(過去を無視した)大幅刷新であったりするように、ここ暫くのMSのユーザビリティへの暴走は実に著しい、そしてMeの時はまだ2000があったのだが、Vistaの前はもう数年前に出た(今までのMSのリリーススケジュールからすると賞味期限切れの) OSしか無い、そしてそれにも関わらずMSはどうもかなり「本気」であるように思えるのだ、、、

さて、コンピュータは何処に向かうのやら、、、「メディア」としてのコンピュータは携帯などで良いと思うのだけど、「創造の為の道具」(但しコンピュータ自体が目的の創造を除く) としてのコンピュータはまだデスクトップでないと役不足な気がするので、ここで妙に倒れられては面白く無いのだが(笑)

殆ど私信モード、Cと同じコントロール粒度で構造体メンバ参照演算子'->'を廃したいというような話を友達がしていたので少々それっぽい文法を考えてみた、こんな具合なら一貫性を保てるんじゃなかろうかというカンジで↓ (注) 完全にネタ会話での妄想言語の話なのでこういう言語があるという事ではありません;-)

Foo *a;
Foo b;

&a = &b;    //&はアドレス参照、但しポインタ型については左辺値としても許可
//&b = &a;  //bはポインタ型として宣言されていない為エラー
a.member;
b.member;

配列の場合は

int[] *a;   //heapに確保
int[3] b;   //stackに確保
もしくは
int*[] a = new int[256];    //heap
int[] b = int[256];         //stack

&a = &b;

多値の場合は
[int, MyData] foo(){
    MyData b;
    return [ 10, b ]
}

int[] *foo( int[3] b, int []*a ){
    return new int[256];
}

int[3] foo( int[3] b, int [16]*a ){
    return b;
}

ポインタ指定を宣言部のみでそれ以降は値型と同じに扱える、ただアドレス代入の場合は左辺値に&変数の形式で可能という具合.

難点は解放しなきゃならないデータと実体の区別がつき辛くなる事、一応型情報があるのでdeleteはコンパイルエラーにできるけど、解放忘れは一段と深刻になりそうな予感(^^;

後はBCCにはあるけど (boost::bindは面倒&実装が汚いので好きじゃない) 暗黙のthisポインタ所有する関数ポインタを取得して

void foo(void *) = closure(a.foo);

※正確に言うとこれはクロージャでは無いとは言わない事、bccの名前と合わせているだけなので;-)
(正確にはPythonのbound methodみたいなモノやね)

としてthisをバインドした関数ポインタを抽出する機能とか (更にそれが通常の関数ポインタと同等に使える事)

メモリアロケーションドメインを設定するとか

Foo* foo(){
    AllocDomain m1;         //メモリアロケーションドメイン、この変数の有効スコープで削除される
    Foo *a = new(m1)Foo;
    return (@__global)&a;   //Heap管理を__globalドメインに変換して外部に返す
}

AllocDomain m2;
Foo *b = (@m2)foo();        //返却値をm2ドメインで所有
Derived *foo = (Derived*@m2)getData(); //キャストを伴う場合

、、、やっぱキモい？(笑)

# 型システムがあるなら OCamlみたいな多相Variantとかも欲しいけどCレベルの粒度で管理するコンパイラ言語 (プリミティブな部分のオーバーヘッドは極力減らす方向、想定用途がモノリシックなパッケージでぶっちゃけsaiレベルのアプリを素で書けるレベルのポテンシャルが無ければならない) としてはちと辛いかもなぁ↓こういうヤツです.
typedef (int | null) int?; とか
typedef (SingleFile | Directory) File; とかいうカンジ.

# まぁSimple is Best, あまり上のようにゴテゴテ付けずCを少しだけ扱い易く (但しC++程複雑では無く) しただけの仕様でメモリ管理周りは据え置きの方が良いかもしれない(笑)

以下の演算の結果について

-10 % 3 = ?
-10 \ 3 = ?

※但し%は剰余、\は整数除算演算子とする(※1)

同様の演算を整数型で実行した場合、結果はVC++bcc,とC#, Javaではそれぞれ[-1,-3]となる (正確にはC89では上記結果は処理系依存であり、上記の結果はC99からの定義になる)

これに対し幾つかのスクリプトの実行結果についてはこちらにある通り. 整数除算と剰余が相補的 ((a\b)*b + (a%b) == a) とならないものはそもそも演算体系として論外なので置いといて(ぉ 多くのスクリプトでは[2,-4]を返すものが多いようだ.

それぞれ解が[-1,-3], [2,-4]となる演算体系について(x % 1)をプロットすると以下のようになる.

[-1,-3]となる系...(1)

[2,-4]となる系...(2)

上記のように(1)が原点に対し対称になるのに対し(2)では剰余が数直線状で連続になり、 パラメータxについて演算結果も連続である事が期待できる.

どうもこの結果を見るに[2,-4]の方が自然な気がする、、、本当に？

上記は実数系での演算であるが、より一般化した複素数の演算を考えると乗除算(not整数)は複素空間上の原点を中心とした回転・スケーリングと考えられ、実数での乗除算はその特殊なケースとなる. (除算の場合はn/(a+bi) := n * (a-bi)/(a^2+b^2)として乗算と見なせる)

この場合本来の(連続的な)除算演算と近い意味を持つ整数除算 についても、原点で対称となる[-1,-3]となる系の方がむしろ美しいような気もする.

無論除算と整数除算は同一の概念では無く、連続的な数を扱う除算に対し、整数除算自体が現実に存在する非連続のものを「分ける」という概念とも見なせる、無論この場合負数というのは現実には存在しない為、この演算を負数に展開して良いかという議論は残る. また反面nを法とするような系について考える場合(厳密には整数論であり実数集合では無いが)(2)の演算にも妥当性がある.

はてさて、どうしたものか :-<

※1) 何かMS系BASICみたいとか言われてしまいそうだが、自分の用途が比較的浮動小数点数を多用する為1.0などと書かないと勝手に整数として扱われては非常に迷惑であるし、かと言って実際整数と実数の区別の無いデザインの処理系では下手に除算しておかしな事になってしまうケースも多い為、別途整数除算演算子が必須だと思う、みたいな ;-)

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

実際の所は(1)の系を採用する事にした、慣用的には(2)の方が思考に即しているかもしれないが (VBが(1)の系を採用しているのに対しExcelのmod関数では(2)の系を返すのが実にヒューマンインターフェイス設計として面白い) 上のような哲学的な話は置いといて、C/C++でのプロトタイプ時に(intとの)演算結果が違うと混乱の原因になり兼ねないという理由と、別途製作している複素数の行列処理言語 (より初期の計算プロトタイプで使う、演算の試行錯誤で複数データを扱う場合にクロージャ+高階関数を使った処理すら面倒と感じるような段階での検討用、但し特化し過ぎてる為汎用性は無い) との間で式の互換性が無いとマズいという至極単純な理由.

但し(2)の演算も規則的なパターン的なものを扱う場合のutilityとしては非常に便利な為、演算子 %%, \\を慣用的な整数除算向けとして別途定義し(行列処理系で)複素数を扱う場合には実数,もしくは純虚数での演算以外をエラーとする形にした.

、、、まぁかなりどうでも良い内容の話だが(笑) こんな微々たる話でも、改めて「数」というものを考えると色々面白いものだなぁなどと実感する、みたいなそんなカンジ ;-)

あるコンテキストにおいて生成された名前付き(つまり変数に代入された)クロージャはすべからく循環参照になるワケで.

寿命の長いオブジェクトなら問題無いけど、関数呼び出しなどでテンポラリで作成されるものが一番タチが悪くGCにかなりの影響を与える. 気付かずにこういう構造ができてしまうのも問題と言えば問題かもしれない、、、まぁ実質想定用途では問題無いし、この辺りを全く意識せず湯水のごとく扱えるのもスクリプトのありがたみではあるが(※1) やはり用途次第か、うーん.

※1) ふと気になったので以前書いたZバッファレンダラで3000ポリゴン程度のオブジェクトを320x240でレンダリングした際のスクリプト上のヒープオブジェクト生成回数のプロファイルを取ってみた、、、結果は.

、、、まともなC/C++プログラマが見たら卒倒しそうな数字だな(笑) ポリゴンの読み込み以外ならC++でのインスタンス生成は2桁で十分じゃなかろうか、無論配列などの暗黙の生成はスクリプトの使い勝手において非常に重要なものであるし、用途が違うのであれこれ言うものでも無いが、改めて数値を見ると呆気に取られる部分もあるなぁ(苦笑)

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

最近Pythonのインデントが気持ち悪くなくなってきた(※3) selfやコンテキスト周りなどレガシーっぽい部分を引きずっている気もするけど、実行速度や構文のバランスも悪くないし、プログラム自体も(メタクラスなどを扱う個所を除けば)典型的な手続き型で分かり易くシンプルなものだと思う、この辺はRubyのメソッドチェーンの多用とブロック呼び出し(イテレータ)などに見られるアグレッシブさとは対称的で保守的な印象、というかPythonってやっぱ思想的に硬い(但しJavaやPascalを指すような悪い意味では無く)印象があるなぁ、ドイツ製品とかそういうものにあるイメージ、みたいな(作者はオランダ人だけど)

いちいちimportとか正規表現の記述とか色々面倒なのでプライベートで使う事は無いけど、仕事でPerlとの選択であればPythonでも悪くないカンジ. 無論純粋に技術的な視点のみで政治的やリソース的な要素は考慮しないでという話で、だけど ;-)

という事で配列内包表記やらスライス表記やらループ文のelse等 Pythonにある機能なども自作インタプリタに追加してみたり、安易にカリー化を実現する為にラムダ式に局所スコープを導入したり、高階関数系のライブラリも充実してきてコードを見ると(Python + JavaScript + C++プログラマっぽい機能)/4〜5位のカンジだろうか、JavaScriptも1.5以降またECMAScript4とかは随分Pythonっぽいけど (しかし実際に使えるのは何時になるか、OperaとかFirefoxとかは頑張っているけどそんなものはマニア向けでしか意味無いし、主流のIEを握るMSとしてはAjaxでのクライアントアプリが優勢(※1)になっても実質何のメリットも無いからなぁ(※4))

以前JavaScriptのインタプリタを作っていて、幾つか言語仕様の (自分にとっての) 致命的欠陥 (暗黙の宣言がグローバルになる、関数引数に対するチェック機構が無い) からコードを廃棄した時、友人にそんなに気にするならその部分だけ独自仕様にしたら、と言われたのに対し中途半端にJavaScriptに似せているなら仕様に則っている方が優先されるのでは、的な話をしたが、結局新規に作った言語もある意味JavaScriptと似ている辺り何ともはや、とは言えJavaScript2としてアナウンスされているものが実装されれば良いかというと、結局レガシーも引きずっていてやっぱり自分の美的感覚には反する (特にあのletは無いよな、型指定も不必要に冗長だし) ので結局「自分の為のもの」は自分で作るしか無いワケだけど.

※1) とは言え現状のJavaScriptで無理矢理リッチクライアントっぽくってのがメインストリームになるのもどうかとは思うけど. 先日NiftyのメールサービスがAjax対応になってブラウザ内で独自ウィンドウを表示するような仕様になったのだが (Webメール2.0というらしい) ログインしてから表示完了に毎回時間がかかる(多分通常のhtmlフォームの2〜3倍程度)ので結局使ってない、Webでの確認はスパムフィルタをすり抜けるメールを排除する為だけの自分の用途としては余りに重いし、例え見た目がクールでも、一瞬で表示されるフォームに比べ表示完了までの数秒マウスを握ってぼんやりディスプレイを眺めているのは余りに馬鹿馬鹿しく感じるのだよね ;-P

※2) breakとcontinueのラベル指定もちゃんと入れましたよ、ええ(って誰に言っているのだか.

※3) 最初は閉じられていないブロックがまるでパンツを穿いていないような何とも言えない気持ちの悪さを感じたのだが、慣れるものだなぁ、というカンジ.

※4) と言ってもLinuxがクライアント分野で主流になるとかは無いワケだが (根底にある設計思想が余りに違い過ぎる) 最近久しぶりに触ったLinuxデスクトップも以前よりは随分マシになっているっぽいけど、根底にあるのがSunが設計したswingと同じような匂いがする気が、、、 :-P

以前より据え置きにしていたconst構文と、ユーザー定義関数の可変長引数のサポートを実装、関数オーバーロードは固定長→可変長の順に優先設定、constの糖衣構文としてenumを実装、多少宣言的であり事前計画的要素ではあるがdefineでシンボルを並べるよりはenumの方がタイプ量が少ないのでという所. ついでに連想配列リテラル表記をJavaScriptに合わせる、JSONデータなどを使い易くする為だが自分の用途でそんなモノ使うかどうかははなはだ不明、まぁ余興というトコロ.

この小康状態のタイミングで現バージョンのスクリプトの言語仕様 (クラス及び計画的な要素を可能な限り廃して使い捨てプログラムを書き殴る規模向け、但し方法論としては一般的なスクリプト要素をほぼ備える事) を完成させてしまう予定、次のアクションまで余り猶予は無いので結構尻に火がついてるカンジ(苦笑)

@ITの記事より「AjaxベースのWebOSとAjaxオフィスが統合」

最初はWeb2.0 (とか言うと恥ずかしいネ) もここまで来たか、すげー、とか思いながら見たのだが、冷静に考えるとこれって何処かで見たような、、、確かあれはJavaのSwingのデスクトップだ、アレを見た時も同じような感慨があり、また後に落胆する事となる.

あるいは古くから言えばNetwork OSであったり、太古で言えばX端末から続く話となる. 少し前色々話題となっていた仮想化周辺の技術も然り、仮想化のサーバ製品などは正に昔のX/ダム端末を彷彿とする.

そしてそのWeb2.0 (だから言いたくないんだって) の利便性を補う為の技術として

「グーグル、Webアプリをオフライン対応にする「Google Gears」開発」

だそうな、、、何と言うか、、、ひたすら焼き直しの下位階層が増える建て増しのような気もするが、あるいはこれがDOSからWindowsに移った時のような変革であるのか、、、うーん、ただ、何か少しズレている気がするのは僕だけだろうか?

# まぁ個人的な感情もあるのは確か、個人プログラマの自分にとってはWebはデスクトップ程エキサイティングでは無いし、配布と開発の分業化のプロセスにおいてWebアプリの方が作りやすかったという企業側の事情もあるのではなどとも思ってしまう、エージェントシステムなどの分散環境には興味があるが、単に「繋がる」だけのシステムには余り面白みを感じない. あるいは定型業務やメディアとしてのコンピュータも然り.

、、、あるいは、歳を取ったという事かしらん(苦笑)

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

最近のMSの戦略を見ているとデスクトップは(デザインの手軽さや見た目の華やかさで)Webに近づこうとし、Webは利便性の部分でデスクトップに近づこうとしているカンジ、ソフトの用途自体は既に膠着状態にあるし (誰彼から反論がある気もするけど) 結局またまたAPI戦争って事かもしれない ;-)

# しかしWebを複雑にするのは良いけど、結局内部遷移が複雑になるとそれなりのプログラマを雇わないとキツいワケで、Webによる最大のメリットの一つであるプログラムの工業製品化 (つまりは確保し易い人材で賄える複雑さ・分割に落とし込む) とは相反するのだよねぇ. 言ってみればデスクトップアプリを組む複雑さと何ら変わらなくなってしまうし. この流れは(比較的まとまったリソースがかけられるコンシューマ向けサービスなどは別だが) 全体の流れとして来るのか、あるいはもう一段クッションが必要なのか、はてさて.

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

もう一つ@ITネタ「総論：C# 2.0らしいプログラミングとは」

内容はC#2.0で導入された無名delegate(クロージャ)とクラス機能を比較して、クラス機能よりクロージャの方が柔軟なのでCoolなコーディングが出来るヨ. というような話 (悪意のある誇張はあるが、得てしてこういう論調の記事を読んだ人間の受ける印象というのはそのようなものだ)

言っている内容が間違っているワケでは無いのだが、クロージャのメリットだけが強調されてデメリットについて書かれていないのは如何にというカンジ、確かにクロージャベースの構造の組み立てはクラスベースに比べ柔軟だが、その柔軟さ故にスパゲッティになりがちでもある. またクロージャ内でリソースを扱う場合はより深刻でクラスベースであればリソース管理の根元をクラスのシャットダウンに任せられるのに対しクロージャでは下手な作り方をしてしまうとファイナライザに任せるしか無くなってしまう.

メンテナンスで実行を追う場合も然り、クラスという実行単位があるクラスベースに対し何処でもアクションを追加できるクロージャは下手なプログラマがいじると後から実行を追うのが極めて困難な構造を安易に作り出し得る. 正直Ajax技術が出始めた頃 (商用ベースのメンテナンスまで考慮した時に) この規模の複雑なJavaScriptをまともに扱えるプログラマを確保するのはJavaプログラマを確保するよりも遥かに難しいだろうなぁなどと思ったのだが、それと同じように悲惨な話になりかねない.

余り無意味に特定の技術の利点だけを強調して煽るような記事ってのはどうかなぁ、などと思う事しきり. まぁ得てして技術系のトピック紹介はそういう傾向があるのも事実だが、実際のコーディングに密着した記事では如何なものかというカンジ :-<

# まぁ自分の作っているスクリプトもクラス機能をオミットしてクロージャは残すというようなカンジなのでアレだが、これについては作り捨てのプログラム向けなのでという背景があり、決して全ての規模の開発でクロージャの方がクラスより優れているという意図は無い ;-)