以下はPeter Norvig のPradigmns of AI Programming についての 自身のブログ を訳したものです．もし君に私の声が聞こえないんだったら，それは私が括弧の中にいるせいだ（わきぜりふだからだ）．- Steven Wright

1997年10月: Paradigms of AI Programming (すなわちPAIP)を私が書き上げてから６年が経った．だからLispと人工知能プログラミングがその後どう変わったのか振り返るのにちょうどよいときのように思われる．

2002年4月更新: 10年経過した今，このページを更新した．

Lisp はまだユニークか? それとも少なくともまだ変わっているのか？

組込みのリスト． Javaにはベクトル型があり，動的に可変長なシーケンスが可能である．リストは（線形のアクセス時間という欠点はあるにせよ）関数プログラミングにより適している．一方，ベクトルは（非破壊的プッシュに対して線形時間であるという欠点があるにせよ）オブジェクト指向プログラミングにより適している．Java におけるベクトル型に対する支援は，Lisp におけるリストやシーケンスに対するサポートほど完成されてはいない．その主な理由は，Lisp は関数を引数とする第１級の関数をサポートするからである．Java もじきに列挙とベクトルとハッシュテーブルについて欠点を取り除くようなコレクションクラスを用意するかも知れない．Python にもまたベクトルクラスがある（それを List と呼ぶなら Python も Lisp と同様である）．

Javaにはベクトル型があり，動的に可変長なシーケンスが可能である．リストは（線形のアクセス時間という欠点はあるにせよ）関数プログラミングにより適している．一方，ベクトルは（非破壊的プッシュに対して線形時間であるという欠点があるにせよ）オブジェクト指向プログラミングにより適している．Java におけるベクトル型に対する支援は，Lisp におけるリストやシーケンスに対するサポートほど完成されてはいない．その主な理由は，Lisp は関数を引数とする第１級の関数をサポートするからである．Java もじきに列挙とベクトルとハッシュテーブルについて欠点を取り除くようなコレクションクラスを用意するかも知れない．Python にもまたベクトルクラスがある（それを List と呼ぶなら Python も Lisp と同様である）． 自動ストレージ管理． Java にも Python にもこれはある．しかしLisp の実装はより成熟していてよりよい性能である傾向にある．

Java にも Python にもこれはある．しかしLisp の実装はより成熟していてよりよい性能である傾向にある． 動的型付け． Java はクラスオブジェクトのインスタンスにランタイムの型情報を添加したけれども，プリミティブなデータエレメントには添加していない．しかしながら，Java ではすべての変数に型宣言が必要である．これは製品コードには何らかの利点をもたらすが，ラピッド・プロトタイピングやプログラム進化にとっては欠点となる．Java には Vector<String> のようなジェネリックなあるいはテンプレートのシステムがなくて，そのためにとっても苦しむことになる．Python のオブジェクトモデルは Lisp のそれと同じであるが，Python では Lisp のようにはオプションの型宣言をすることができない．

Java はクラスオブジェクトのインスタンスにランタイムの型情報を添加したけれども，プリミティブなデータエレメントには添加していない．しかしながら，Java ではすべての変数に型宣言が必要である．これは製品コードには何らかの利点をもたらすが，ラピッド・プロトタイピングやプログラム進化にとっては欠点となる．Java には のようなジェネリックなあるいはテンプレートのシステムがなくて，そのためにとっても苦しむことになる．Python のオブジェクトモデルは Lisp のそれと同じであるが，Python では Lisp のようにはオプションの型宣言をすることができない． 第１級の関数． Java には無名クラスがあり，クロージャの目的の幾ばくかはサービスされるけれども，それほど多くの使い方があるということでもないし，構文はぎこちない．Lisp なら， (lambda (x) (f (g x))) となるところが，Java では次のようになる． new UnaryFunction() { public Object execute(Object x) { return (Cast x).g().f(); }} ここで Cast は x の実タイプである．これは（JGL から生じてJava に組込みではない） UnaryFunction インターフェースを見るクラスと一緒のときだけ動く．Python はversion 2.1でLisp とほとんど同様な第１級の関数をサポートして， lambda x: f(g(x))． と書くことができる．唯一の欠点は，クローズドオーバー変数がリードオンリーであることである

Java には無名クラスがあり，クロージャの目的の幾ばくかはサービスされるけれども，それほど多くの使い方があるということでもないし，構文はぎこちない．Lisp なら， となるところが，Java では次のようになる． ここで は の実タイプである．これは（JGL から生じてJava に組込みではない） インターフェースを見るクラスと一緒のときだけ動く．Python はversion 2.1でLisp とほとんど同様な第１級の関数をサポートして， と書くことができる．唯一の欠点は，クローズドオーバー変数がリードオンリーであることである 一様な構文． Java の構文は複雑だ，Lisp より確かに複雑だ．Java ではマクロを使えない（禁止されている）．JDK コンパイラもコンピュータの生成するコードを敵視している．（到達不能コードのような）ワーニングであるべきものがエラーになっている．人間の書くコードには幾らかの助けとなるかもしれないが，コンピュータの生成するコードにとっては正直ウザい．言語のいくつかの特徴（同じ名前の変数が宣言されるときのためのルールみたいな）もコードの生成を難しくする．Python の構文はJava よりもいくらかは簡単だ．そして eval の存在がランタイム時のコード生成をうまくできそうにしてくれる．しかし，マクロシステムがないので，Lisp のときよりずっと長ったらしくつまらない．

Java の構文は複雑だ，Lisp より確かに複雑だ．Java ではマクロを使えない（禁止されている）．JDK コンパイラもコンピュータの生成するコードを敵視している．（到達不能コードのような）ワーニングであるべきものがエラーになっている．人間の書くコードには幾らかの助けとなるかもしれないが，コンピュータの生成するコードにとっては正直ウザい．言語のいくつかの特徴（同じ名前の変数が宣言されるときのためのルールみたいな）もコードの生成を難しくする．Python の構文はJava よりもいくらかは簡単だ．そして の存在がランタイム時のコード生成をうまくできそうにしてくれる．しかし，マクロシステムがないので，Lisp のときよりずっと長ったらしくつまらない． 対話環境． Java 環境には対話的なコマンドループや実行中断・デバッグのような Lisp 的な特徴を有するものがある．多分ずっと長く続けようとするわけではないが，Lisp 環境のほうがずっと進んでいる．特に BlueJ にはよいLisp 環境に匹敵するようなたいていの特長があって，メソッドを稼働中のプログラム中に再コンパイルできたり，タイプ入力してすぐ評価したりすることができる．それは教育目的を意図しており，製品使用に合っているかどうかは何とも言えない． Python にもLisp と同じ対話的アプローチがあるが，その環境はLisp ほどは成熟していない．

Java 環境には対話的なコマンドループや実行中断・デバッグのような Lisp 的な特徴を有するものがある．多分ずっと長く続けようとするわけではないが，Lisp 環境のほうがずっと進んでいる．特に BlueJ にはよいLisp 環境に匹敵するようなたいていの特長があって，メソッドを稼働中のプログラム中に再コンパイルできたり，タイプ入力してすぐ評価したりすることができる．それは教育目的を意図しており，製品使用に合っているかどうかは何とも言えない． Python にもLisp と同じ対話的アプローチがあるが，その環境はLisp ほどは成熟していない． 拡張性． これがJava の弱点を証明するものかも知れない．すべてをクラスをつくってやろうとする限りはJava はうまく動く．もし何か新しいこと，たとえば，アスペクト指向プログラミングでうまくやろうとすると，Lisp ならマクロを使って具体化できるかもしれないが，Java ではできないだろう．

これがJava の弱点を証明するものかも知れない．すべてをクラスをつくってやろうとする限りはJava はうまく動く．もし何か新しいこと，たとえば，アスペクト指向プログラミングでうまくやろうとすると，Lisp ならマクロを使って具体化できるかもしれないが，Java ではできないだろう． 歴史． （2002年当時において，訳注）Lisp には45年以上の歴史がある．対して，Java は7年, Python は12年である．

The Great Computer Language Shootout からの10のベンチマークに関する五つの言語の相対比較．

速度はC++ 用g++ コンパイラを1として正規化してある．2.00は２倍遅く， 0.01 は百倍速いという意味である．

Test Lisp Java Python Perl C++ 例外ハンドリング 0.01 0.90 1.54 1.73 1.00 ハッシュアクセス 1.06 3.23 4.01 1.85 1.00 ファイルからの数合計 7.54 2.63 8.34 2.49 1.00 100+ x C++ 行を反転 1.61 1.22 1.38 1.25 1.00 50-100 x C++ マトリックス掛け算 3.30 8.90 278.00 226.00 1.00 10-50 x C++ ヒープソート 1.67 7.00 84.42 75.67 1.00 5-10 x C++ 配列アクセス 1.75 6.83 141.08 127.25 1.00 1-5 x C++ リスト処理 0.93 20.47 20.33 11.27 1.00 0-1 x C++ オブジェクト生成 1.32 2.39 49.11 89.21 1.00 語数カウント 0.73 4.61 2.57 1.64 1.00 25% から75% 0.93 to 1.67 2.63 to 7.00 2.57 to 84.42 1.73 to 89.21 1.00 to 1.00

1991年に Lisp は他のどんな言語にも見られないような特徴の結合を提供した．この結合は Lisp をある種の仕事(AIとその他の応用)にほとんど必須なものにし，Lisp は大きなユーザのコミュニティに選択される言語となった．その時以来，Lisp は保守され，特徴が追加されたけれども，他の言語が追い付いてきた．Lisp が依然とユニークなのか，それとも2002年においても他の言語と少なくとも違うのか，どうなのかを見てみよう．PAIP[25ページ]で，私はLisp が人工知能応用に向いている言語にしている八つの重要な要素を挙げて，これらの大部分がプログラマーの意思決定を遅らせることができる要因であると述べた．この八つの要因に照らして，どのように Lisp が，たとえば Java やPython とは，どのように違うのかを見てみよう．このリストにはないもう一つの特徴がである．Lisp はJava より1.5倍から4倍早く，Python より10倍から50倍早い．たいていの仕事において，Lisp は多分効率でC/C++ の20%から60%の範囲内であろう．それは言語というよりもプログラマーにより依存した違いと言ってよく，ほとんどの応用でスピードはLispで問題ではないと言っていい．（何がしかのコードは必要である．特にメモリ資源のようなPAIPに記載のテクニックを用いた，メモリマネジメントを含むようなコードが．プログラマーにとっては余分な仕事だが，C++ との差はゼロである．）Python は遅すぎる．応用セットに関連したベンチマークのデータを得ることは難しいが，ここに実例がある．

総じて，Lisp はこの九つの指標で大変よい．これらの特徴に基づいて選択するならば，広い応用範囲でLisp がベストな選択であり続けるということはだれでも分かるであろう． しかし1991年には存在していなかった競技者が今は存在している．

Lisp は今不人気か?

他の言語ほどポピュラーではなく，それでユーザコミュニティはより小さく，Lisp まわりの開発は活発ではないという Lisp に対する批判がある．

大多数のインダストリーにおいて Lisp はあまり関係なくなって，言語選択にはJava が優っていると多分思われている．1997年当時の私の印象では，世界中でLisp ユーザ以外はこぞって最初はC++ に，それからJava （素早くキャッチアップしたけれども，C++ は依然として大きくリードを保っていた）に群がった一方で，Lisp はその忠実なユーザのほとんどに対して踏みとどまっていて，いくらかの新しいユーザが加わったというものであった．かくして，Lisp は安定的な絶対のポジションを占めているけれども，C++ やJava のような「マジョリティ」な言語の支持が増えてきたために，相対的に立場が弱くなっていて，広範囲には受け入れられていない言語であった．主なLisp ベンダーは，（リンク切れ，現在はLispWorksに継承されている．訳注） Harlequin （私は2年間そこで働いた） とFranz で，当時，着実に増加する販売が報告されていた．Digitool が素晴らしい製品を作ったことはよくわからなかった．それはMac 専用だし，Mac は急速にマーケットシェアを落としていた．多分OS Xに引き続いてより強くカムバックしてくるだろう．（残念ながらそうはならなかった．訳注）Lisp はまだまだ控えめではあるけれども，出版社やAmazon のようなディストリビュータによって販売促進されていた．Lisp はニッチで商業上の成功を享受し続けている．ポール・グレアムは最近Lisp プログラム（とその会社）をYahoo に4千万ドルで売却した．（オンラインストア用のオーサリング・ツールだった．）オンラインのe-コマース旅行会社，Orbitz は， Carl de Marcken の会社， ITA ソフトウェアによって提供された Lisp システムを用いて，スケジュール最適化を行う．CL-HTTP ウェブサーバは広く用いられている．バイオインフォマティックスのベストな仕事のいくつかは Lisp で行われている．もっと多くの例は以下を参照されたい．

2002年では, Java への壮大な希望はうまくいっていない．Java は企業空間においては大きな人気を享受しているが，汎用のラピッド開発用言語としても，効率的なシステム用言語としても，凌駕していない．Java の性能はC++ やLisp に比べて，みじめなままである．何故そうなのかは私は分からない．Sun は確かによりよいシステムを実装するのに十分な時間と資源を持っていた．多分彼らはもっと多くの元Lispコンパイラー作者を雇うべきだったんだろう．Fred Brooks は「ユーザが多ければ多いほど，より多くのバグが見つかる」 と報告しているけれども，私はLisp でそれが問題だったとは思わない．Lisp は我々がここで取り上げる他の言語よりも安定的であるのに十分なユーザと年月を得た．

しかし，人気におけるLisp の状況はいまだ弱点をさらけ出す．言語標準は滞っていて，スレッドやソケットやその他のキーとなる事柄の提案がない．さらに，HTTP，HTML，XML，SOAP，等々のような新しいプロトコルに対するよく知られたライブラリの標準リポジトリがない．工業的な実装はこれらのライブラリを追加するし，工業分野のプログラマーはオープンソースの実装を作りだす．しかしJava やPython のように箱から出してつかうだけというわけにはいかないし，Perl のCPAN のように一か所でそれらを見つけられるというわけにもいかない．これはこれらのライブラリを探し回るのにより多くの労力が必要だということだし，必要なライブラリがすぐに見つからないのでプロジェクトにLisp を使うことをやめてしまうプログラマーがいるということを意味している．C++ にはなのかんのと言っても結局Lisp のシーケンスよりもずっと使うのが難しくはあるが，STL使いのプログラマーの手によってとっても効率よく利用できる標準のテンプレートライブラリがある．Lisp エキスパートはまだ今までどおりに生産性は高いけれども，新しいプログラマーがLispを拾い上げたくなることはあまりない．言語の人気度を測った以下の表を考えてみよう．1997年には10言語があったが，2002年には5言語になってしまった．

1997 Language Books Usenet

Articles Recent

Articles URLs Jobs Avg.

Rank C++ 479 166,686 13,526 3,329 1,006 1.2 Java 161 160,276 30,663 2,450 280 1.8 All Lisps 140 31,501 3,833 1,565 12 4.1 Perl 67 12,376 9,919 1,031 174 4.6 Smalltalk 35 36,176 2,187 537 31 5.2 Lisp 127 15,367 1,775 734 11 6.1 Prolog 150 7,101 518 846 2 6.6 Eiffel 10 16,367 2,080 214 0 7.5 Scheme 10 11,458 1,846 408 0 8.3 Dylan 3 4,676 212 21 1 9.6 For 10 computer languages, this chart summarizes the number of books offered at Amazon , the number of archived and recent news articles in comp.lang.* at Dejanews , the number of hits on the query "+Language +computer" at Infoseek , and the number of jobs offered at Westech . (The "+computer" is used because many of the language names are ambiguous (Eiffel Tower, Java drink). "All Lisps" means Lisp+Scheme+Dylan.) Lisp is clearly behind C++ and Java, but at least in the ballpark for all measures except jobs. Lisp is slightly ahead of Perl, beating it in 3 of 5 measures. 2002 Language Books Usenet

Articles URLs Jobs Avg.

Rank Java 1695 68,000 1,790,000 1109 1.75 C++ 1208 25,800 1,170,800 517 2.00 Perl 424 57,800 978,000 364 2.50 Python 132 6,810 354,000 33 4.00 Lisp 159 6,330 305,000 4 4.75 For 5 computer languages, this chart summarizes the number of books offered at Amazon , the number of news articles in comp.lang.* at Google Groups , the number of hits on the query "Language computer" at Google , and the number of jobs offered at Monster.com . (Congratulations to Amazon for being the only one to remain the definitive category-leader for five years.) Java has now moved ahead of C++ in popularity, Perl has moved up to where it is nearly competitive with the big two, and Lisp has moved down, now beaing an order of magnitude behind the others in most categories. Python edges out Lisp in 3 of 4 categories.

Lisp は少なくともAI では人気があるか?

この測定は極めて科学的ではないし，それ以上多くを意味しているわけでもない．その計測後，Tiobe Softwareによる もうひとつの調査 があることに気が付いた．それではJava とトップで，C とC++ がそれぞれ2位と3位，そしてLisp は17位で，マーケットシェアはJava の 1/30 だ．人気度がよさを意味するわけでもないし，この数字が人気度に正しく関係しているということでもないけれども，何かを物語ってはいる．1991年と1997年では，答えは明らかにYes だ．しかし2002年では，答えはあまりはっきりしていない．次のGoogle サーチに従った結果の数字を考えてみよう．

（同様に，今日の時点，2015/04/15において，訳者が英語のみ表示で検索した結果を以下に示す．）



たいていの観察者にとっては明らかなのであるが，特に機械学習のコミュニティではLisp から離れて，C++ やMatlab のような特別の数学的パッケージに移動している．しかし，私はこの傾向がさらに進んでいることに実際驚いているし，Java がトップであることにもとっても驚いている．というのは，私はいままでそんなに最高のJava AI コードにお目にかかったことがないからだ．私は "Perl AI" が"Lisp AI" を上回ったことにも驚いた．だけどPerl 世界では "AI" は何か別の意味なのではないかと疑っている．というのは， "Perl Artificial Intelligence" は"Lisp Artificial Intelligence" よりもずっと下だからだ．

（さらに言えば，2015年の結果では "Python AI" が3位につき，"Lisp AI" は最下位に落ちた．一方，"Python 'aritificial intelligence'"も3位の好位置に付け，"lisp 'aritificial intelligence'"はまだ辛うじて4位にとどまっている．訳者はGoogle検索にはそれを求める人の数の多さが反映されるからだと思っている．ところがAIプログラミングのコードはLispが圧倒的に多く見ることができるのに対して，そのほかの言語では極端に少なく，グレアムのコメントと同様に，特にPerl のプログラムなど現在でも見たことがない．訳注）

新しいLisp の本

PAIP で何を学ぶか?

無名関数を使う． [p. 20] 実行時に新しい関数（クロージャ）を生成する． [p. 22] 問題を解くのに利用可能な最も自然な記法を利用する． [p. 42] 複数のプログラムで同じデータを使う． [p. 43] 具体的であれ．抽象を用いろ．簡潔であれ．あるツールを使え．あいまいにするな．首尾一貫させよ． [p. 49] マクロを使え（もし本当に必要なら） [p. 66] 20 か30の主要なデータタイプがある．それらに慣れよ． [p. 81] 複雑なデータ構造を開発するときはいつでもそれに合致した矛盾検出器を開発せよ． [p. 90] 問題をとくには，それを記述し，アルゴリズムの用語で明細に述べ，実装し，テストし，デバッグと分析をしろ．これを相互作用プロセスとして予期せよ． [p. 110] AI プログラミングは大部分探索的プログラミングである．目標はしばしば問題領域に対してより多く発見される． [p. 119] 一般問題解決器は異なる問題を解くことができなければならない． [p. 132] すべての考えるということが計算モデルのとおりと信ずる誘惑に抵抗しなければならない． [p. 147] この本の主な目的は読者が自分自身に「それなら書けたかも」と言わせることにある． [p. 152] もしプロンプトを除けば，丁度四つのシンボルを用いてLisp インタプリタを書けた．Pascal （またはJavaで）Lisp （または Pascal, あるいはJava）のインタプリタを書くために何をしなければいけないか考えてみよう． [p. 176] デザインパターンは非公式に使われるか，もしくは形式的な関数，マクロ，データタイプ（しばしば高階関数を含む）に抽象化される． [p. 177] データ駆動型プログラミングを用いよ．そこではパターン／アクションのペアがテーブル内に保存される． [p. 182] "多かれ少なかれ": 正しい出力というよりも多くの出力をするほうが容易であるときがある． [p. 231] Lisp が他の高級言語よりも本質的に効率が悪いということはない- Richard Fateman．[p. 265] 最初に動くプログラムを開発し，２番目にそれを装着し，最後に遅い部分を置き換えろ． [p. 265] 経験を積んだ Lisp プログラマーは結局はよい"効率的モデル"を開発する． [p. 268] アルゴリズムを高速化する四つの一般的テクニックがある．キャッシュすること，コンパイルすること，計算を遅延すること，インデックス化することである． [p. 269] マクロ集合としてコンパイラを書くことができる． [p. 277] コンパイルとメモ化することで百倍は速くすることができる． [p. 307] 低レベルの高速化に注意を払って，40倍は速くすることができる． [p. 315] 高速化には，宣言を用いよ，汎用関数を避けよ，複雑な引数リストを避けよ，不必要なコンスを避けよ，正しいデータ構造を用いよ． [p. 316] プログラミングについて考えたようには働かない言語なら知る必要はない- Alan Perlis． [p. 348] Prolog は三つのアイデアに依存している．均質なデータベース，論理変数，そして自動バックトラックである． [p. 349] Prolog は主な点でLisp に類似している． [p. 381] オブジェクト指向 = オブジェクト+ クラス+ 継承- Peter Wegner [p. 435] （関数プログラミングがするような）大域的状態を禁じる代わりに，オブジェクト指向プログラミングは大域的状態の御しにくい量を小さな管理可能な断片すなわちオブジェクトにバラバラにして，それをカプセル化する． [p. 435] あなたの定義に依存して，CLOSはオブジェクト指向であったりなかったりする．それはカプセル化はサポートしない． [p. 454] Prolog は正確にはあなたが望む論理を提供しないし[p. 465]，望む効率も提供しない．[p. 472] その他の表現のスキーマが可能である． ルールベースの変換は強力なアイデアであるけれど，ときどきもっと効率が必要となる．そしてルールベースシステムの単純さをあきらめる必要がある．[p. 509]. 入力を正規の書式に変換するのはしばしばよい戦略である．[p. 510]. 「エキスパートシステム」は簡単な論理プログラミングを超えるものである．それは不確実性推論，説明，柔軟な制御フローを提供する．[p. 531]. 確信度は不確実性を扱う簡単な方法を提供するが，確率論はより堅固な基礎を提供するという一般的な合意がある．[p. 534]. よい移動シーケンスを探索するのに用いられる戦略が重要である．[p. 615]. あるタスクに対する二つの異なる戦略を繰り返し試すことで二つを比較することができる．[p. 626]. プレサイクルは報酬が見合う．[p. 633]. メモ化は非効率なプログラムを効率的にする．[p. 662]. 厳密なルールで一つの解釈をINかOUTか決めようとするよりも，競合する入力の解釈を好みで選んだ方が簡単な場合がしばしばある．[p 670]. 論理プログラミングには文法を表現する簡単な方法がある．[p. 685]. 自然言語で量化を扱うのはトリッキーである．[p. 696]. 自然言語で遠く離れた依存関係を扱うのはトリッキーである．[p. 702]. Scheme のインタプリタがどう働くかを理解すれば，どうLisp が働くかがよりよく分かり，よりよいプログラマーになる．[p. 753]. call/cc について真に驚きで素晴らしいことは一度以上のコンティニュエーション・ポイントに戻ることのできる能力である． [p. 771]. 最初のLisp インタプリタはプログラマーがボスの忠告を無視した結果であった． [p. 777]. Abelson とSussman (1985) は多分今までで一番ベストなコンピュータの紹介である．[p. 777]. 最も単純なコンパイラがインタプリタよりずっと複雑である必要はない．[p. 784]. ANSI Common Lisp の並外れた特徴はエラーハンドリングの機能設備である．[p. 837]. もしどうやって，かついつ once-only 用いればよいか分かったなら，それは本当にマクロが分かったということだ．[p. 853]. 賢者への言葉：マクロで調子にのるなかれ．[p. 855].

PAIP は何を成し遂げたか?

進んだLisp 教科書として， PAIP はとってもうまくできている．効率問題，Lisp 設計問題，マクロとコンパイラの使用の扱いでこんなに徹底的なものはほかには依然とほとんどない．（マクロについては，ポールグレアムの本が特別に優れている．）

はとってもうまくできている．効率問題，Lisp 設計問題，マクロとコンパイラの使用の扱いでこんなに徹底的なものはほかには依然とほとんどない．（マクロについては，ポールグレアムの本が特別に優れている．） AI プログラミングの教科書として， PAIP はうまくできた．本当に匹敵するものは，最近出現したForbus と de Kleer のものだけであって，それはもっと限られている（もっと焦点がはっきりして統合されている）アプローチで推論システムに集中している．（Charniak，Riesbeck，McDermott の本もまだ読む価値がある．） 最近の6年間にわたる変化は AI プログラミングがより「普通の」プログラミングのように見え始めたということだ．なぜなら (a) AI プログラムが，「普通の」プログラムのように，大きなデータベースと関わることが増えたためであり，(b) 「普通」のプログラマーがインターネットサーチのようなことをし始めたり，手書き文字認識や音声認識を始めたりしたからである．今日の AI プログラミング教科書はデータベース・インタフェースやhttpやその他のネットワークプロトコル，スレッド，グラフィックインタフェースなどをカバーしなければならないだろう．



はうまくできた．本当に匹敵するものは，最近出現したForbus と de Kleer のものだけであって，それはもっと限られている（もっと焦点がはっきりして統合されている）アプローチで推論システムに集中している．（Charniak，Riesbeck，McDermott の本もまだ読む価値がある．） 最近の6年間にわたる変化は AI プログラミングがより「普通の」プログラミングのように見え始めたということだ．なぜなら (a) AI プログラムが，「普通の」プログラムのように，大きなデータベースと関わることが増えたためであり，(b) 「普通」のプログラマーがインターネットサーチのようなことをし始めたり，手書き文字認識や音声認識を始めたりしたからである．今日の AI プログラミング教科書はデータベース・インタフェースやhttpやその他のネットワークプロトコル，スレッド，グラフィックインタフェースなどをカバーしなければならないだろう． AI の教科書としては，PAIP はあまりよくない．最も現代のプログラムや理論をというよりも，この分野の「パラダイム」や「古典」を強調して，包括的な AI の教科書にしようとは決してしなかった．幸いなことに，今では古典は時代遅れであるかのようになってきている．（もしまだそれが結局そうでなかったのなら，残念なことであるが．）より現代の AI アプローチについては，PAIP は忘れて Artificial

Intelligence: A Modern Approach を見てほしい．

私の意見では，ベストはポール・グレアムのだ．（Peter Seibel のPractical Common Lisp は2005年出版，訳注）Lisp コンパイラーとインタプリタの書き方について今までで最高の本は多分Christian Queinnec のだ．Scheme 世界なら，Abelson とSussman のの新しい版と，The Seasoned Schemer と呼ばれるDaniel Friedman の The Little Lisper の新版だ．Stephen Slade は新しい本を書いたが，私はまだ見るチャンスがない．以下のリストはPAIP におけるもっとも重要な52の教訓である．