少し前に、今すぐ辞めて欲しい、「Ruby on Rails勉強してます」「CakePHP勉強してます」なんていう、ちょっと過激なタイトルのブログをたまたま見かけましたが、思うところがあったので書き綴ってみます。
#コンピューターの歴史は抽象化の歴史
「70年以上前からコンピューターで（理論上）可能な情報処理の内容は変わっていない」というと、おそらく多くの人は驚くかもしれません。しかし、現在も「コンピューターで処理可能な範囲」と同義となっているチューリング完全性という概念が登場したのは、電子計算機が出現するより前の、実に1930年台の話です。その後登場した電子計算機は、時を経て劇的な高性能化、小型化、低価格化、入出力の多様化などを遂げるわけではありますが、処理可能なものについてはチューリング完全の範囲を超えるものではありません。
コンピューターの圧倒的な性能向上で、書かれるプログラムの規模がどんどん膨張していき、そして性能に余裕ができたこともあって、プログラムを書く方でも抽象化が進行していきました。初期には機械語で直接プログラムを書いていたのが、それを単語に置き換えたアセンブラとなり、さらには数式をそのままかけるようなプログラム言語が成立して、関数・オブジェクトとより大きな単位で扱えるようになっていく、そんな歴史がプログラミング言語の進化の歴史でした。
抽象化の能力
抽象化することによるメリットは、
- 詳細を考えずに実装が可能となる
- コードの再利用が容易となる
ということがあります。OSの上で動く（一般的な）プログラムは、OSに組み込まれたデバイスドライバなどが細かい差異を吸収してくれるので、自分でキーボードやマウスやディスプレイの制御をせずに済み、実装が簡易化されると共に、他の環境でも動くようになります。Javaやスクリプト言語のように、抽象度の高い形態のままでプログラムを頒布すれば、命令セットの異なる環境ですらそのまま動かせることもあります。
抽象化の限界
もちろん、抽象化にも限界がありますが、大きなポイントとして2つがあります。
- 抽象化レイヤがカバーできる機能範囲の限界
- 抽象化しきれない部分の存在
抽象化レイヤーの限界
森羅万象、あらゆる状況に対応できるシステムなんてものは存在しないわけで、どんな抽象化レイヤーについても、その上では扱いきれない部分が出てきます。こういう場合、OSであればデバイスドライバ、言語処理系であればより抽象化の低い言語で拡張できるような仕組みになっていることが多いですが、適切な拡張がない場合は、「抽象化度合いを下げた世界に入って、自分で何とかする」ほかなくなってしまいます。
また、抽象化レイヤー自体もプログラムですので、バグがあるようなこともあります。そういう場合も、バグを回避する、レイヤー側に手を入れるというように、抽象化しきれない部分となってしまいます。
チューリングモデルの限界
上では明言していませんでしたが、チューリング完全というのは資源（メモリ、実行時間…）の消費についてはなんら考慮していません。そういうわけで、完全性が保証される機能面と違って、実行速度やメモリ消費といった資源を適切に配分しようと思えば、下のレイヤに関する知識が往々にして必要となります。例えば、純粋に理論的に考えると、データベースにインデックスがどう付いていようと検索は可能なわけですが、大きなテーブルで実用的な性能を得るには適切なインデックスの構築が欠かせません。
言語内レイヤーについて
冒頭で出てきたRuby on RailsやCakePHP、そしてjQueryなどのように、あるプログラミング言語で書かれたフレームワークというものもあります。これらはよく使う処理について典型的な処理を実装してくれるなど、もちろん使いやすいものではあります。ただ、
- 純粋にフレームワークだけでできないことも多い
- 性能面を考えるには、フレームワークの中身まで知っておかないと身動きが取りづらい
- その言語で書かれているので、中身を読むこともできる
ということで、使っていくうちに中身を調べて、徐々に理解した上で使っていくのが、理想的な態度かもしれません。