読者です 読者をやめる 読者になる 読者になる

排他的万物理論

.NET

C# でコーディングしていると,背後にある CLI が「オブジェクトへのマッピング」を強制することによる限界や制限を感じることがあります.上記 Iterator の例をとっても,「列挙」がオブジェクト化した背後で,考慮すべき実行時状態が追加されたことを忘れてはなりませんし,IDisposable といった言語外の存在が重要な役割を演じることを受け入れる必要があります.
オブジェクト指向での「隠れた状態」の取り扱いの難しさについて,名無しさん♯は次のように書かれています.

最近は、JavaC#VB.NETなどのオブジェクト指向が主流になってきている反面、その設計・実装のむずかしさが障壁となっております。何が問題かというと、hidden stateの取り扱いがあまりにもむずかしいのです。単純なケースではきちんと動いてたのに、複雑になればなるほど予期せぬかつ再現しづらい不具合がなんてことが・・・。ヽ(`Д´)ノ

最近思うことは、「オブジェクト指向の前提って無理がない?」ってことです。状態管理が完璧に設計され、完璧に実装されている限り、プログラムは正しく動く。しかしながら、メモリの確保・解放すら信用されずにガベコレに仕事を奪われた人間様です。どうしてそんなことが期待できるのでしょう?現実は、よく起きる例外がぬるぽだったりして、オブジェクトが中身があるか空かすらきちんとコントロールできてないのです。(´・ω・`)

.NETに目を向ければ、データ関連が見事なまでにすべっております。その代表格はObjectSpacesでしょうか。CLIオブジェクト指向を前提としており、はっきり言って偏っています。データ関連の失敗には、このことと何か因果関係がないのでしょうか?

また別の記事では,.NET コミュニティでの「空気」が世界をミスリードすることへの懸念として以下のように述べられています.

また、たまには.NETから距離を置いてみることも大事。最近よく聞く声、

  • managed製IEはまだか
  • managed製Officeはまだか
  • managed製Visual Studioはまだか
  • managed製Windows Shellはまだか

ひどいのになれば、「MS製品がmanaged codeで作られてないから.NETは成功していない」などというステキな論理を披露する方もいらっしゃいます。WinFXと向き合う前に、こうした発想がいかに目的と手段の違いを見失ってるのかよく考えてみる必要があります。(元Java使いのおいらから見れば、あの悪夢再び、です。)

落ち着いて読めば同意できますが.気のゆるみからこのような文章を書いてしまいかねないという不安はぬぐえません.やはりズシリと重い響きを感じます.
オブジェクト指向が理解できれば何事もうまくいく」,あるいは「うまくいかないのはオブジェクト指向が理解できていないからだ」という主張を滑稽と感じるならば,自分が書く文章表現が「まず C# で記述すべきだ.後のことはそれから考えればいい」と解釈されないよう注意を払っておくことで,いつかどこかで何かが救われるかもしれません.本人にそのつもりが無くても,読者が誤解したまま誤解を再生産するリスクは低いに越したことはないでしょう.