インピーダンスがミスマッチしているのですよ

手続き型言語とSQLのインピーダンス問題。ビジネスロジックをSQLで書くのは是か非かみたいなのとか。あるいはGPGPU。やりたい処理に対して、それをどこでやるかによって記述がバラバラ。きもい！一つの言語内で全部済ませたいが、まだなしとげられていない。なぜか。
それを成し遂げるための言語はじゅうぶん強力でじゅうぶん抽象的でなければならない。データ構造とアルゴリズムとインターフェース。ソートされてない線形リストから検索するのとRDBにクエリ投げて検索することは、データをさがしてくるという意味で完全に共通だけどあまりにちがいすぎる。ジョエルの人が抽象化はどっかで漏れるって言ってた。手続き型言語、宣言型言語。そもそもあらゆるものを抽象化で一本にまとめられると言う発想はバカ。目指すものはそれであっても、現実的には無理無理カタツムリ、どれだけ簡潔な記述で差異を吸収するかが勝負。LINQは小規模ながら救済の第一歩って感じしない？手続き的/宣言的記法を混在させる戦略ってそれなんてPL/SQL？CoCはもっと広範に使われるべき重要概念だと思う。ソースに書いてあるのに利用されてない情報って案外多いのでは？だから書かなくてもいいこと書かされてる。型推論すりゃわかるだろそこは！察しろよ！データ構造とアルゴリズム。C++というかSTLの設計理念は最強すぎるテンプレ周りの言語仕様含め。やっぱ禿天才だな。
要求を明示的に記述するか否か。ダックタイピングな言語はしない。メソッドが足りなきゃコンパイルエラーか実行エラーかなんかが起こるからわかるよ！みたいな。まあそれ以外の言語でも不完全な指定しかできないけど。インターフェースを使えば一連のメソッドの組があることを明示することはできても、それらがいかなる動作をするのかについては明示/保証できない。DbC使うとちょっと進歩？でも五十歩百歩。テストで補うか(それも五十歩百歩)。Prolog的なアレやHaskell的なアレで厳密にがっつり記述できるように―― しかし不潔な外の世界との界面問題が。(let ( (x 1) ) (+ x 1))が副作用を持たないのは証明可能だが(call-external-function "hoge.dll" foo)がどうなっているかなんて知る由もなく、一番ゆるい推定を適用するしか。つまりあらゆるコードが*きれいな*世界に存在すればいいんだよ！VM（それも純粋関数言語的なアレ)上にOSを構築せよ！BIOSも仮想コードで書いて数学的変形によって等価な機械語を生成すれば完璧じゃないですか！こんにちは美しい世界！！！だが無理