プログラミングがあいまいで曖昧なアイデアを表現する良い方法である理由

ハロルド・アベルソンとジェラルド・ジェイ・サスマンによる注目すべき本「コンピュータプログラムの構造と解釈」（SICP）の初版の序文には、マーヴィン・ミンスキーの記事「なぜプログラミングはあいまいで曖昧に定式化されたアイデアを表現するのに適しているのか」からの引用があります。引用は短く完全です。ロシア語の出版物は私に出くわしませんでした。

以下では、この記事の翻訳に慣れることができます。かなり前に書かれましたが、Marvin Minskyのような人の考えを知ることはまだ興味深いです 。元の記事はここにあります 。



この記事は、ビジュアルコミッティーブックスの「Design and Planning II-Computers in Design and Communication」（Martin KrampenおよびPeter Seitz編）に掲載された章のわずかに編集されたバージョンです。 、ヘイスティングスハウス出版社、ニューヨーク、1967年。）

コンピュータはプログラムされたものだけを実行できるという一般に受け入れられ広く普及した信念があります。 この誤った判断は、フォームとコンテンツの間に存在する混乱に基づいています。 厳密な文法は、プロセスの厳密な説明を意味するものではありません。 プログラマーはコンピューターの文法の規則に従って非常に正確でなければなりませんが、これらの規則を使用して表現したいコンテンツは自由であり、何にも限定されません。 そして、文法の厳格さはコンピューターによるものではなく、それを使用するプログラマーによるものです。 プログラマーは、自分の考えを非常に正確に定式化する必要さえありません。彼は、ある範囲のコンピューターの解答を頭の中に持っているかもしれません。 プログラマーは、コンピューターを特定のプロセスに制限する必要はありません。 疑いの重みのもとで、彼はコンピューターに新しいプロセスを生成するように依頼するか、特定の選択ルールを提示し、コンピューターに選択を「助言」することができます。 したがって、コンピューターをプログラムする必要がなく、明確に正確に表現する必要があります。

ここで示されている理由は、「デザイン」ではなく、コンピューターが作業にどの程度役立つかということではありません。 多くの理由で、人々は通常これらの機会を過小評価しています。 そもそも、1つの間違いについて警告したいと思います。彼が状況を完全に理解していると信じている多くの人のように、「中程度の」立場を取るべきではありません。 サイエンスフィクションの作家、あらゆる分野の科学者、経済学者、アナリスト、心理学者、さらには論理学者までもが繰り返し、コンピューターが本当に考えられないことを皆に納得させようとします。 「機械が人間のように考えることができると想定すべきではありません。機械はプログラムが提供することしかできないので、独創的で創造的ではありません。」 私たちは皆、似たようなことを聞​​いたことがあり、私たちのほとんどはこの観点に同意します。



人文科学者がなぜ思考プロセスのあいまいな性質についてりたがるのかを理解するのは簡単です。なぜなら、そのようなあいまいさと人間の思考のユニークな性質との関係について誤った結論を出すのは簡単だからです。 しかし、ここでは結論は重要ではありません。 この議論の全体的な誤Theは、非常に明確に定義されたタスクの範囲を超えて何かを行うコンピュータープログラムを作成することは不可能であるという広範な信念にあります。 この信念は、科学者（さらには「コンピューター科学者」）と人文科学の両方によって広く推進されています。



通常、コンピューターの制限について語られることはすべて、次のような一般的な形式を取ります。「コンピューターは作成できません。 彼は言われたことだけをすることができます。 プロセスが非常に正確に定式化されていないと、コンピューターはそれを実行できません。」 ある意味ではこれは正しいですが、別の場合は絶対に間違っています。 理由を説明する前に、コンピューターの出現のずっと前に、悪魔についても同じことが言われていたことに注目するのは興味深いことです。悪魔は創造者になり得る唯一の人間です。



Scientific Americanの1966年9月号で、3つのプログラムについて説明しました。マスターレベルでのArthur Samuelのドラフトプログラム。 幾何学図形間の類推を認識することでかなり良いレベルで知性評価タスクを解決することを可能にしたThomas EvansプログラムANALOGYと、非公式言語で表現された上級クラスの代数問題を解決するD. BorborveプログラムSTUDENT：



, , , . 24 , ?







このプログラムはいくつかの問題を解決しますが、すべてではありません。 その記事では、より多様な知的開発の方向で作業を継続するために、タスクをさらに先に進むように設定しました。 しかし、私の目的では、現在の状態であっても、これらのプログラムは優れた例として役立ちます。非常に限られた範囲のタスクで動作しますが、すべての人にとって便利なこの古い神話を破壊するのに十分なことをすでに行っています



古い視点は、プログラムは、「特定の」各特定の状況で何をすべきかを明確に示す一連の厳格なルールであるということです。 これは、プログラミングの初心者を説得するため、または初心者によって書かれたプログラムを分析するための非常に便利な視点です。 ただし、より複雑なプロセスの場合（ある意味では「絶対に」真実ですが）、「家は単なる建築材料の構造物」または「本は単なる単語の連鎖」と言うのも正しいでしょう。 そして真実：1967年1月1日のComputer Reviews 8、1で作成されたScientific Americanの記事のレビューでは、これらのプログラムは「辞書検索、検索と比較機能のシーケンス、および並べ替えと結合操作」で構成されています。 。

ロジックとシステム

まず、優れた論理学者や哲学者の意見に基づいた1つの声明を議論することから始めましょう。 シーケンシャル論理システムを証明するための定理には、「発見プロセスを完全に機械化することは不可能であるため、マシンよりも常に有利である」という結果が得られると言われています。 ほとんどすべての読者がゲーデルの定理を聞いたことがあると思います。 ほとんどの人は、主張された結論についても聞いています。 しかし、これは不注意な技術的観察に基づいているため、論理的な結論ではありません。 一般的に問題解決に適用できる場合、ゲーデルの定理は一貫した論理システムにのみ適用されます。 人々はそれほど一貫していないので、どんな種類の恥ずかしさを感じ、そのような原則に従って機械を作ることに自分自身を制限する理由はありません。 代わりに、すでに行われている実際の判断の矛盾を許容できるマシンを作成できます。 これを行うには、矛盾を解決するための一連のルール、競合する判断から選択するための優先順位のスケールなどを追加します。 このようなスキームの簡単な例は、1964年にマサチューセッツ工科大学で擁護したバートラムラファエルの博士論文に記載されています。 このようなプログラムとの対話の例を次に示します。

 すべての人は人です 
 （私は理解しています）
 フィンガー-パートオブザハンド
 （私は理解しています）
各人には2つの手があります
 （このオファーは不確かです。修理してください）
 誰にも2つの手があります
 （私は理解しています）
 Johnジョンは何本の指を持っていますか？
 （指がジョンの一部であるかどうかはわかりません）
 ジョン-ボーイ
 （私は理解しています）
 Johnジョンは何本の指を持っていますか？
 （手にたくさんの指）
 EVERすべての手指5本
 （私は理解しています）
 Johnジョンは何本の指を持っていますか？
 （回答-10）
 Jジョンはどのような車を持っていますか？
 （このオファーは不確かです。修理してください）
 US米国大統領は誰ですか？
 （特定されていない判決の形式）
 TABLEテーブルから出てくるだけの男の子
 （G02840-表）
 （私は理解しています）
 ランプ-テーブルから左
 （G02841-ランプ）
 （上記の判断は不可能です）
 テーブル-議長の権利
 （G02842-椅子）
 （私は理解しています）
相対的な個人性とは何ですか？
 （左右などを注文）
 （椅子-男の子-テーブル） 

ラファエルの質問に対する知識と回答を収集するシステムは、一般原則と矛盾する場合に個々の事実がどのように最優先されるかを示しています。 もちろん、このような「排除の原則」は矛盾を解決する非常に単純化された方法であり、一般性の観点から判断に明確な違いがある場合にのみ使用できます。 それらが同じレベルにある場合、この例に見られるように、プログラムは後の判断を単に拒否します：

  EVERすべての手指5本
 （私は理解しています）
 男には2つの手があります 
 （私は理解しています）
 ボーイ-男 
 （私は理解しています）
 TOM-BOY
 （私は理解しています）
 ディック-ボーイ 
 （私は理解しています）
 ハリー-ボーイ 
 （私は理解しています）
 TOMには9つの指があります
 （この判決は概念的なものですが、私は（HAS）を意味します（一部として））
 （私は理解しています）
 ディックには一つの手がある
 （この判決は概念的なものですが、私は（HAS）を意味します（一部として））
 （私は理解しています）
 OMどのくらいの指がトムをしますか？
 （回答-9）
 DIディックはどのように機能しますか？
 （回答-5） 
 HARどのくらいの指がハリーをしますか？
 （回答-10） 
 Jジョーはどのような指をしますか？
 （指がジョーの一部であるかどうかはわかりません） 

もちろん、ラファエロは優先順位設定の別のルールを書くことができます。 ところで、「この文はあいまいです...」というプログラムの判断は、「持っている」という言葉が「一部として持っている」または「所有している」のいずれかを意味する可能性を指します。 Raphaelのプログラムは通常、特定の物を所有している、または特定の物の一部であるなど既に知られているオブジェクトの研究について正しい仮定を立てます。 これについては、以下で詳しく説明します。 ラファエルは、このような「コンテキスト」の決定は、より一般的なアイデアを示すことによって、または以前に存在した「ジャスト」アプローチの代わりにプログラムの異なるより堅牢なビューを示すことによってプログラムできることを明確に示しました。 したがって、プログラムについて推論するための最良の方法のいくつかを説明しようとします。

（1）従うべき指示のシーケンスとしてのプログラム。

最も一般的で単純な観点：コンピュータープログラムは、特定のデータに基づいて実行される一連の明確な操作です。 簡単なプログラム例を見てみましょう。Xが入力情報として与えられた数値であると仮定します。

 START: SET R = 1 LOOP: SET S = X/R SET T=R+S SET R = T/2 SET U = R x R SET V = X - U IF |V| > .001, GO TO LOOP ELSE PRINT V
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Isaac Newtonに起因するこのプログラムは、Xの平方根のおおよその値を計算します。プログラムの各行では、現在の状況と次に来るものが完全に明確です。 もちろん、そのような状況のシーケンスがRの許容値とすべての計算の終わりにすぐにつながることを証明するために、数学的分析が必要です。 したがって、これらの判断を一連の手順と見なしても害はありません。 「GO TO」コマンドは、「メインループ」のいくつかのコピーの非常に短いバージョンと考えることができます。 もちろん、分析が完了するまで、プログラムは有用であるが理解できないアイデアの表現と見なすことができます。

（2）裁判所としてのプログラム

ラファエルのプログラムでは、「持っている」という言葉が「所有している」か「一部として持っている」かを判断する必要があります。

  ジョン-男
 （私は理解しています）
 ディック-男
 （私は理解しています）
 チェーン-バイクの一部
 （私は理解しています）
 チェーンソーにはチェーンがあります
 （この判決は概念的なものですが、私は（HAS）を意味します（一部として））
 （私は理解しています）
 ジョンにはチェーンがある 
 （私は理解しています）
 ディックには椅子がある
 （この判決は概念的なものですが、私は（HAS）を意味します（一部として））
 時計時計にはチェーンがあります
 （このオファーは不確かです。改革してください） 

タスクは、表明されるとすぐに、プログラムのその部分に転送されます。この部分では、以前に行われたすべてのレビューを実行できます。 このようなサブルーチンは、次のことに基づいて決定を行います。

1. yは他のオブジェクトの一部として知られていますか？ または、何かの一部であるグループのメンバーですか？
2. uは誰かに属している、または誰かに属しているグループのメンバーであることがわかっていますか？
3. 条項（1）または（2）のいずれかが正しい場合、適切な選択を行います。 適切なオプションがない場合は、停止して詳細情報を収集します。 両方の記述が真である場合、パラグラフ（4）のオプションを検討してください。 （したがって、プログラムは、以前に取得した情報が世界の「モデル」にどのように含まれていたかの証拠を使用します。）
4. この点に到達すると、uはすでに何かの一部であり、すでに誰かに属していることになります。 より正確なテストが必要です。

U1とU2を、それぞれ質問（1）と（2）への回答に存在する「何か」または「何らかのシステム」とします。 それらはyに依存します。 質問：xはU1とU2のメンバーまたはサブジェクトですか？ どのオプションも適合しない場合は、停止します。 オプションの1つが正しい場合、対応する結果、「part」または「belongs」を選択します。 両方のオプションが正しい場合、停止して詳細情報を収集します。 ラファエルは言う：

「これらの基準は非常に単純ですが、プログラムが曖昧な単語を含むさまざまな文の特定の目的のためにかなり合理的な決定を下せるようにするのに十分です」。 もちろん、たとえば、上記のダイアログで「ジョンはチェーンを持っている」という文の前にある「ディックはチェーンを持っている」という文の場合、プログラムはミスを犯す可能性があります。 しかし、人が同じような状況で新しい世界に出会うと、きっと同じような間違いをするでしょう。 事実は、文の説明に単語を記述することによって文のあいまいさの問題を解決することが可能であることです。これは、以前に与えられた明確な文を通して自動的に作成できます。

したがって、プログラムは、以前に収集された情報を検索し、xとyがどのように接続されているか、およびそれらがまったく接続されているかどうかを見つけようとします。 プログラムのこの「部分」は、一種の小さな裁判所として、または証拠と証言の収集と分析として認識できます。 問題を解決するために以前に指定されたシーケンスのフレームワーク内で、単純な方法で手順としてそれを認識するべきではありません。 むしろ、プログラムが矛盾またはあいまいになったときを告げることができる控訴裁判所です。 さて、必要な場合にそれぞれが他の人に助けを求めることができるような多数のそのような船で大きなプログラムを書いているとき、プログラムを「シーケンス」と考えることはまったく無意味です。 プログラマ自身がそのような「アピール」を可能にする「正当な」原則を策定したとしても、そのようなプロセスが相互作用を必要とするプログラムの過程でいつどこで完全に理解できないかもしれません。 個々の「裁判所」については、彼はそのような相互作用につながる可能性のある状況について断片的な考えしか持っていません。 要するに、初心者レベルを完了したプログラマーは、「一連の命令」を書くだけではありません。 彼らは、小さなグループまたはプロセスからの個々のケースについて書いています。 しかし、その相互作用のすべての詳細を事前に完全に想像できることはめったにありません。 結局、コンピューターはまさにこれが目的です。

（3）ヒント集としてのプログラム

おびえた人文科学だけでなく、ほとんどのコンピューター「専門家」によって共有されている誤解があります;それは、プログラミングが本質的にフォームとコンテンツの間の基本的な混乱に基づく機能の正確で明確な環境であると言います。 詩人に14行のスタンザを書くタスクが与えられた場合、これはプロセスをより正確にしたものではなかったでしょう。 作曲家がスケールの12ステップすべてを使用する場合、これはフォーム全体を制限しません。 設計者が4次のサーフェスのみを使用する必要がある場合、誰も気付かないでしょう！ したがって、（古い）プログラミング言語の厳密な文法がプロセスの記述の正確さに貢献するような論争でそのような一致を観察することは、単にばかげています。 実際、プログラムがまったく機能するためには、コンピュータの文法（構文）のルールを非常に注意深く守る必要があります。 スペルミスや句読点のエラーは許可されていません！ しかし、これがあなたのプログラムが何をするかを明確に理解するのに役立つと言うのは間違っています。 FORTRAN言語では、プログラムが既に記述されたプロセスを参照するようにしたい場合、「GO TO」固定コマンドのいずれかを使用する必要があります。 「使用」（「使用」）や「GET TO」（「PROCEED ON TO」）などとは言えません。 この場合の構文は非常に厳密です。 しかし、ほとんど何でも「GO」できるので、コンテンツは無料のままです。



そのような厳しさはコンピューターによるものであると仮定するのはさらに間違っています！ 言語を定義したプログラマーによるものです！ BobrovのSTUDENTプログラムでは、必要に応じて「USE（「USE」）を常に入力（「GO TO」）と入力し、単純な状況では「GO」の代わりに「USE」を使用できます。 もちろん、これは柔軟性の単純な例ですが、ほとんどの人が受け入れないのはまさにこの考えです。FORTRAN言語の厳密さと明確さは、もしあれば、厳密な偏見によるものであり、事実の厳密さによるものではありません！



モダンでより柔軟なシステムの例として、Warren Teitelman（ミシガン工科大学の博士論文、1966年）によって開発されたPILOTプログラミング言語を取り上げます。 ） 多くの場合、「プログラム」ではなく「アドバイス」と呼ぶことができます。 これらはケース間で記述され、通常、デフォルトの状況に応じて、または以前のアドバイスの結果として使用されます。 例は、 「宣教師と共食いについて」というよく知られている謎のような問題を解決するためのプログラムを開発するときに導入された次の命題です 。



, m – -1, c – -2 (- m) (- c ), . ( .)







このプログラムはヒューリスティックな検索であり、さまざまなパターンと動きを試し、前進できるものを好み、人々が川を渡るのを助けます。 Teitelmanは最初に基本プログラムを作成します。 しかし、宣教師は食べられており、上記の「アドバイス」は、「前方への動きを測定するプログラムの一部を変更して動きを拒否し、その後、不平等な数の宣教師と人食い人が川のほとりに残る」ことを推奨しています。 タイテルマンによると：

プロモーションでは、同時に「食べる」という条件が作成されます。 すべての人食い人が1つの銀行にあり、宣教師が他の銀行にいるとき、彼らは3対0の比率で宣教師の数を超えているので、数えて比較するだけでは十分ではありません。

ただし、構文上の制限を減らすことは重要ではありません。 ポイントは、プログラムに加えられた変更の「助言」の性質にあります。 「前進」についての判断は、この「前進」がどのように実行され、正確に「プログラム」のどこに位置するかを知らなくても行うことができます。 状況は別のアドバイスの影響で変化する可能性があり、新しいアドバイスがいつ使用されるのか、彼らが単にそれに注意を払わないのか想像さえできないかもしれません。 アドバイスの影響下で、完全に異なる機能が変化する可能性があり、状況によっては「進行」がまったくなく、いずれにせよ誰かが食べられる可能性があります。 これが発生した場合、その理由を理解する必要があります。



(1) «» (2) - , , , . , . , . , , , .



. , , . , , . , . (, , , !) « , ». .

, , , , . , , :

• : , - , - .
• : . .
• : , .

, , .



. -, , . (). , . , . : - , . , - .



. - . , . , , , «» «» .. , .



: ? , , – ! , , . - . , . . , – . , , . . , , . , .