プログラミング言語比較 知識処理言語の野望とは


とりあえず、意志の詳細分析は前回で終わり。感情もあれ以上は作りながら考える必要があるので、今後は実装フェーズ。すると、多分、誰も興味を持たないような話題になってしまうのだが。。そもそもコンピューター言語の比較って、最低でもCとかの手続き型と、Lispに代表される関数型を触った事がある人じゃないと、スタートラインに立てないから。

これだけIT系企業が増えても関数型言語をやったことあるのは、情報系出身の中でも一部だろうなぁ。それに加えてPrologに代表される論理型言語までやったことがある人って、うーん日本に毎年1000人以下だと思う。

この「コンピュータプログラミングの概念・技法・モデル」(以下、青本と略)が複数のコンピューター言語を比較するのには一番良い市販本だと思う。

後、大事な情報としてはポールグレアムの分類があって、整理したら以下になる(引用はこちら)
Algolが解決: アセンブリ言語は機械語に近すぎる。
 →Pascalが解決: Algolにはデータ型の種類が足りない。
 →Simulaが解決: Algolはシミュレーションにはそれほど向いてない。
  →Smalltalkが解決: Simulaには実はオブジェクトでないものもある。

Fortranが解決: アセンブリ言語は機械語に近すぎる。
 →Cobolが解決: Fortranはおっかない。
 →PL/1が解決: Fortranにはデータ型の種類が足りない。
 →Basicが解決: Fortranはおっかない。
 →APLが解決: Fortranは配列操作がイマイチだ。
  →Jが解決: APLは独自の文字を要求する。

Adaが解決: 今までの言語はすべて何かが抜けている。

Cが解決: アセンブリ言語は機械語に近すぎる。
 →C++が解決: C言語だって機械語に近すぎる。
  →Javaが解決: C++はやっつけ仕事だ。それにマイクロソフトは私たちをやっつけるつもりだ。
   →C#が解決: Javaはサンに支配されている。

Lispが解決: チューリングマシンではプログラムがまともに書けない。
 →Schemeが解決: MacLispはその場しのぎだ。
  →Tが解決: Schemeにはライブラリがない。
  →Dylanが解決: Schemeにはライブラリがないし、Lispの文法はおっかない。
 →Common Lispが解決: Lispには方言が多すぎる。

Perlが解決: シェルスクリプトやawkやsedは、プログラミング言語ほどには良くない。
 →Pythonが解決: Perlはその場しのぎだ。
  →Rubyが解決: Perlはその場しのぎだし、Lispの文法はおっかない。

Prologが解決: そもそもプログラミングなんて論理みたいなものと言えるほど十分じゃない。


この青本は並列性とか知識処理と関係ない(と一応おもってる)内容もあるので、知識処理に絞って考察していきます。結局、以下の二つの分類がスタート。

.團絅関数型言語と手続き型言語の違い ⇒状態をもつか/全て引数で表現できてるか
▲團絅関数型言語と論理型言語の違い  ⇒手続き(メソッド)を逆向きで使えるか

この内容をシンプルに言ってるので、非常に分かりやすい本だと思う。けど、その先を書いてないの不満。手続き型(この本では命令型と読んでるが)よりも関数型言語の方が好ましいのは、影響を与える因子が全て引数になっているから。すると、この条件は知識処理的にはかなり対象の分析が終わった状態なんだよね。

たとえば、南太平洋の島にいってその民族を分析している。彼らは祭りをたまに行うが、その周期がわからない。この場合、祭りの周期を関数型として表現できるのは、ものすごく分析が終わった後だから。関数として表現できる途中段階の状態を表現する能力が言語として必要になるんだよね。

一部の関数型は高階によって関数自体を変更できる。でも、その前に大事なポイントして、引数も二つに分類する視点だと思う。

○「単なるオペランドとしての引数」
○「分岐に関連する引数」
ここら辺を概念的に別に扱う仕組みって無いよね。知識処理としてはここがポイントだと思うのだが。結局さ、「新たな事実が判明する」→「手続きを変える」→「場合分け(分岐)が増える」の流れだから。単にオペランドが変わるだけなら、手続き内の定数を引数化するだけ。


△竜娶きで使えるというのは、「メソッド(A,B)→C」という記述方法を、「メソッド(A,B,C)」と答えまで引数化して記述することで、メソッド(1,2)→3という処理でなく、メソッド(A,2,3)という逆向きの呼び出しが自然に行える。このためには、全検索する仕組みが内部で必要。その検索を効率化するために制約プログラミングがあるという、青本の意見は非常にクリアで分かりやすい。

制約プログラミングの考え方自体は非常に面白いし、僕の修士1年はずっと制約プログラミングの研究だったけど、はっきり言って無駄だった。そもそもこの本では「論理型言語は非常に応用がさかん」と書いているけど、これって研究者ベースで見た場合であって、実際のビジネス視点で見れば、殆ど使われてないような。

ポールグレアムの以下の文章は個人的には凄く納得した(こちらから引用)。
最も顕著な例はProlog流のパターンマッチングなのだが、『追加』や『削除』などにしか有効ではなかった。Prologはappendを書くためにはすばらしい言語だが、その以上のことになるとダメになる。

論理型言語がダメなんじゃなくて、知識処理を論理でやろうとする思想がダメ。なぜって、論理は関数型ほどではないけど、やっぱりまだ厳しい条件だから。知識処理言語の一番のポイントって、論理じゃないんだよ。それを論理だと勘違いしたのが西洋人のミスだと、そろそろはっきり言った方がいい。論理が使えるのは最後の方なんだって。

★|亮韻鮗集する
★⊆集した知識の整合性を維持する
★収集した知識を組あわせて推論できる

この3つ。これらを別にやる。ここが論理型言語の隠れた野望であり、知識処理に必須の内容。その環境で必要な全ての知識が判明しているなら、知識処理って必要ないの! と訴えておこう。

今後、HHAIの知識処理部分はこの方針で作っていきます。






コメント
コメントする








   
この記事のトラックバックURL
トラックバック

categories

links

recent comment

profile

search this site.

others

mobile

qrcode

powered

みんなのブログポータル JUGEM