プログラミング環境に対する思考実験

Java,C#から、PHP,Perlや果ては組み込みまでやる立場からちょっと考えてみます。

まずは立場の表明から。
私は、JavaやC#に類するバイトコードによる中間言語というものが好きです。これは、アルゴリズムを記述するための方法論のうち、特にシンプルでなおかつ実装依存にならないぎりぎりの線がこの辺であろうと思っているからです。
フォン・ノイマン型コンピュータの基本原理を実現した今時のCPUは、たぶんバイトコードからならばネイティブに変換したときに（もしくはインタープリタループでよしなに解釈したときに）うまく環境依存部分で最適化できると思っていますので。
でも、環境依存部分をよしなにこなす必要がなければ、バイトコードはあるタイミングでいきなりネイティブになっていてもさほど困らないという見方は可能です。
特に、JavaやC#はプリベリファイヤが結構発達しているので、コードの段階である程度安全な動作を保証できます。なのであれば、VMが本来持っているはずの特質の一つであるところの安全性は、AOTコンパイルされたネイティブコードであっても保たれるとはいえます。このとき、ディスクやメモリに対するフットプリントはバイトコードの状態よりも大きくなるでしょうが、まぁ、CPUパワーの消費に由来する電力消費に比べれば微々たるものでしょうし。
ただ、Javaにしても、C#にしても、はなっからコンパイルせずに動くスクリプト言語よりは書き換えに対する心理的抵抗はちょっと高めです。
がっつり設計して、一発で動かさせるタイプの開発よりも、動いているところをちまちまと直しながらクオリティを上げる言語の方が、迷ったり立ち止まったりすることは少ないでしょう。
もっというと、わざわざプログラムを動かしなおすよりも、動いているプログラムを直接書き換えるぐらいの方がもっと心理的抵抗は低いはずです。コンパイルという意識がないのなら、こっそりコンパイルしていても全然抵抗にはならないでしょうし。

……ってなことをいろいろ考え始めると、やっぱりLISPやSmalltalkってすごいよなぁ、って気は確かにします。Eclipseも、VisualStudioとCLRも、どうやら目指すところはSmalltalkみたいですし。
とはいえ、今時の環境だって、決して負けてはいないと思います。PHPのAccelaratorは、スクリプト言語の中でも特に重い構文解析をあらかじめ行ったものをメモリやファイルシステム内に自動的にキャッシュしますし、RubyもPerlも今時実行環境はVMです。スクリプト言語だからコンパイルしないなんてことは全然無いです。あまり表から気にされない（ようにしている。心理的抵抗ができちゃうし）だけで。

C言語で一から書くとパフォーマンスがいいという幻想は、結局、安全性をどこかが担保するか、そもそも担保しないのかというその一点に集約されちゃうんじゃないのかなーって気は、非常にします。
C言語はプリベリファイヤがあまり多く使われていませんし、型やバインドに関する意識も薄目です。なにより、安全性を担保するのはプログラマーであって言語や環境ではないという思考が貫かれています。いや、この思考自体がいいとか間違っているとかではなくて、担保しなくてもいいならパフォーマンスはその分上がるし、担保しようとすると、結局高級チックな言語と同レベルにまで落ちるだろうなぁ、と。
だったら、作る際に楽できたり、可搬性高くしたりできた方がやっぱりいいよなぁ、とは思うのでした。

あ、もちろん、メモリのほとんどないNintendoDSにSmalltalkのJITコンパイラを乗せたり、プログラムを差し替えることが有り得ない炊飯器にJavaVMを乗せるのは良いとはいいませんよ。
安全性とかの担保が必要そうな環境は、たまたまリッチなところが多いって傾向に則って話しているだけで。
……待てよ。
ってことは、安全性が非常に要求されるMillitary&Medical環境や、車などのバグが許されない割にリアルタイムは必要な組み込みはそれこそバイトコードVMでいろんなものを担保すべき……？
えー？　なんかそれは、やだなぁ。生理的に(^^;)。どんだけー*1

*1:書いていてまとまらなかったときには最近いつも使ってるような……