ソフトウェアデザインのトリレンマ

国際金融のトリレンマというものがある。
これは(1)為替レートの安定、(2)独立した金融政策、(3)自由な資本移動の3つのすべてを同時に達成することはできず、2つを達成した時点で残りの1つは捨てなければならない、という話だ。
金融政策を独立させて自由な資本移動を確保すると為替レートは資本移動に伴って変動しまくるし、金融政策は独立した状態で為替レートを安定させようとすると資本移動を制限しなければならない。為替レート安定と自由な資本移動を保証すると金融政策で為替を安定させる必要が出てくる。

これと似たような感じで、ソフトウェアデザインにもトリレンマが存在するのではないか、と、ふと思った。(1)簡単さ、(2)柔軟性、(3)速度の2つを達成した時点で残りの1つは捨てなければならない。簡単で柔軟なソフトは遅い。柔軟で速いソフトは難しい。簡単で速いソフトは制限が多い。どうだろう。

俺が扱っているもので例を挙げるなら、Rubyは簡単で柔軟だが遅い。C++は柔軟で速いが難しい。DirectXも柔軟で速いが難しい。DXRubyは簡単で速いが制限が多い。という感じか。
プログラム言語についてはそもそもが柔軟であるものなのでモノサシは簡単か速いかということになるわけだが、柔軟性についてはそれぞれベクトルが違うので比較しようが無い。また、ソフトウェアの実行速度は実装テクニックも関係するから、ある時点での絶対性能をもってして速い遅いという比較は意味が無い。どちらかというと傾向とか、高速化するのに必要なリソースのようなイメージが近いか。

DXRubyは特性の違うRubyDirectXを結びつけるために、DirectXの速さだけいただいて柔軟性を切り捨てて、Ruby的な簡単さとRuby的な柔軟性を重視している。Rubyの良さを保つためにDirectXの良さを削っているわけだ。そういうことをしないとこの2つを結び付けることはできない、ということだ。
まあ、なんかソフトを作るときには何を重視して何を切り捨てるのかを明確にすることが必要だろう。少なくとも全部取りは不可能だということを、ソフトウェアデザインのトリレンマは物語っているのだと思う。