時間が経つにつれて、関数型プログラミングが他のプログラミング言語により多くの影響を及ぼしているように見えます。私は私のAIクラスでPrologを始めていますが、AI以外の分野でのプログラミングを容易にするものがいくつかあるようです。私の質問はこれです：なぜ論理プログラミングが同じように普及しなかったのですか？
このトピックでは、論理プログラミングは有用であるが、そのように証明されなければならないという一般的なコンセンサスに達したようです。役に立たないと思われる理由はありますか？
更新：おそらく私はもう少し明確にする必要があります。私は実際にPrologについて質問していません。ほとんどの実際のアプリケーションにPrologを選択するのが得策ではない理由がわかります。
私が話していることの例をもっと示すために、Pythonのリスト内包/マップ/フィルターを検討してください。これらは明らかに関数型言語の影響を受けています。Pythonのような言語も、関数型言語のように論理プログラミング言語からこれらの種類のものを取り上げていないのはなぜですか？
Prolog を使用してコンピューター サイエンスのクラスでロジック プログラミングについて学ぶときの主なポイントは、熟練した Prolog プログラマーにすることではなく、代わりの形式のプログラミング手法 (データ構造/アルゴリズム) に心を開くことです。以前は考慮していませんでした。
私がコンピュータ サイエンスを勉強し始めたときの私の主張を説明すると、私の工学部ではすべての学生に Pascal でソフトウェア プログラムを書くように要求していましたが、卒業してから一度も Pascal を使ったことがありません。しかし、適切なデータ構造とアルゴリズムを選択することで学んだスキルは、今でも毎日使用しています。
Pascal は私の履歴書に私が知っている言語として表示されていませんが、ソフトウェア エンジニアとしてのトレーニングに役立ちました。その有用性は、現在作成中の Pascal コードの行数だけでは測れません。
ソフトウェアを開発するとき、Prolog コードを 1 行も書いていなくても、参加したこれらの「役に立たない」Prolog または AI クラスで最初に学んだ可能性のある手法を再利用していることに気付くでしょう。 .
テクノロジー (特定のプログラミング言語、特定のソフトウェア ツール/アプリケーション) の有用性を評価することは、単にその実際の使用レベルを評価することではなく、むしろその影響を評価することです。
ロジック プログラミングがエキスパート システム、コンピュータ ゲーム AI、航空管制、およびおそらく他の多くの分野に与えた影響を調べてみると (誰か教えてくれませんか?)、それはロジックとは言えないと思います。プログラミングが流行らない…
私はプログラミングのキャリアの約 4 年間を、顧客の要件に基づいて電話交換機用のハードウェアをプロビジョニングおよび構成するためのルール ベースの「エキスパート システム」に取り組んでいました。
それは大成功を収め、私の知る限り、10 年以上経った今でも日常的に使用されています。しかし、それがどのように機能するかを理解できるプログラマーを見つけることは、システム自体を開発することよりも大きな仕事でした。
手続き型プログラミングや関数型プログラミングの概念を理解できる人の数に比べて、ロジックベースのプログラミングに必要なマインドセットを持っている人はほとんどいないため、このアプローチが広がらない理由だと思います。
論理プログラミング言語は、事実と推論規則を「推論エンジン」に供給するメカニズムを提供します。この推論エンジンは、与えられた事実に規則を適用して新しい事実を生成するように起動されます。特定の論理言語は、その特定の推論エンジンの強さに左右されます。
Prolog の推論エンジンの実装は非常に単純で、非常に非効率的です。同じ問題は、ほとんどの手続き型言語でループ内に多数の if ステートメントを記述するだけで、より効率的に解決できます。
「Configurator」に選択した言語は、より広く知られている OPS5 言語を改良した DEC の RuleWorks でした。これにはRete Algorithmに基づく推論エンジンがあり、手続き型アプローチよりもはるかに効率的です。
DEC が HP に飲み込まれた Compaq に飲み込まれたため、RuleWorks はオープン ソースになり、この Web ページ から入手できます。
そのような技術は、他の方法では扱いにくいさまざまな問題を解決するのに非常に効果的である可能性があるため、このような技術にこれ以上関心がないのは残念です。
プレーンな Prolog に対する私の印象は、おもちゃの言語だということです。論理プログラミングが役に立たないというわけではありません。たとえば、Twelfでは、単純なプログラミング言語のセマンティクスを非常に簡単に宣言し、宣言をインタープリターとして機能させることができます。また、 λPrologについていくつか良いことを聞きました。
論理プログラミング言語を汎用言語として使用しようとする際の問題は、一部のタスクが概念にうまく適合しないことです。ロジック プログラミング機能は、命令型および関数型の構造を持つ言語に組み込む必要があると思います。そのような言語が少なくとも 1 つあります: Ozですが、まだ試していません。
編集: しばらくの間、試してみたいと思っていたアイデアが 1 つあります。リレーショナル データベースを Prolog にアトムとしてフィードし、それを使用して SQL の代わりにクエリを実行することです。SQLよりも大幅に改善されると感じています。
私は最近、ゲーム デザイン AI 研究プロジェクト (ティーザー ビデオ!) で大量のロジック プログラミングを使用しましたが、ロジックを多用するプロジェクトの少なくとも半分は、基本的なゲーム エンジンを実装する関数型または命令型の Scala コードでした。 プログラミングのポイントは、私がそのようなことを主張する場合、あなたが何を望んでいるかについてのマシンの理解をあなた自身のものと同期させることです.終わり。それらの愚かな機械は常に文字通りです...
ロジック プログラミングは、それが伝統的な演繹的なプロローグ スタイルのものであろうと、よりエキゾチックな帰納的ロジック プログラミングや回答セット プログラミングのフレーバーであろうと、命令型の知識を簡単に伝達できるという犠牲を払って、問題のいくつかのフレーバーに大きなレバレッジを与えます (実世界のアプリのどこかで常に必要です)。対話型アプリケーションの懸念により、命令的な知識を表現する際の生産性がわずかに損なわれることさえ許容できない場合があります。ロジック プログラミング スタイルでゲーム エンジン全体を記述することは、常に悪い考えです (同様に、同じ計算能力を持つ perl 互換の正規表現を使用して試す場合も同様です)。ハイブリッド言語 (またはロジック インタープリターを簡単に埋め込むことができる言語) では、両方の長所を活かすことができます (私はjTrologを使用して Prolog を私の Scala エンジンに組み込み、一種のマルチパラダイム voltron を形成します)。
論理プログラミングは確かにもっと人気があり、よく理解される可能性があると思いますが、ある意味では、純粋な論理プログラミングは、「キャッチアップ」という点で SQL や正規表現よりもはるかに優れているとは言えません。命令的な表現力 (理想的には、重要でない詳細で迷子にならないようにします)。この説明は、関数型プログラミングにもほぼ同じように当てはまります。私はロジック プログラミングが大好きですが、それはいつ使用するかを選択できるからです。今後の最善の方法は、一貫性のある適切に設計された方法でその選択肢を提示するハイブリッド言語のようです。
私がPrologで最初に抱えた問題は、それが論理プログラミング言語ではないということです。これには、「true」、「false」、および「do n't know」の3値論理がなく、後者の2つが混同されています。つまり、2つの真理値は実際には「表示可能」と「表示不可」です。これは、論理的推論のかなり基本的な「ない」という考えに関する実際の問題をPrologに与えます。
通常の論理では、その否定を反証することによって命題を証明することは完全に合理的であり、これは「帰謬法」と呼ばれます。（はい、それを使用せずに数学を再構築しようとした人がいますが、それは少し難解になっています。）これはPrologでは機能しません。
そのため、Prologでクラスプロジェクトを行ったとき、プログラミングロジックだと思ったら困りました。私はいつも実際の否定を必要とする何かをすることになります。他の人はそうしないかもしれませんが、私はそれをパターンマッチング言語と考えてしまい、プロジェクトを完了するのにほとんど苦労しませんでした。
プログラマーが物事を書き、実際に結果に依存できる真の論理ベースの言語を持つことは不可能です。一階述語論理（つまり、変数を含む論理、真または偽の関数、「and」、「or」、「not」、「for all」、および「thereexists」）は、明確に決定不可能です。（結局のところ、すべての可能な定理を機械的に生成するのではなく、数学者にコーヒーを注ぎ続ける理由があります。）プログラマーがすでに知っている場合でも、特定の命題が証明されるかどうかをプログラマーが事前に知る方法はありません。それは真か偽かです。
編集：私はまた、条項を適切に順序付けることの決定的な必要性を忘れました。論理的には、書き留める順序は重要ではありません。Prologでは、ロジックベースの言語として扱うのをやめるまで、無限ループに入り続けました。繰り返しになりますが、パターンマッチング言語としていくつかの優れた機能がありますが、それは論理ではなく、言語のワントリックポニーのように見えました。YMMVですが、他の人も私に同意しているようです。
私たちがプロローグを学んだとき (プログラミング言語のクラスでほんの数週間だったので、私はほとんど専門家ではありません)、その教授は、あなたの定義によっては、論理プログラミングは実際にはプログラミングではないかもしれないと指摘しました。
私たちがプログラミングと言うとき、通常は「一連のタスクや命令をコンピューターに発行すること」のようなものを指します。それが、命令型または関数型プログラミング言語が行うことです。これは、すべての「本物の」プログラミング言語が行うことです。プロローグ、または論理プログラミングは、実際にはそうしません。それはSQLに似ています。コンピューターに多くの質問をすることができます。以前に入力したデータに基づいて、その能力を最大限に発揮しますが、他のプログラミング パラダイムとは異なり、コンピューターに何をすべきかを実際に指示しているわけではありません。
これは非常に専門的であり、汎用プログラミングには適していません。そして、それが専門とするものは、しばしば必要とされません。
一方、関数型プログラミングは間違いなく汎用プログラミングであり、何にでも使用でき、大きな問題はありません。これが、後者が人気を博している理由であり、ロジックプログラミングはそうではありません. おもう... ：）
関数型プログラミングは、マルチスレッド プログラミングに適用するといくつかの重要な利点があるため、より一般的になりつつあります。また、マルチコア プロセッサに移行するにつれて、マルチスレッド プログラミングがますます重要になるでしょう。
私自身のPrologの経験から、特定のタスクには非常に適していますが、汎用プログラミング言語としては、他の多くの言語ほど柔軟ではないと思います。
大学のAIクラスでPrologを受講したとき、Prologは非常に魅力的でしたが、今日AI以外で使用する状況はほんの一握りしか考えられません。そして、そのような状況でも、私はそれを使用したくありません。最終的にPrologを「入手」するのに長い時間がかかりました。そうすると、それは素晴らしいと思いましたが、すぐに有用性の範囲が限られていることに気づきました。
それでも、別の方法でプログラミングに取り組むことを学ぶ以外の理由がなければ、それを学ぶことを強くお勧めします。多くの異なる視点から問題を見ることができることは、絶対にあなたをより良いプログラマーにします。
Prolog が特定のタスクに非常に適していることは事実ですが、私の 11 年間の実務経験では、Prolog が最適なソリューションであるという問題に遭遇したことはありません。Prolog が理想的であるような問題は非常にまれです。
これは、ジョブに適切なツールを使用する標準的なケースです。特定の状況でロジック プログラミングを目にすることがあります。それらは通常、ルールベース システムやエキスパート システムなどと呼ばれます。
計算可能性理論コースでは、これらの汎用言語はすべて (数学的な観点から) 事実上同等であるという事実について説明します。ただし、プロトタイピングと長期的な開発はまったく別の領域です。したがって、ルールベースのシステムでは、Prolog などを使用してルールセットを作成し (それがうまく機能する場合)、後で配信プラットフォーム (Java など) に最終的なシステムを実装することは十分に可能です。
ところで、私はいつも、ほぼすべてに対する Prolog の答えが「いいえ」である方法が好きでした。
このディスカッションスレッドには、真に宣言型であり（ステートメントは任意の順序で作成できます）、SQLの代わりにデータベースをクエリするために使用できる論理プログラミング言語の呼び出しがあります。
データログはあなたが探しているものです。たとえば、データ統合、セキュリティアプリケーション、プログラム分析で使用されます。
AIクラスで Prolog を開始していることがヒントになるはずです。AIもあまり普及していません。
1980 年に教授に AI の重要な使用法を示すように要求したことを覚えています (わかりました、「嘲笑」はより正確な用語ですが、当時の私は若かったです)。彼は当時それを行うことができませんでした。当時彼が絶賛していた AI のアプリケーションの約 10 分の 1 です。
プロローグも同じかもしれません。Prolog の経験を求めている会社を最後に見たのはいつか覚えていません。たぶん一度もなかったかもしれませんし、あるいは私がそれを見て無視したのかもしれません。