まずは、本の紹介から。
Language selection (17.1 : Criteria)
前略
Professional software engineers should instead base their decisions on relevant technical and economic criteria, such as the following.
- Scale:(略)
- Modularity:(略)
- Reusability:(略)
- Portability:(略)
- Level:(略)
- Reliability:(略)
- Efficiency:(略)
- Readability:(略)
- Data modeling:(略)
- Process modeling:(略)
- Availability of compilers and tools:(略)
- Familiarity:(略)
なんだか「略」ばかりで申し訳ないが、引用の範囲を越えてしまってもしょうがないので。ということで、この本は 12 種類の項目でプログラミング言語の選び方を分類している。5 番めの "Level" ってのが一般的な単語なので、補足すると、この本では、アセンブラは低レベル、いわゆる高級言語と呼ばれている言語は高レベル、と称している。その他の項目については、単語から推測できると思う。興味をお持ちの方は手に取って読んでいただきたい。まあ、こういった観点から、プログラミング言語を分類した上で、自分の好みの言語を決めるという方法はありだと思う。
ただ、この本はちと古い(May 28, 2004)。Amazon.co.jp の読者レビューでは5つ星だが、Amazon.comでは酷評されている。いけがみの感想では、後者の酷評が的を射ているような気がして、ようするに本書の対象読者は、プログラミング言語の研究者ではなくて、普通のプログラマ向けに書かれているように思われる。なので、"Missing information and factual errors", "No really theory!" といったレビューは残念ながら当たっている...
ぐさっ
[それは痛いです - ときどきの雑記帳 i戦士篇より引用]
ええと、木村さんときどきの雑記帳はよく読んでいます。有益なリンクが多いので助かります。">*1を刺すつもりはなかったんだけど。言葉足らずでどうもすみません。
世の中、プログラミング言語が満ちあふれているので (Fortran しか無かった頃から比べれば恵まれた時代である)、言語の仕様をすべて理解しようとする前に、いくつかの観点から自分の必要な言語を決めればいいのではないかな、というのが 前回のエントリで言いたかったことです。もう一つ言いたかったことは、メタプログラミングという技法を取得してしまえば、いくつもの言語仕様(特に syntax sugar)を頭の中に詰め込まなくても大丈夫、ということ。つまり、プログラミング言語を一つ習得すれば、もう一つのプログラミング言語の「プログラム」を生成する「プログラム」を書くことはそんなに難しくないということです。もちろん、対象の言語の複雑さにもよるんだけど、たとえば最近流行りの HogeScript なんかは、簡単な仕様ですので、「手で書く」ことなしにプログラムを生成することができます。Haskell から JavaScript を生成とかね。SQL を吐くプログラムとかも、ある意味メタプログラミングだと言える(と思う)。
プログラミング言語の最適な選び方なんて無いでしょうけど、オブジェクト指向言語と関数型言語の二つのうちどっちを選ぶか、は、わかりやすい指標があるのではないかな。プログラムを構成する部品と機能のどちらが種類が多いか。これで決められると思います。
たとえば、GUI は部品のほうが機能よりも多い。GUI では Window に満ちあふれていて (Window, 警告 Panel, ...)、 Window そのものは plane View + title bar + close button + α(最大化ボタン、最小化ボタンなど)からできているわけです。これは、オブジェクト指向のほうが直感的にプログラムを書くことができる。というのは、オブジェクト指向の継承とインスタンスという概念によるところが大きい(というのがいけがみの理解)。一方、関数型言語で GUI ライブラリを書こうとすると、polymorphic type や Haskell の type class 、phantom type みたいな特殊な技法があったほうが便利で、素直には書きにくいのです。ボタンを押したときのイベント処理も、オブジェクト指向言語では移譲という概念がありますが、関数型言語だと継続とか、動的型キャストとか、いけがみにとっては heavy-weight な機能が必要に思える。
その逆に、テキストエディタのような、部品よりも機能が多いソフトウエアでは、関数型言語が有利です。テキストエディタは、文字列の処理や highlight などの機能がたくさんある一方、GUI のような部品は多くありません。このようなソフトウエアをオブジェクト指向言語で作るとどのようなことになるでしょうか。たとえば、MacOSX のテキストエディタは NSTextView クラスを使っているのだけれど、NSTextView クラスはメソッドの個数が約160個もあるのです。さらに、NSTextView クラスの継承関係は NSTextView : NSText : NSView : NSResponder : NSObject ということになっていて、メソッドの総数はどれだけあるのやら。NSTextView のメソッドの一つは (void *)setBackgroundColor:(NSColor *)aColor ですが、このように、機能一つにメソッドが対応するので、結果的にクラスが大きくなってしまうわけです。当たり前のことですけど。その点、関数型言語でしたら、(Haskell の例にしますが) setBackGroundColor :: (ApplicationStateMonad m, View a) => a -> Color -> m () になるでしょう。これ一つで充分です。Emacs が関数型言語 Lisp を採用したのもそういった視点からだと思います。EmacsLisp が名前空間をめちゃくちゃにしてしまうのは困ったものですが...
現状では、どちらの陣営も得手不得手をわかっていて、お互いの良いところを取り入れようとしています。無名関数を持つオブジェクト指向言語は増えてきましたし、一方で、関数型言語にもオブジェクト指向言語の機能を取り入れる試みがなされています。ごっちゃまぜとしては、先日聞いた Scala とか。
論理型言語は、立ち位置がちょっと特殊で、うまく当てはまる問題に適用すると、どの言語よりも楽に記述できる。Prolog は知っていて損はありません。Curryは……触ってないので評価できない。非決定的な振る舞いとか、どういう場面で使ったらいいんだろうか...モデル記述?
まとめると、プログラミング言語は多くあれども、特徴や文法よりも、まず先に、「そのプログラミング言語がどのようなプログラムを作るのに便利であると主張しているのか」を調べるほうが先だと思うのです。言語の信者は当然「素晴らしさ」を強調しますが（『美しい』とか『principle of least astonishment』とか、そういう指標の無い基準を持ち出してきて笑わせんな）、そんなもん信用せずに、自分でプログラムを書いてみて、自分の好みを確かめるのがいいのではないでしょうか。あと、バッドノウハウは勘弁な。最後に、全く関係ないけど C は最高である。C は素晴らしい。C だけ知っていれば充分である。
以下、気になっている本：
*1 ときどきの雑記帳
はよく読んでいます。有益なリンクが多いので助かります。