2009/09/25
プログラミング言語の進化
プログラミング言語の歴史を眺めていると、経験の中から立ち現れるベストプラクティスを取り込んだものが多いことに気がつく。
- 構造化
- 例外サポート
- オブジェクト指向
- 並列サポート
言語の進化はベストプラクティスをサポートするためにあるんじゃなかろうか。
そういったケースが多いのは確かだろうけれど、それだけ見てるとまずいと思う。
言語というのは表現の道具であって、動作するプログラムを表現するには 言語を使うしかない。では、これらの「ベストプラクティス」が言語に 取り込まれる前には、どうやって表現されていたんだろう?
- 他の機能を組み合わせて無理やり表現していた (e.g. CによるOOP)
- プログラムとして表現するのを諦めて、自然言語で表現してプログラマが逐一実装してた (e.g. デザインパターン)
どちらにせよ、これは表現として不自然だ。 そのプラクティスが有用であることが既にわかってるなら、 不自然な表現でも何とかそれを使おうとして、やがてそれが広まり 言語にサポートされることになるわけだけれど、そもそも最初に そのプラクティスを始めようと思った人達は、どうやって その不自然な表現を乗り越えたんだろう?
例えば、内包表記は便利で、いろんな言語が採用し始めているけれど、 多くの言語は他の言語の内包表記を見て便利なことを知って採用したんだと思う。 内包表記のおおもとの起源は数学記法だけど、「これを プログラミング言語に取り込んだら便利だろう」と最初に思って 実行した人がいたはずだ。その時点では、内包表記は 「経験の中から立ち現れるベストプラクティス」ではなかったはずだ。 だってプログラミングで内包表記を使うという経験はそれまで無かったわけだから。
あるいはスタティックスコープ+無限エクステントでもいい。 スタティックスコープは前からあったけれど、それを無限エクステント にしてlambdaがクローズするようにしたら、funarg問題があっさり解決しちゃった。 でもSchemeがそれをやってみせるまで、人々はfunction特殊形式みたいな アドホックな方法でfunarg問題を解決しようとしてたわけで、 決してスタティックスコープ+無限エクステントがベストプラクティスと みなされてたわけじゃない。
つまり、プラクティスの中には、「実際にその言語機能を使って書いてみるまで それがベストかどうかわからない」というものがある。
代替の表現方法が「ちょっと面倒くさい」程度ならまだ、その手間をかけて まわりくどい方法で書いてみようという人はいるだろう。けれど、今ある言語機能では 実現するのが非常に面倒くさい、実現できるかどうかもよくわからない、 というプラクティスについては、よっぽどモティベーションが高くない限り、 遠回りな方法で今の言語上に実現してみようとは思わないはずだ。 ベストプラクティスを取り込むという点だけ見ていると、そういう妙な アイディアを見逃すことにはならないだろうか。
逆に、ベストかどうかわからないけど、妙なアイディアを思いついたら 気軽に言語の方を変えてそのアイディアを表現できるようにしてしまう。 そしてそれを使ってみる。うまくいけば広めればいいし、ダメならスクラップすればいい。 そういう過程もまた、言語の進化には重要だと思うのだ。
Tag: Programming
