どうせ擬人化するなら

みなさんは実行コンテキストをどういうふうに頭の中にイメージしていますか。

私は、例えばスレッドやプロセスを小さな妖精(例えばホビット)に喩えて考えます。

ミューテックスきのこを踏んづけたら、ビビビと瞬間的に固まってしまって、別のホビットが動き出す、という具合です。

しかし最近になって、その喩え方が、あまりよろしくないことに気づきました。

そもそもコンテキストというのは、一人しかいないホビットがまるで何十人もいるかのように振舞ったときの、ホビットの幻影なのです。悟空で言えば、残像拳です。

マルチプロセスやマルチスレッドというのは、本来は数百人のホビットで一斉に行う仕事をせいぜい32人くらいでおこなうための仕事の管理の仕方でしかないことに気づかされます。

#って、お前が忘れてただけだろ

いまさらながら、それってそもそも無理あるよなぁ。しかも仕事の記述方法は、シングルタスク前提のプログラミング言語で。

最近の言語ではコンテキストを意識した、つまりコンテキスト・コンシャスなので、気にしなくてもいいのかもしれませんが、ごみためまんはまだまだ旧世界で食い扶持を稼がないといけないのです。

例えば100人のホビットのためにそれぞれ別々の仕事を記述するとしたら、それはシングルタスクを意識したものになりますね。しかし、100人でいっしょにやる仕事を記述するなら当然まったく別の記述方法が必要です。

なので、私が過去に見てきた、しっかりしたつくりのシステムはみな、それぞれのアーキテクチャを備えていました。アーキテクチャというのは、例えばユーティリティライブラリであったり、アプリケーション内の組み込み言語だったりします。それをミドルウェアと呼びたい人はどうぞ。

まともなシステムを構築するのに、一番下から一番上前1枚岩で作ろうとするおバカさんが多すぎるのです。一番下はユーティリティライブラリで、その上は、値クラスライブラリ、それを統括するマネージャクラスライブラリ、そしてアプリケーションです。ライブラリじゃなくて、レイヤと呼んでも同じことです。

上の住人ほど、より抽象化された世界で問題解決を記述できます。ただし自由度は低い。下へ行くほど泥臭いが自由度は高い。

この自由度の逆転現象には注意が必要です。上は例えばよりユーザに近い層なので、 実はこの自由度の低さが、ユーザビリティやエクスペリエンスに決定的に不利に働くことがあるのです。