似たもの技術：サーバサイドJavaとメインフレーム
似てると言っても、サーバサイドJavaのXMLによる面倒くさい設定とメインフレームにおけるJCLの面倒くさい記述が似てるなぁと思っただけなんだけど。
さすがにServletやJSPは知ってるが、それだけではマズイかと思ってStrutsやDIフレームワークをかじったりしている。ここらへんの技術でよく用いられるのが、ソースコード中ではファイルやbeanや依存関係などを抽象的な名前で扱っておいて実体はXMLファイルで設定する、という手法だ。まぁ理屈はわかるが面倒臭い。
一方、仕事でz/OS*1をさわっていて今時のOSとのあまりの世界観の違いに戸惑ったりしている（最近は余裕が出て面白くなってきた）。一応z/OSにもUNIX System ServicesというUNIXエミュレーション環境があるのだが、素のz/OSではプログラム中にファイル*2の名前をハードコーディングしない。その代わり、プログラム中ではSYSPRINTとかSYSDATAとか適当な名前でファイルを扱い、ファイルの実体との関連付けはバッチ記述ファイルであるJCL (Job Control List)の中に書く。
この全然関係ない二つの技術の面倒臭さの質はなんだかすごい似ているように感じた。もちろんUNIXでもデーモンの設定ファイルにあれこれ記述する必要があるのだが、簡単なプログラムではそんなことせずにシェルを介してファイルをプログラムに渡せる。z/OSではどんな簡単なプログラムでもいちいちユーザが関連付けを書く必要がある*3のだ。もぅ、その面倒臭さといったら*4。先輩曰く、「シェルというのはやはり発明だったのだ。」詳しい経緯は知らないが、UNIXとその親であるMULTICSが「発明」した「シェル」という概念はやはり画期的だったのだろう。
歴史的な流れで言うと「シェル」的な概念はメインフレーム的なユーザインタフェース概念を当然のことながら駆逐していくわけだが、それを考えると現代のサーバサイドJavaの恐竜っぷりの将来が気になってしょうがない。しょうもなくて当たり前だけど画期的に使いやすい新しい概念が今のサーバサイドJavaのドン臭さを駆逐していってくれると面白いんだけどね。
