いや、速いことそれ自体がいけないとは思わないんだけど。

なんで表題のようなことを思ったかと言えば、Cが高速だってのは安全性とのトレードオフの結果だから。そして、アプリケーションの律速要素は言語それ自体よりも、それ以外の部分にあるから。となると、そんなにCばかりが高速になる必要はないし、だったら安全性を確保してもいい。

今はあまり言わなくなったけど、元々のCは「ポータブルアセンブラ」だった。アセンブラをポータブルにして、高級言語っぽく書けるようにした。それが元々のCだ。だから速いし、だからいろいろ自分で面倒を見なきゃいけない。

時代は下がって、今はCは汎用高級言語としても使われるようになった。そこいらにあるアプリケーションは、たいていCで出来ている。とは言え、全てがCでなきゃいけないような、低レベルなことをしているわけでもないし、高速である必要もない。ただ、比較的綺麗なバイナリのアプリケーションが作れる言語がCだってだけだ。一々ランタイムを用意しなきゃいけない言語でアプリケーションが書かれていたら、かなり面倒臭い。私があまりJavaなアプリケーションを好まないのはその辺が理由だ。

Cは高速だけどいろいろ危険だ。今時は普通にちゃんとしたOSの上だから、MS-DOSの時代みたいに「ポインタ間違えたからリブート」なんてことはなくなったけど、それでもコア吐いたりするし、サーバ系のアプリならバッファオーバフローで攻撃とか出来てしまう。そうならないようにいろいろ自分で手当しなきゃいけないのがCだ。

RubyとかJavaとかはいろいろ安全だけど、ランタイムが必要だったりインタープリタが必要だったりして面倒臭い。そもそも、そのままサクっと.soがつながらない。いろんなラッパが必要になってしまう。どうせ必要なのは、いろんなオーバーフローのチェックとかその程度なんだから、OOPすらわりとどうでもいい。てか、JITとか言わなくてバイナリ落とせよ。

ということで、Pascal程度の重さでいろいろ細かいことを気にしないでアプリケーションが書ける言語があると良いなぁと思わんでもない。バイナリ落とすんだったらgcjとかって手もあるんだろうけど、これも微妙だしな。諸々のダイナミックな言語もいろいろ頑張っているけれど、そこまでの柔軟性を「Cの延長」に求めるつもりもないしな。

と言っても、今さらCみたいなプリミティブでOOPでもない言語を新しくデザインするってのも、時代に逆行しているような気がするよなぁ…