「今日使われているプログラミング言語の多くは、なぜ1990年前後に誕生したものなのか」に関する一考察 http://d.hatena.ne.jp/kazuhooku/20131221/1387603305 という文章を読んだ。
内容をまとめると、90年ころからコンピュータのメモリコストが下がり、変な制限をつけなくても文字列を簡単に処理できるようになった、そういう新しい言語や処理系は文字列処理の優位性があるので今でも生き残って使われている、という仮説だ。
仮説構築としては面白いと思う。でも、いろいろ議論に穴があるんじゃないかなぁという気がしているのでちょっと事例を調べてみた。
C++。C with classesのはじまりは1979年で、1983年にC++という名前になる。90年前後ってのは全然ただしくない。ただ、このころのC++にはSTLは存在しなかったわけで、「文字列型」もなかった（のだと思う、知らないけど……）。となるとSTLの歴史も知っておく必要があるが、STLは92年ということで良いのかな？ これは90年前後と言えると思う。
Objective-Cも登場は同じ1983年だ（↑には言及されていないけれど、iOSアプリを書くのに必要な本言語はまさに「今日使われている」だろう）。とはいえNeXT以前のObjective-Cがいったいどうなっていたのかはまったくわからない（たとえば、NeXT以前にNSStringがあるわけない）。NeXTの創業は85年だそうだが、NSStringなどのフレームワークが、いつどのように整備されていったのかはぼくは知らない。NeXTStepの発展の歴史をひもとけば、これが90年前後ということはかなりありえそう。
Java。Javaの登場は意外と新しく1995年だ。これは、90年前後と言うには振れ幅が広いんじゃないですかね……。Javaから名づけたJSも95年と同年だったのは知らなかった。
スクリプト言語類を見ていくと、Perlは87年、Pythonが90年、PHPとRubyが95年。あとLuaが93年。PHP/Rubyはけっこう新しいですね。これを「90年前後」と言うかなあ……。
以上は、昨今の業務において比較的メジャーな言語といえると思う。もちろんScalaやGoなどの新しい言語も「使われている」の範疇に入れていいと思うけれど、確かにこの辺の言語は生き延びている。
---
もう少し視野を広げてみる。たとえばHaskellはどうだろう。「今日使われている」かはさておき（一部の特殊な世界では使われているが）、Haskellは文字列型を持たない言語だ。文字列とは単なる文字のリストであり、豊富なリストユーティリティを持つからいいじゃねえかという気もするけれども、やはりそれは違うだろう。そしてHaskellの登場は、じつはまさに90年だったりする。
ただHaskellの文字列型も、それじゃやっぱり不便だよねということでByteStringなどが整備されていったりしている。その現象が起きたのはここ数年……とまではいかなくても、00年代後半以降である。これはHaskellがそれなりに使われようとされはじめたということを意味している、のかもしれない。そうじゃないのかもしれないが。
同じようなパターンがErlangにも当てはまるかも。Erlangにも文字列型は存在せず、バイナリ列とか文字コードのリストとかしかなかったはずだ。Erlangは特殊な用途ではあるがずっと使われていた言語である。
あと、ぼくは全く知らないがAdaはどうなのだろう。どういう文字列ユーティリティがあるのかはよくわからないが、Adaは軍用として長く使われてきた実績があるはずである。ちなみに登場は83年。
いちおう言及しておくと、Lisp系の言語はシンボル処理が多かったのではないかと推測されるけれど、もちろん今では文字列型も含まれている。この辺がどういう時期に現れ、発展してきたものなのかはよく知らない。Scheme R3RS （86年）にはすでに文字列リテラルは存在していたし、簡単なユーティリティは存在していた。ただ、文字列の基本的な処理をまとめたSRFI-13は99年の登場となっている（というかSRFI自体がそのころに始まったものなので）。Common Lispの登場は86年だが、CLはそれ自体の由来からしてあんまり参考にならなさそう。
---
以上、簡単に事例を積み上げてみたが、やっぱり「90年前後」というポイントにはムリがあるんじゃないかなぁ、というのが個人的な感想だ。だけど一方として、90年ぐらいからパーソナルコンピュータやワークステーションなどの上でのプログラミングでメモリとかを気にしなくても良くなってきた、というのは感覚的には理解できるわけで、その辺のすり合わせをどう持っていくかというのが気になるところかな。
Unixには、主に行志向の文字列処理ユーティリティ群が大量にあった。こういう奴らのストリーム処理に対して、メモリコストの低下から、もっと汎用的に処理ができるPerlのようなユーティリティが発達してきた。で、ワークステーションなどの管理に使われていた。そして、サーバサイドはいまだにUnixというかLinuxがメジャーで、そういうシステムではたいていの場合、文字列処理を多用する（設定ファイルとかはたいていテキストなので）。したがって、文字列処理が得意な処理系は有利だ、という仮説はあるかもしれない。
---
最後に蛇足として、こういうことを考えるならついでに「では今現在、もしくは近年、実はコストが下がっていて、それによってプログラミングに変化が訪れているものは何か？」と考えてみるのも良いのではないかと思う。
いろんなテーマが考えられるだろうけれど、昨今の流行や新言語の雰囲気を考えるに、「メモリ非共有なマイクロスレッドによる並行実行処理」なんじゃないかと思う。マルチスレッドやマルチプロセスじたいはありふれているが、スレッドやプロセスというのは比較的重いモノであるという考え方から自由になり、「深く考えずに気軽にスレッドを作りまくって良い」というのは比較的新しいパラダイムだろうと思う（もちろん、むかしからErlangがそういう感じだったのだが……）。それでも最近の言語は、こういうものをうまく扱えることをウリにしているように思うのだった。
内容をまとめると、90年ころからコンピュータのメモリコストが下がり、変な制限をつけなくても文字列を簡単に処理できるようになった、そういう新しい言語や処理系は文字列処理の優位性があるので今でも生き残って使われている、という仮説だ。
仮説構築としては面白いと思う。でも、いろいろ議論に穴があるんじゃないかなぁという気がしているのでちょっと事例を調べてみた。
C++。C with classesのはじまりは1979年で、1983年にC++という名前になる。90年前後ってのは全然ただしくない。ただ、このころのC++にはSTLは存在しなかったわけで、「文字列型」もなかった（のだと思う、知らないけど……）。となるとSTLの歴史も知っておく必要があるが、STLは92年ということで良いのかな？ これは90年前後と言えると思う。
Objective-Cも登場は同じ1983年だ（↑には言及されていないけれど、iOSアプリを書くのに必要な本言語はまさに「今日使われている」だろう）。とはいえNeXT以前のObjective-Cがいったいどうなっていたのかはまったくわからない（たとえば、NeXT以前にNSStringがあるわけない）。NeXTの創業は85年だそうだが、NSStringなどのフレームワークが、いつどのように整備されていったのかはぼくは知らない。NeXTStepの発展の歴史をひもとけば、これが90年前後ということはかなりありえそう。
Java。Javaの登場は意外と新しく1995年だ。これは、90年前後と言うには振れ幅が広いんじゃないですかね……。Javaから名づけたJSも95年と同年だったのは知らなかった。
スクリプト言語類を見ていくと、Perlは87年、Pythonが90年、PHPとRubyが95年。あとLuaが93年。PHP/Rubyはけっこう新しいですね。これを「90年前後」と言うかなあ……。
以上は、昨今の業務において比較的メジャーな言語といえると思う。もちろんScalaやGoなどの新しい言語も「使われている」の範疇に入れていいと思うけれど、確かにこの辺の言語は生き延びている。
---
もう少し視野を広げてみる。たとえばHaskellはどうだろう。「今日使われている」かはさておき（一部の特殊な世界では使われているが）、Haskellは文字列型を持たない言語だ。文字列とは単なる文字のリストであり、豊富なリストユーティリティを持つからいいじゃねえかという気もするけれども、やはりそれは違うだろう。そしてHaskellの登場は、じつはまさに90年だったりする。
ただHaskellの文字列型も、それじゃやっぱり不便だよねということでByteStringなどが整備されていったりしている。その現象が起きたのはここ数年……とまではいかなくても、00年代後半以降である。これはHaskellがそれなりに使われようとされはじめたということを意味している、のかもしれない。そうじゃないのかもしれないが。
同じようなパターンがErlangにも当てはまるかも。Erlangにも文字列型は存在せず、バイナリ列とか文字コードのリストとかしかなかったはずだ。Erlangは特殊な用途ではあるがずっと使われていた言語である。
あと、ぼくは全く知らないがAdaはどうなのだろう。どういう文字列ユーティリティがあるのかはよくわからないが、Adaは軍用として長く使われてきた実績があるはずである。ちなみに登場は83年。
いちおう言及しておくと、Lisp系の言語はシンボル処理が多かったのではないかと推測されるけれど、もちろん今では文字列型も含まれている。この辺がどういう時期に現れ、発展してきたものなのかはよく知らない。Scheme R3RS （86年）にはすでに文字列リテラルは存在していたし、簡単なユーティリティは存在していた。ただ、文字列の基本的な処理をまとめたSRFI-13は99年の登場となっている（というかSRFI自体がそのころに始まったものなので）。Common Lispの登場は86年だが、CLはそれ自体の由来からしてあんまり参考にならなさそう。
---
以上、簡単に事例を積み上げてみたが、やっぱり「90年前後」というポイントにはムリがあるんじゃないかなぁ、というのが個人的な感想だ。だけど一方として、90年ぐらいからパーソナルコンピュータやワークステーションなどの上でのプログラミングでメモリとかを気にしなくても良くなってきた、というのは感覚的には理解できるわけで、その辺のすり合わせをどう持っていくかというのが気になるところかな。
Unixには、主に行志向の文字列処理ユーティリティ群が大量にあった。こういう奴らのストリーム処理に対して、メモリコストの低下から、もっと汎用的に処理ができるPerlのようなユーティリティが発達してきた。で、ワークステーションなどの管理に使われていた。そして、サーバサイドはいまだにUnixというかLinuxがメジャーで、そういうシステムではたいていの場合、文字列処理を多用する（設定ファイルとかはたいていテキストなので）。したがって、文字列処理が得意な処理系は有利だ、という仮説はあるかもしれない。
---
最後に蛇足として、こういうことを考えるならついでに「では今現在、もしくは近年、実はコストが下がっていて、それによってプログラミングに変化が訪れているものは何か？」と考えてみるのも良いのではないかと思う。
いろんなテーマが考えられるだろうけれど、昨今の流行や新言語の雰囲気を考えるに、「メモリ非共有なマイクロスレッドによる並行実行処理」なんじゃないかと思う。マルチスレッドやマルチプロセスじたいはありふれているが、スレッドやプロセスというのは比較的重いモノであるという考え方から自由になり、「深く考えずに気軽にスレッドを作りまくって良い」というのは比較的新しいパラダイムだろうと思う（もちろん、むかしからErlangがそういう感じだったのだが……）。それでも最近の言語は、こういうものをうまく扱えることをウリにしているように思うのだった。
No comments:
Post a Comment