(Original article: Lisp: Good News, Bad News, How to Win Big
. Japanese translation by Hisashi Morita.)
This article was originally published in 1991.この記事は当初1991年に公表された。
Lisp has done quite well over the last ten years: becoming nearly standardized, forming the basis of a commercial sector, achieving excellent performance, having good environments, able to deliver applications. Yet the Lisp community has failed to do as well as it could have. In this paper I look at the successes, the failures, and what to do next.Lispはこの10年以上の間、順調に進んできた：ほぼ標準化された状態になり、商業部門の基盤となり、優れた効率を達成し、良い環境を備え、アプリケーションを仕上げることができる。しかしいまだにLispコミュニティは理想には遠い状態にある。この論文で私は成功と失敗、そして次に何をすべきかを見ていく。
The Lisp world is in great shape: Ten years ago there was no standard Lisp; the most standard Lisp was InterLisp, which ran on PDP-10s and Xerox Lisp machines (some said it ran on Vaxes, but I think they exaggerated); the second most standard Lisp was MacLisp, which ran only on PDP-10s, but under the three most popular operating systems for that machine; the third most standard Lisp was Portable Standard Lisp, which ran on many machines, but very few people wanted to use it; the fourth most standard Lisp was Zetalisp, which ran on two varieties of Lisp machine; and the fifth most standard Lisp was Scheme, which ran on a few different kinds of machine, but very few people wanted to use it. By today’s standards, each of these had poor or just barely acceptable performance, nonexistent or just barely satisfactory environments, nonexistent or poor integration with other languages and software, poor portability, poor acceptance, and poor commercial prospects.Lispの世界は非常によく発達している：10年前は標準化されたLispというものはなかった。最も標準に近いLispはInterLispで、PDP-10とXerox Lispマシンで動作するものだった（Vaxで動作したと言う人もいたが、それは誇張だと思う）。2番目がMacLispで、これはPDP-10でしか動作しなかったが、そのマシン上では最も人気がある3種類のオペレーティングシステム上で動作した。3番目はPortable Standard Lispで、これは多くのマシン上で動作したが、使いたがる人はほとんどいなかった。4番目はZetalispで、2種類のLispマシン上で動作した。5番目はSchemeで、いくつかの異なるマシン上で動作したが、使いたがる人はほとんどいなかった。今日の標準によれば、これらはどれも貧弱なあるいは許容できるぎりぎりのパフォーマンスでしか動かず、環境は存在しないか満足ぎりぎりのものしかなく、他の言語やソフトウェアとの統合は存在しないか貧弱なものであり、可搬性は低く、受け入れられておらず、商業利用は見込みが薄かった。
Today there is Common Lisp (CL), which runs on all major machines, all major operating systems, and virtually in every country. Common Lisp is about to be standardized by ANSI, has good performance, is surrounded with good environments, and has good integration with other languages and software.今日ではCommon Lisp（CL）があり、これは主要なすべてのマシン、主要なすべてのオペレーティングシステム、および実質的にすべての国において動作する。Common LispはANSIによって今まさに標準化されようとしており、効率は良好で、優れた環境に取り囲まれており、他の言語やソフトウェアとうまく統合されている。
But, as a business, Lisp is considered to be in ill health. There are persistent and sometimes true rumors about the abandonment of Lisp as a vehicle for delivery of practical applications.しかし、ビジネスとしては、Lispは悪い状況に置かれているとみなさざるを得ない。実用的なアプリケーションを納品する際の言語としてLispを使うことを断念したという噂話は常に流れており、それが本当であることもあった。
To some extent the problem is one of perception -- there are simply better Lisp delivery solutions than are generally believed to exist and to a disturbing extent the problem is one of unplaced or misplaced resources, of projects not undertaken, and of implementation strategies not activated.ある程度までは、問題は人々の認識にある――世間で一般に信じられているよりも明らかに優れたLispのソリューションは存在する。むしろ、リソースが正しく割り当てられていないか、あるいは全く割り当てられていないこと、プロジェクトが着手されていないこと、実装戦略が手つかずのままであることが問題である場合が、嫌になるほど多い。
Part of the problem stems from our very dear friends in the artificial intelligence (AI) business. AI has a number of good approaches to formalizing human knowledge and problem solving behavior. However, AI does not provide a panacea in any area of its applicability. Some early promoters of AI to the commercial world raised expectation levels too high. These expectations had to do with the effectiveness and deliverability of expert-system-based applications.問題の一部は、人工知能（AI）ビジネスの分野にいる我々の実に親愛なる友人たちに端を発するものだ。AIには、人間の知識と問題解決能力を形式化する優れたアプローチが数多くある。しかしながらAIはその該当分野のただ一つにおいても、万能薬を提供してはいない。初期にAIをビジネスの世界に持ち込んだ推進者のなかの誰かが、期待の水準をあまりに高く持ち上げすぎてしまったのだ。この期待はエキスパートシステムベースのアプリケーションの有効性および完成可能性に影響した。
When these expectations were not met, some looked for scapegoats, which frequently were the Lisp companies, particularly when it came to deliverability. Of course, if the AI companies had any notion about what the market would eventually expect from delivered AI software, they never shared it with any Lisp companies I know about. I believe the attitude of the AI companies was that the Lisp companies will do what they need to survive, so why share customer lists and information with them?この期待が裏切られたとき、スケープゴートを探す輩がいた。そしてしばしばLisp企業が生贄になった――特に、完成可能性が問題になる時には。もちろん、納品されたAIソフトウェアに対する市場の最終的な要望について、AI企業が何かしら知っていても、彼らは私が知っているどのLisp企業ともそれを分かち合おうとはしなかった。私の記憶では、AI企業の態度はこういうふうだった。Lisp企業は勝手に生き延びるだろう、顧客名簿や情報を彼らと共有する必要などあるものか、と。
Another part of the problem is the relatively bad press Lisp got, sometimes from very respectable publications. I saw an article in Forbes (October 16, 1989) entitled Where Lisp Slipped by Julie Pitta. However, the article was about Symbolics and its fortunes. The largest criticisms of Symbolics in the article are that Symbolics believed AI would take off and that Symbolics mistakenly pushed its view that proprietary hardware was the way to go for AI. There was nothing about Lisp in the article except the statement that it is a somewhat obscure programming language used extensively in artificial intelligence.問題はほかにもあって、それはLispに対する論評がかなり悪いことだった。時として非常に立派な出版物で叩かれることもあった。私はForbes（1989年10月16日号）でJulie PittaのWhere Lisp Slipped（Lispのよろめき）という記事を見かけた。しかしながら、この記事はSymbolicsとその浮沈に関するものだった。記事中におけるSymbolicsに対する最大の批判は、SymbolicsはAIが離陸すると信じていたことと、AIにおいては独自ハードウェアが進むべき道だという見方を誤って推し進めたことだとしていた。記事中には、人工知能ではなんだかよく分からないプログラミング言語が大々的に使われていたということを除いては、Lispに関する記述は何もなかった。
It seems a pity for the Lisp business to take a bump partly because Julie thought she could make a cute title for her article out of the name Lisp.Lispビジネスがつまずいた原因の一端が、Julieが自分の記事にLispという名前を利用して気が利いたタイトルを付けられそうだと思ったせいだったとは、気の毒なことだ。
But, there are some real successes for Lisp, some problems, and some ways out of those problems.しかし、Lispには本物の成功があり、問題があり、そして問題を解決する道がある。
As I mentioned, Lisp is in better shape today than it ever has been. I want to review some Lisp success stories.先に述べたように、Lispは今日ではかつてないほどに発展した状態にある。Lispの成功談をいくつか振り返ってみたい。
A major success is that there is a standard Lisp -- Common Lisp. Many observers today wish there were a simpler, smaller, cleaner Lisp that could be standardized, but the Lisp that we have today that is ready for standardization is Common Lisp. This isn’t to say that a better Lisp could not be standardized later, and certainly there should be. Furthermore, like any language, Common Lisp should be improved and changed as needs change.大きな成功は、標準化されたLisp――Common Lisp――が存在することだ。今日では多くの傍観者たちが、もっと単純で小さくきれいで標準化に適したLispがあればよいのにと思っているが、しかし我々が今日手にしている標準化の準備が整ったLispはCommon Lispだ。将来より良いLispが標準化される可能性がないと言っているわけではないし、もちろんそうあるべきだ。さらに言えば、どんな言語でもそうであるように、Common Lispは需要が変化するにつれて改良され変わっていくべきだ。
Common Lisp started as a grassroots effort in 1981 after an ARPA-sponsored meeting held at SRI to determine the future of Lisp. At that time there were a number of Lisps in the US being defined and implemented by former MIT folks: Greenblatt (LMI), Moon and Weinreb (Symbolics), Fahlman and Steele (CMU), White (MIT), and Gabriel and Steele (LLNL). The core of the Common Lisp committee came from this group. That core was Fahlman, Gabriel, Moon, Steele, and Weinreb, and Common Lisp was a coalescence of the Lisps these people cared about.Common Lispは、ARPAから資金援助を受けてSRIで開催されたLispの将来を決定する会合の後で、草の根的な取り組みとして1981年に始まった。当時USでは、以前MITにいた人々によって数多くのLispが定義され実装されていた：Greenblatt（LMI）、MoonとWeinreb（Symbolics）、FahlmanとSteele（CMU）、White（MIT）、そしてGabrielとSteele（LLNL）だ。Common Lisp委員会の中心人物はこれらのグループから来ていた。その中心人物とは、Fahlman、Gabriel、Moon、Steele、およびWeinrebで、Common Lispはこれらの人々のお気に入りのLispが一つに融合したものだった。
There were other Lisps that could have blended into Common Lisp, but they were not so clearly in the MacLisp tradition, and their proponents declined to actively participate in the effort because they predicted success for their own dialects over any common lisp that was defined by the grassroots effort. Among these Lisps were Scheme, Interlisp, Franz Lisp, Portable Standard Lisp, and Lisp370.Common Lispに取り入れることができただろうLispはほかにもあったが、それらはMacLispの流儀にあまりはっきりと沿っておらず、それらの支持者たちは草の根活動で定義されたどんな標準lispよりも自分たちの方言のほうが成功すると予想したので、標準化活動に活発に加わろうとしなかった。そういったLispにはScheme、Interlisp、Franz Lisp、Portable Standard Lisp、およびLisp370があった。
And outside the US there were major Lisp efforts, including Cambridge Lisp and Le-Lisp. The humble US grassroots effort did not seek membership from outside the US, and one can safely regard that as a mistake. Frankly, it never occurred to the Common Lisp group that this purely American effort would be of interest outside the US, because very few of the group saw a future in AI that would extend the needs for a standard Lisp beyond North America.そしてUSの外では、Cambridge LispとLe-Lispを含む、Lispに関する大きな取り組みが存在した。USの慎ましやかな草の根活動はUS外には参加を呼びかけなかったが、それは誤りだったと言って差し支えない。率直に言って、Common Lispのグループが、この純粋にアメリカ的な取り組みがUS以外で関心を持たれるだろうと想像することは一度もなかった。なぜなら、標準Lispに対する需要を北米以外に広めるような未来がAIにあると察した人が、グループにはほとんどいなかったからだ。
Common Lisp was defined and a book published in 1984 called /Common Lisp: the Language/ (CLtL). And several companies sprang up to put Common Lisp on stock hardware to compete against the Lisp machine companies. Within four years, virtually every major computer company had a Common Lisp that it had either implemented itself or private-labeled from a Common Lisp company.Common Lispが定められ、/Common Lisp: the Language/（CLtL）と呼ばれる本が1984年に出版された。そして既成のハードウェアにCommon Lispを載せてLispマシン企業に対抗すべく、いくつかの企業が立ち上げられた。それから4年以内に、事実上すべての主要なコンピュータ企業が、自身による実装か、もしくはCommon Lisp企業のプライベートレーベル版によるCommon Lispを持っていた。
In 1986, X3J13 was formed to produce an ANSI version of Common Lisp. By then it was apparent that there were significant changes required to Common Lisp to clean up ambiguities and omissions, to add a condition system, and to define object-oriented extensions.1986年には、Common LispのANSI版を作るべくX3J13が発足した。それまでに、Common Lispの曖昧さと不備を修正し、condition systemを追加し、オブジェクト指向拡張を定義するには、大幅な変更が必要であることが明らかになっていた。
After several years it became clear that the process of standardization was not simple, even given a mature language with a good definition. The specification of the Common Lisp Object System (CLOS) alone took nearly two years and seven of the most talented members of X3J13.数年の後、十分な定義のある成熟した言語であったとしても、標準化のプロセスは容易ではないことがはっきりした。Common Lisp Object System（CLOS）の仕様策定だけでも、2年近くの歳月とX3J13の最も才能ある7人のメンバーを必要としたのだ。
It also became apparent that the interest in international Lisp standardization was growing. But there was no heir apparent to Common Lisp. Critics of Common Lisp, especially those outside the US, focused on Common Lisp’s failures as a practical delivery vehicle.また、国際的なLisp標準化に対する興味が増してきているということもはっきりした。しかしCommon Lispには法定推定相続人がいなかった。Common Lispを酷評する者は、特にUS外の人間は、Common Lispが実用的な開発基盤として失敗していることに批判を集中した。
In 1988, an international working group for the standardization of Lisp was formed. That group is called WG16. Two things are absolutely clear: The near-term standard Lisp is Common Lisp; a longer-term standard that goes beyond Common Lisp is desirable.1988年には、Lispの標準化に関する国際的なワーキンググループが結成された。グループの名はWG16といった。完全にはっきりしていることが2つあった：当面の標準LispはCommon Lispであること。より長期的な視点に基づいた、Common Lispを超える標準の存在が望ましいこと。
In 1988, the IEEE Scheme working group was formed to produce an IEEE and possibly an ANSI standard for Scheme. This group completed its work in 1990, and the relatively small and clean Scheme is a standard.1988年に、SchemeについてIEEEのそしてできればANSIの標準を作るべく、IEEE Schemeワーキンググループが発足した。このグループは1990年に作業を終え、比較的小さくてきれいなSchemeが標準となっている。
Currently, X3J13 is less than a year away from a draft standard for ANSI Common Lisp; WG16 is stalled because of international bickering; Scheme has been standardized by IEEE, but it is of limited commercial interest.現在、X3J13はANSI Common Lispのドラフト標準を1年以内に控えている。WG16は国際間の口論によって立ち往生している。SchemeはIEEEによって標準化されたが、商業的な関心は乏しい。
Common Lisp is in use internationally, and serves at least as a de facto standard until the always contentious Lisp community agrees to work together.Common Lispは国際的に利用されており、論争を好むのを常とするLispコミュニティが協力して働くことに同意するまでは、少なくとも事実上の標準として役に立つ。
Common Lisp performs well. Most current implementations use modern compiler technology, in contrast to older Lisps, which used very primitive compiler techniques, even for the time. In terms of performance, anyone using a Common Lisp today on almost any computer can expect better performance than could be obtained on single-user PDP-10s or on single-user Lisp machines of mid-1980s vintage. Many Common Lisp implementations have multitasking and non-intrusive garbage collection -- both regarded as impossible features on stock hardware ten years ago.Common Lispは効率良く動作する。現在の実装のほとんどは、当時でさえ非常に原始的とされていたコンパイラ技法（techniques）を使っていた古いLisp実装とは対照的に、モダンなコンパイラ技術（technology）を利用している。効率について言うと、今日Common Lispを使っている人は、ほとんどのプラットフォーム上で、1980年代半ばの年代物のPDP-10やLispマシンをシングルユーザで動かして得られるよりも良いパフォーマンスを期待できる。ほとんどのCommon Lisp実装はマルチタスクとnon-intrusiveなガーベジコレクションを備えている――どちらも10年前は既成のハードウェアでは無理だと思われていた機能だ。
In fact, Common Lisp performs well on benchmarks compared to C. The following table shows the ratio of Lisp time and code size to C time and code size for three benchmarks.実際、Common LispはCと比較したベンチマークでも良好な成績を示している。次の表は3つのベンチマークでLispの所要時間およびコードサイズをCの所要時間およびコードサイズと比べた比率だ。
|
CPU Time
|
Code Size
|
|
| Tak |
0.90
|
1.21
|
| Traverse |
0.98
|
1.35
|
| Lexer |
1.07
|
1.48
|
Tak is a Gabriel benchmark that measures function calling and fixnum arithmetic. Traverse is a Gabriel benchmark that measures structure creation and access. Lexer is the tokenizer of a C compiler and measures dispatching and character manipulation.Takは関数呼び出しと固定小数点数演算を計測するGabrielベンチマークだ。Traverseは構造体の生成とアクセスを計測するGabrielベンチマークだ。LexerはCコンパイラのトークナイザで、ディスパッチと文字の操作を計測する。
These benchmarks were run on a Sun 3 in 1987 using the standard Sun C compiler using full optimization. The Lisp was not running a non-intrusive garbage collector.これらのベンチマークは1987年にSun 3上で標準のSun Cコンパイラを使って最高度の最適化を有効にして実行された。Lispはnon-intrusiveなガーベジコレクタを走らせていない。
It is arguable that modern programming environments come from the Lisp and AI tradition. The first bit-mapped terminals (Stanford/MIT), the mouse pointing device (SRI), full-screen text editors (Stanford/MIT), and windowed environments (Xerox PARC) all came from laboratories engaged in AI research. Even today one can argue that the Symbolics programming environment represents the state of the art.モダンなプログラミング環境がLispとAIの伝統に由来するということは間違いない。初めてのビットマップ端末（Stanford/MIT）、マウスポインティングデバイス（SRI）、フルスクリーンテキストエディタ（Stanford/MIT）、およびウィンドウ環境（Xerox PARC）はすべてAIの研究に携わっていた研究所から出てきている。今日でもなお、Symbolicsプログラミング環境は最高の水準にあると言える。
It is also arguable that the following development environment features originated in the Lisp world:次に挙げる開発環境の機能も間違いなくLispの世界に由来するものだ：
Today’s Lisp environments are equal to the very best Lisp machine environments in the 1970s. Windowing, fancy editing, and good debugging are all commonplace. In some Lisp systems, significant attention has been paid to the software lifecycle through the use of source control facilities, automatic cross-referencing, and automatic testing.今日のLisp環境は、1970年代の最も優れたLispマシン環境に匹敵する。ウィンドウ、凝ったエディタ、快適なデバッグは当たり前のものになっている。Lispシステムのなかには、ソース管理機構やクロスリファレンスの自動生成や自動テストを使って、ソフトウェアライフサイクルに相当の配慮をしているものがある。
Today Lisp code can coexist with C, Pascal, Fortran, etc. These languages can be invoked from Lisp and in general, these languages can then re-invoke Lisp. Such interfaces allow the programmer to pass Lisp data to foreign code, to pass foreign data to Lisp code, to manipulate foreign data from Lisp code, to manipulate Lisp data from foreign code, to dynamically load foreign programs, and to freely mix foreign and Lisp functions.今日ではLispはC、Pascal、Fortranその他のコードと同居できる。これらの言語はLispから呼び出すことができ、一般的に言って、さらにこれらの言語からLispを再度呼び出すこともできる。そういったインタフェースのおかげでプログラマはLispデータを他の言語のコードに受け渡したり、他の言語のデータをLispに受け渡したり、他言語のデータをLispで操作したり、Lispのデータを他の言語で操作したり、他の言語のプログラムを動的にロードしたり、他の言語の関数とLispの関数を自由に混ぜ合わせたりできる。
The facilities for this functionality are quite extensive and provide a means for mixing several different languages at once.この機能を実現している機構は非常に徹底したもので、いくつかの異なる言語を同時に混在させる手段を提供している。
Lisp has the most powerful, comprehensive, and pervasively object-oriented extensions of any language. CLOS embodies features not found in any other object-oriented language. These include the following:Lispはあらゆる言語のなかで最も強力で包括的で広汎なオブジェクト指向拡張を備えている。CLOSは他のどんなオブジェクト指向言語にも見られない機能を実現している。それには次のものが含まれる：
It is likely that Common Lisp (with CLOS) will be the first standardized object-oriented programming language.（CLOSを含む）Common Lispが標準化された最初のオブジェクト指向プログラミング言語になる可能性は高い。
It is possible to deliver applications written in Lisp. The currently available tools are good but are not yet ideal. These solutions include from removing unused code and data from application, building up applications using only the code and data needed, and producing .o files from Lisp code.Lispで書かれたアプリケーションを納入することは可能だ。現在手に入るツールは悪くないがまだ理想的とは言えない。これらの解決策には、未使用のコードやデータをアプリケーションから取り除くことや、必要なコードとデータだけを用いてアプリケーションをビルドすることや、Lispコードから.oファイルを生成することが含まれる。
Delivery tools are commercially provided by Lucid, Franz, and Ibuki.納入のためのツールはLucid、Franz、およびIbukiから商品として提供されている。
Too many teardrops for one heart to be crying.
Too many teardrops for one heart to carry on.
You’re way on top now, since you left me,
Always laughing, way down at me.
? & The Mysterians
This happy story, though, has a sad interlude, an interlude that might be attributed to the failure of AI to soar, but which probably has some other grains of truth that we must heed. The key problem with Lisp today stems from the tension between two opposing software philosophies. The two philosophies are called The Right Thing and Worse is Better.だがこの幸福な物語には、悲しい幕間がある。それはAIが離陸に失敗したせいにされるかもしれないが、多分真の原因は他にもあり、我々はそれに注意しなければならない。今日のLispにおいて鍵となる問題は、2つの対立するソフトウェア哲学の緊張関係から生じるものだろう。その2つの哲学は、The Right Thing（正しいもの）およびWorse is Better（劣っているほうが優れている）と呼ばれる。
I and just about every designer of Common Lisp and CLOS has had extreme exposure to the MIT/Stanford style of design. The essence of this style can be captured by the phrase the right thing. To such a designer it is important to get all of the following characteristics right:私をはじめ、Common LispとCLOSの設計者なら誰でも、MIT/Stanford式の設計に極度に慣れ親しんできている。このスタイルのエッセンスは、the right thingという言葉に集約することができる。そのような設計者にとって、次の特徴をすべて正しく実現することは重要なことだ：
I believe most people would agree that these are good characteristics. I will call the use of this philosophy of design the MIT approach Common Lisp (with CLOS) and Scheme represent the MIT approach to design and implementation.ほとんどの人が、これらが良い特徴であるということに同意してくれると思う。私はこの設計哲学を用いることをMITアプローチと呼ぶ。Common Lisp（CLOSを含む）およびSchemeはMITアプローチによる設計と実装の代表例だ。
The worse-is-better philosophy is only slightly different:worse-is-better哲学はほんのわずかしか違わない：
Early Unix and C are examples of the use of this school of design, and I will call the use of this design strategy the New Jersey approach I have intentionally caricatured the worse-is-better philosophy to convince you that it is obviously a bad philosophy and that the New Jersey approach is a bad approach.初期のUnixとCはこの学派による設計が用いられた例で、この設計戦略を用いることを私はNew Jerseyアプローチと呼ぼう。私はworse-is-better哲学を意図的に戯画化した。それが明らかに悪い哲学であり、New Jerseyアプローチは悪いアプローチであると分かってもらうためだ。
However, I believe that worse-is-better, even in its strawman form, has better survival characteristics than the-right-thing, and that the New Jersey approach when used for software is a better approach than the MIT approach.しかしながら私が思うに、論破するための貧弱な対立意見として提示された場合であってすら、worse-is-betterにはthe-right-thingよりも生き残りやすい特性がある。ソフトウェアに用いられたときには、New JerseyアプローチはMITアプローチよりも優れたアプローチなのだ。
Let me start out by retelling a story that shows that the MIT/New-Jersey distinction is valid and that proponents of each philosophy actually believe their philosophy is better.MIT/New-Jerseyという区別が妥当であり、両派の支持者が自説のほうが優れていると実際に信じているということを示す話から始めさせてほしい。
Two famous people, one from MIT and another from Berkeley (but working on Unix) once met to discuss operating system issues. The person from MIT was knowledgeable about ITS (the MIT AI Lab operating system) and had been reading the Unix sources. He was interested in how Unix solved the PC loser-ing problem. The PC loser-ing problem occurs when a user program invokes a system routine to perform a lengthy operation that might have significant state, such as IO buffers. If an interrupt occurs during the operation, the state of the user program must be saved. Because the invocation of the system routine is usually a single instruction, the PC of the user program does not adequately capture the state of the process. The system routine must either back out or press forward. The right thing is to back out and restore the user program PC to the instruction that invoked the system routine so that resumption of the user program after the interrupt, for example, re-enters the system routine. It is called PC loser-ing because the PC is being coerced into loser mode, where loser is the affectionate name for user at MIT.かつて2人の著名な人物*がオペレーティングシステムの問題を議論するために会う機会があった。一人はMITから、もう一人はBerkeleyから（ただし彼はUnixに取り組んでいた）。MITから来た人物はITS（MITのAI研のオペレーティングシステム）に詳しく、その時までにUnixのソースを読んでいた。彼はUnixがどうやってPC loser-ing問題を解決しているのかに興味を持っていた。PC loser-ing問題とは、ユーザプログラムが、（例えばIOバッファのように）重要な状態を持つ可能性がある、時間のかかる操作を行おうとして、システムルーチンを起動するときに起きる。操作の途中で割り込みが入れば、ユーザプログラムの状態は保存されなければならない。システムルーチンの呼び出しはたいてい1命令なので、ユーザプログラムのPC（プログラムカウンタ）はプロセスの状態を適切に捉えて保存しない。システムルーチンは取り消し（back out）するか押し進む（press forward）か、どちらかしかない。正しい対処法は、取り消しを行って、システムルーチンを呼び出した命令のところにユーザプログラムのPCを復元することだ。割り込み後のユーザプログラムの再開が、例えばシステムルーチンに再入するように。これはPC loser-ingと呼ばれる。というのもPCが強制的にloser modeにされているからだ。ここでいうloserは、MITにおけるuserの愛称だ。
The MIT guy did not see any code that handled this case and asked the New Jersey guy how the problem was handled. The New Jersey guy said that the Unix folks were aware of the problem, but the solution was for the system routine to always finish, but sometimes an error code would be returned that signaled that the system routine had failed to complete its action. A correct user program, then, had to check the error code to determine whether to simply try the system routine again. The MIT guy did not like this solution because it was not the right thing.MIT派の男はこのような場合を扱うコードを見つけ出せず、New Jersey派の男にこの問題がどう扱われているのか聞いた。New Jersey派の男は、Unixの連中はこの問題に気づいているが、解決策はこうだと言った：システムルーチンは常に完了するが、システムルーチンが失敗して動作を完遂できなかったことを示すエラーコードを返すことがある、というものだと。正しいユーザプログラムは、だから、システムルーチンを単純に再試行するかどうかを決めるためにエラーコードを確かめる必要がある。MIT派の男はこの解決策が気に入らなかった。なぜならそれは正しいことではなかったから。
The New Jersey guy said that the Unix solution was right because the design philosophy of Unix was simplicity and that the right thing was too complex. Besides, programmers could easily insert this extra test and loop. The MIT guy pointed out that the implementation was simple but the interface to the functionality was complex. The New Jersey guy said that the right tradeoff has been selected in Unix -- namely, implementation simplicity was more important than interface simplicity.New Jersey派の男はこう言った。Unixの解決策は正しい、なぜならUnixの設計哲学は単純さであり、正しいことはあまりに複雑だからと。その上、プログラマがこの余分のテストとループを付け加えるのは簡単だった。MIT派の男は、実装は単純だが機能へのインタフェースは複雑だと指摘した。New Jersey派の男は、Unixでは正しいトレードオフが選択されていると言った――すなわち、実装の単純さがインタフェースの単純さよりも重要なのだと。
The MIT guy then muttered that sometimes it takes a tough man to make a tender chicken, but the New Jersey guy didn’t understand (I’m not sure I do either).MIT派の男はそこで、柔らかい鶏料理を作るには屈強な男が必要なこともあるのだとぶつぶつ文句を言ったが、New Jersey派の男は意味が分からなかった（私にも分かっているかどうか定かではない）
Now I want to argue that worse-is-better is better. C is a programming language designed for writing Unix, and it was designed using the New Jersey approach. C is therefore a language for which it is easy to write a decent compiler, and it requires the programmer to write text that is easy for the compiler to interpret. Some have called C a fancy assembly language. Both early Unix and C compilers had simple structures, are easy to port, require few machine resources to run, and provide about 50%-80% of what you want from an operating system and programming language.さて私はworse-is-betterの優位を主張したい。CはUnixを書くために設計されたプログラミング言語であり、New Jerseyアプローチを用いて設計された。よってCはそれ自身のまずまずのコンパイラを書くのが容易な言語で、コンパイラにとって翻訳しやすいテキストを書くようプログラマに要求する。Cのことを飾り付きのアセンブリ言語と呼んだ人もいた。初期のUnixとCコンパイラはどちらも簡単な構造で、移植が容易で、動作するのにわずかな資源しか必要とせず、オペレーティングシステムとプログラミング言語に対して我々が求めるものの50-80%ほどを提供した。
Half the computers that exist at any point are worse than median (smaller or slower). Unix and C work fine on them. The worse-is-better philosophy means that implementation simplicity has highest priority, which means Unix and C are easy to port on such machines. Therefore, one expects that if the 50% functionality Unix and C support is satisfactory, they will start to appear everywhere. And they have, haven’t they?どの時点でも、存在するコンピュータの半分は平均よりも劣っている（小さいかまたは遅い）。UnixとCはそういったコンピュータ上でも満足に動く。worse-is-better哲学とは、実装の単純さが最高の優先度を持つということであり、それはUnixとCがそういったマシンに移植しやすいということだ。したがって、UnixとCがサポートする50%の機能で満足であるなら、あらゆるところに普及するだろう。そして実際にそうなった、違うだろうか？
Unix and C are the ultimate computer viruses.UnixとCは究極のコンピュータウイルスである。
A further benefit of the worse-is-better philosophy is that the programmer is conditioned to sacrifice some safety, convenience, and hassle to get good performance and modest resource use. Programs written using the New Jersey approach will work well both in small machines and large ones, and the code will be portable because it is written on top of a virus.worse-is-better哲学から得られるさらなる利益は、いくらかの安全と利便性を犠牲にして、効率の良さと控えめなリソース消費を実現するよう、プログラマが条件付けされるということだ。New Jerseyアプローチを用いて書かれたプログラムは小さなマシンと大きなマシンの両方でうまく動作する。そしてコードは可搬になる。ウイルスの上に載せる形で書かれるからだ。
It is important to remember that the initial virus has to be basically good. If so, the viral spread is assured as long as it is portable. Once the virus has spread, there will be pressure to improve it, possibly by increasing its functionality closer to 90%, but users have already been conditioned to accept worse than the right thing. Therefore, the worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing. In concrete terms, even though Lisp compilers in 1987 were about as good as C compilers, there are many more compiler experts who want to make C compilers better than want to make Lisp compilers better.最初のウイルスは基本的に良いものでなければいけないということを覚えておくことは大事だ。もしそうであれば、ウイルスに可搬性がある限りその拡散は保証される。いったんウイルスが広まったら、それを改良しようとする圧力が生じるだろう。おそらく機能を90%近くまで増強することによって。しかしユーザは既にthe right thingよりも悪いものを受け入れるよう条件付けされている。よって、worse-is-betterソフトウェアはまず受け入れられて、次にユーザが多くを望まないように条件付けし、その次にほとんどthe right thingに近いところまで改善されるだろう。具体的に言うと、1987年のLispコンパイラはCコンパイラと同じくらい優秀だったけれども、Cコンパイラを改善したいと思うコンパイラの専門家のほうが、Lispコンパイラを改善したい専門家よりもずっと多いのだ。
The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++.良い知らせは、1995年には我々は優秀なオペレーティングシステムとプログラミング言語を手にしているだろうということだ。悪い知らせは、それがUnixとC++だろうということだ。
There is a final benefit to worse-is-better. Because a New Jersey language and system are not really powerful enough to build complex monolithic software, large systems must be designed to reuse components. Therefore, a tradition of integration springs up.worse-is-betterの利点の最後の一つはこれだ。New Jerseyな言語とシステムには、複雑で一枚岩のソフトウェアを構築するだけの強力さが欠けているので、大規模システムはコンポーネントを再利用するよう設計されなければならない。よって、統合にまつわるよくある話が持ち上がる。
How does the right thing stack up? There are two basic scenarios: the big complex system scenario and the diamond-like jewel scenario.the right thingと比べるとどうだろう？ 基本的なシナリオは2つある：巨大で複雑なシステムというシナリオと、ダイアモンドのような宝石というシナリオだ。
The big complex system scenario goes like this:巨大で複雑なシステムのシナリオはこのようなものだ：
First, the right thing needs to be designed. Then its implementation needs to be designed. Finally it is implemented. Because it is the right thing, it has nearly 100% of desired functionality, and implementation simplicity was never a concern so it takes a long time to implement. It is large and complex. It requires complex tools to use properly. The last 20% takes 80% of the effort, and so the right thing takes a long time to get out, and it only runs satisfactorily on the most sophisticated hardware.まず、the right thingが設計される必要がある。そしてその実装が設計される必要がある。最後にそれは実装される。それはthe right thingなので、要求された機能のほぼ100%を備え、実装の単純さは全く考慮されないので実装には長い期間がかかる。それは大きくて複雑なものになる。正しく利用するためには複雑なツールを必要とする。最後の20%が労力の80%を必要とし、そのためにthe right thingは出荷されるまでに長い時間がかかり、最も洗練されたハードウェア上でしか満足に動作しない。
The diamond-like jewel scenario goes like this:ダイアモンドのような宝石のシナリオはこのようなものだ：
The right thing takes forever to design, but it is quite small at every point along the way. To implement it to run fast is either impossible or beyond the capabilities of most implementors.The right thingは設計に永遠の時間がかかるが、過程のどの時点においても非常に小さい。それを高速に動作するように実装するのは、不可能か、そうでなくてもほとんどの実装者の能力を超えている。
The two scenarios correspond to Common Lisp and Scheme.この2つのシナリオに相当するのがCommon LispとSchemeだ。
The first scenario is also the scenario for classic artificial intelligence software.最初のシナリオは古典的な人工知能ソフトウェアのシナリオでもある。
The right thing is frequently a monolithic piece of software, but for no reason other than that the right thing is often designed monolithically. That is, this characteristic is a happenstance.The right thingはしばしば一枚岩のソフトウェアだが、the right thingがしばしば一枚岩に設計されていることの理由はそれ以外には存在しない。つまり、この特徴は偶然によるものだ。
The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing.ここから学ぶべき教訓は、最初からthe right thingを目指すのは望ましくない場合がしばしばあるということだ。ウイルスのように広がるよう、the right thingの半分を提供するほうがよい。いったん人々が引っかかって夢中になったら、時間をかけてthe right thingの90%まで改善するのだ。
A wrong lesson is to take the parable literally and to conclude that C is the right vehicle for AI software. The 50% solution has to be basically right, and in this case it isn’t.誤った教訓は、この寓話を文字通りに受け取って、AIソフトウェアを実現する正しい手段はCであると結論づけることだ。50%の解決策は基本的には正しくなければならず、この場合にはそれは正しくない。
But, one can conclude only that the Lisp community needs to seriously rethink its position on Lisp design. I will say more about this later.しかし、LispコミュニティはLispの設計に関する態度を真剣に考え直す必要がある、とだけ結論付けることも可能だ。これについては後で詳しく述べる。
Many Lisp enthusiasts believe that Lisp programming is easy. This is true up to a point. When real applications need to be delivered, the code needs to perform well. With C, programming is always difficult because the compiler requires so much description and there are so few data types. In Lisp it is very easy to write programs that perform very poorly; in C it is almost impossible to do that. The following examples of badly performing Lisp programs were all written by competent Lisp programmers while writing real applications that were intended for deployment. I find these quite sad.多くのLispファンはLispプログラミングは簡単だと確信している。これはある点までは真実だ。本物のアプリケーションを納品しなければならない時、コードの効率が良好である必要がある。Cでは、プログラミングは常に難しい。というのも、コンパイラはあまりに多くの記述を要求し、データ型があまりに少ないからだ。Lispでは効率がひどいプログラムを書くのはとても簡単だ。Cではそれはほとんど不可能だ。以降に挙げる非効率なLispプログラムの例は、優秀なLispプログラマによって、実運用のための本物のアプリケーションを書く過程で書かれたものだ。私はこれらをとても残念に思う。
This example is a mistake that is easy to make. The programmer here did not declare his arrays as fully as he could have. Therefore, each array access was about as slow as a function call when it should have been a few instructions. The original declaration was as follows:この例は犯しやすい誤りだ。このプログラマは配列を完全な形で宣言すべきであったのにそうしなかった。よって、配列へのアクセスは毎回数命令で済むはずだったところが関数呼び出しと同じくらい遅くなった。オリジナルの宣言は次のようだった：
(proclaim '(type (array fixnum *) *ar1* *ar2* *ar3*))
The three arrays happen to be of fixed size, which is reflected in the following correct declaration:3つの配列は偶然にも固定長で、それが次の正しい宣言には反映されている：
(proclaim '(type (simple-array fixnum (4)) *ar1*))
(proclaim '(type (simple-array fixnum (4 4)) *ar2*))
(proclaim '(type (simple-array fixnum (4 4 4)) *ar3*))
Altering the faulty declaration improved the performance of the entire system by 20%.誤った宣言を変更すると、システム全体のパフォーマンスが20%改善された。
The next example is where the implementation has not optimized a particular case of a general facility, and the programmer has used the general facility thinking it will be fast. Here five values are being returned in a situation where the order of side effects is critical:次の例は、一般的な機能の特殊なケースを実装が最適化していないところで、プログラマが高速だろうと考えて一般的な機能を使ったというものだ。ここでは、副作用の順序が決定的な影響を持つ状況で、5つの値が返されている：
(multiple-value-prog1
(values (f1 x)
(f2 y)
(f3 y)
(f4 y)
(f5 y))
(setf (aref ar1 i1) (f6 y))
(f7 x y))
The implementation happens to optimize multiple-value-prog1 for up to three return values, but the case of five values CONSes. The correct code follows:この実装は偶然multiple-value-prog1を3つの戻り値までは最適化するようにできていたが、5つの値の場合にはCONSするようになっていた。正しいコードは次のようになる：
(let ((x1 (f1 x))
(x2 (f2 y))
(x3 (f3 y))
(x4 (f4 y))
(x5 (f5 y)))
(setf (aref ar1 i1) (f6 y))
(f7 x y)
(values x1 x2 x3 x4 x5))
There is no reason that a programmer should know that this rewrite is needed. On the other hand, finding that performance was not as expected should not have led the manager of the programmer in question to conclude, as he did, that Lisp was the wrong language.この書き換えが必要であるとプログラマが知っているべきである理由は何もない。その一方で、パフォーマンスが期待したほどではないと分かったとしても、問題となっているプログラマのマネージャは、（彼がそうしてしまったように）Lispが間違った言語だと結論付けるべきではなかった。
Some Common Lisp compilers do not optimize the same way as others. The following expression is sometimes used:Common Lispコンパイラのなかには最適化を他と同じようには行わないものがある。次の表現はたまに使われることがある：
(* -1 <form>)
when compilers often produce better code for this variant:ただし次のような書き方をしたほうがコンパイラがより良いコードを生成することが多い場合に、だ：
(- <form>)
Of course, the first is the Lisp analog of the FORTRAN idiom:もちろん、最初のものはFORTRANのイディオムをLispで近似したものだ：
- -1*<form>
Some might find this example hard to believe. This really occurred in some code I’ve seen:この例は信じるられないと思う人がいるかもしれない。これは私が見たなかで本当にあったコードだ：
(defun make-matrix (n m)
(let ((matrix ()))
(dotimes (i n matrix)
(push (make-list m) matrix))))
(defun add-matrix (m1 m2)
(let ((l1 (length m1))
(l2 (length m2)))
(let ((matrix (make-matrix l1 l2)))
(dotimes (i l1 matrix)
(dotimes (j l2)
(setf (nth i (nth j matrix))
(+ (nth i (nth j m1))
(nth i (nth j m2)))))))))
What’s worse is that in the particular application, the matrices were all fixed size, and matrix arithmetic would have been just as fast in Lisp as in FORTRAN.さらに悪いことに、その特定のアプリケーションの中では行列はすべて固定サイズで、行列演算はLispでもFORTRANと同じくらいに高速だったろうということだ。
This example is bitterly sad: The code is absolutely beautiful, but it adds matrices slowly. Therefore it is excellent prototype code and lousy production code. You know, you cannot write production code as bad as this in C.この例は苦々しく残念なものだ：コードは完璧に美しいのに、行列を加えるのは遅い。よってプロトタイプとしては素晴らしいが実運用コードとしては役に立たない。あなた方も知っているように、Cではこんなにひどいプロダクションコードを書くことはできない。
In the worse-is-better world, integration is linking your .o files together, freely intercalling functions, and using the same basic data representations. You don’t have a foreign loader, you don’t coerce types across function-call boundaries, you don’t make one language dominant, and you don’t make the woes of your implementation technology impact the entire system.worse-is-betterの世界では、統合とは、自由に関数を相互に呼び出して、同じ基本的なデータ表現を使って、.oファイルを結合することだ。他の言語のローダなどはないし、関数呼び出しの境界を越えて型を強制変換することもないし、あるひとつの言語を支配的な立場に置くこともないし、自分の実装技術がシステム全体に影響を与えてしまうことを嘆くこともない。
The very best Lisp foreign functionality is simply a joke when faced with the above reality. Every item on the list can be addressed in a Lisp implementation. This is just not the way Lisp implementations have been done in the right thing world.最も優れたLispの他言語関数呼び出し機能も、そういった現実に直面した場合にはただのジョークだ。Lisp実装では、リスト上のどの要素もアドレスされうる。これは、Lisp実装がthe right thingの世界で作られた流儀とは、ただただ違うのだ。
The virus lives while the complex organism is stillborn. Lisp must adapt, not the other way around. The right thing and 2 shillings will get you a cup of tea.複雑な組織が死産に終わるのを横目に、ウイルスは生き延びる。Lispは適合しなければならない。その逆ではない。The right thingしか頭にないのではだめなのだ。
This is hard to face up to. For example, most C environments -- initially imitative of Lisp environments -- are now pretty good. Current best C environments have the following:これを認めるのは辛いことだ。例えば、ほとんどのC環境は――最初はLisp環境の真似だったものが――今では非常に良くなっている。現時点で最高のC環境は次のものを備えている：
And soon they will have incremental compilation and loading. These environments are easily extendible to other languages, with multi-lingual environments not far behind.もうすぐインクリメンタルなコンパイルとロードを備えることだろう。これらの環境は他の言語用にも容易に拡張できる。多言語環境も遠からず実現するだろう。
Though still the best, current Lisp environments have several prominent failures. First, they tend to be window-based but not well integrated. That is, related information is not represented so as to convey the relationship. A multitude of windows does not mean integration, and neither does being implemented in the same language and running in the same image. In fact, I believe no currently available Lisp environment has any serious amount of integration.いまだに最高のものではあるが、現在のLisp環境にはいくつかの目立った失敗がある。第1に、ウィンドウベースであることが多いが、あまりうまく統合されていない。すなわち、関連した情報が、関係が分かるように表現されていないのだ。ウィンドウがたくさんあれば統合されているというわけではないし、同じ言語で実装されて同じイメージ内で動作しているからといって統合されているわけではない。実際のところ、現在手に入るLisp環境で高度な統合を成し遂げているものはないと私は思う。
Second, they are not persistent. They seemed to be defined for a single login session. Files are used to keep persistent data -- how 1960s.第2に、永続性がない。単一のログインセッション向けに作られたように見える。永続的なデータを保持するためにはファイルが使われている――なんて1960年代的なんだ。
Third, they are not multi-lingual even when foreign interfaces are available.第3に、他の言語のインタフェースが提供されている場合ですら、多言語化がなされていない。
Fourth, they do not address the software lifecycle in any extensive way. Documentation, specifications, maintenance, testing, validation, modification, and customer support are all ignored.第4に、ソフトウェアのライフサイクルを拡張可能なやり方で扱えない。ドキュメンテーション、仕様、メンテナンス、テスティング、検証（validation）、変更、および顧客サポートがことごとく無視されている。
Fifth, information is not brought to bear at the right times. The compiler is able to provide some information, but the environment should be able to generally know what is fully defined and what is partially defined. Performance monitoring should not be a chore.第5に、情報が正しいタイミングで提供されない。コンパイラは何らかの情報を提供できるが、環境は一般的に何が完全に定義されており何が部分的に定義されているか知ることが可能なはずだ。パフォーマンスモニタリングが退屈な作業であってはならない。
Sixth, using the environment is difficult. There are too many things to know. It’s just too hard to manage the mechanics.第6に、環境を利用するのが難しい。知るべきことが多すぎる。操作するだけでも、ただただ大変すぎる。
Seventh, environments are not multi-user when almost all interesting software is now written in groups.第7に、興味深いソフトウェアは今やほとんどすべてがグループで書かれるという時代だというのに、Lisp環境はマルチユーザではない。
The real problem has been that almost no progress in Lisp environments has been made in the last 10 years.本当の問題は、この10年間Lisp環境にはほとんど何の進歩もなかったということだ。
When the sun comes up, I’ll be on top.
You’re right down there looking up.
On my way to come up here,
I’m gonna see you waiting there.
I’m on my way to get next to you.
I know now that I’m gonna get there.
? & The Mysterians
The gloomy interlude can have a happy ending.幕間が憂鬱だったとしても、ハッピーエンドを迎えられる。
We need to bury our differences at the ISO level and realize that there is a short term need, which must be Common Lisp, and a long term need, which must address all the issues for practical applications.我々はISOレベルで差異を埋める必要があり、短期的な需要と長期的な需要が存在することを認識する必要がある。短期的な需要はCommon Lispに違いなく、長期的な需要は実用的なアプリケーションに関係した問題に対処するものであるに違いない。
We’ve seen that the right thing attitude has brought us a very large, complex-to-understand, and complex-to-implement Lisp -- Common Lisp that solves way too many problems. We need to move beyond Common Lisp for the future, but that does not imply giving up on Common Lisp now. We’ve seen it is possible to do delivery of applications, and I think it is possible to provide tools that make it easier to write applications for deployment. A lot of work has gone into getting Common Lisp to the point of a right thing in many ways, and there are viable commercial implementations. But we need to solve the delivery and integration problems in spades.the right thingという考え方（attitude）は、非常に大きく理解するのも実装するのも難しいLispをもたらした――あまりに多くの問題を解決する、Common Lispを。我々は未来に向かってCommon Lispを超えていかなければならないが、それは今あるCommon Lispに見切りをつけるということではない。それがアプリケーションを納品することが可能であることを我々は見てきた。そして展開向けのアプリケーションをもっと簡単に書けるようにしてくれるツールを提供することは可能だと私は考える。Common Lispをいろいろな意味でright thingなところまで到達させるために多くの労力が払われた。その結果、成熟した商用の実装がある。しかし我々は納品と統合の問題を問答無用で解決する必要がある。
Earlier I characterized the MIT approach as often yielding stillborn results. To stop Common Lisp standardization now is equivalent to abortion, and that is equivalent to the Lisp community giving up on Lisp. If we want to adopt the New Jersey approach, it is wrong to give up on Lisp, because C just isn’t the right language for AI.先に私はMITアプローチの特徴を、しばしば死産にいたるやり方だと言った。Common Lispの標準化を今止めるのは堕胎するに等しく、LispコミュニティにとってはLispを見捨ててしまうことに等しい。もし我々がNew Jerseyアプローチを受け入れるのならば、Lispを見捨ててしまうのは間違っている。なぜならCは明らかにAIのための正しい言語ではないからだ。
It also simply is not possible to dump Common Lisp now, work on a new standard, and then standardize in a timely fashion. Common Lisp is all we have at the moment. No other dialect is ready for standardization.またCommon Lispを今投げ捨ててしまって新しい標準に取り組み、早々に標準化を済ませることも、率直に言って不可能だ。現在我々が手にしているのはCommon Lispだけだ。他の方言で標準化の準備ができているものはない。
Scheme is a smaller Lisp, but it also suffers from the MIT approach. It is too tight and not appropriate for large-scale software. At least Common Lisp has some facilities for that.Schemeはより小さなLispだが、これもまたMITアプローチの弊害に苦しんでいる。あまりに窮屈で、大規模なソフトウェアに適していない。少なくともCommon Lispにはそれに立ち向かうための機構がある。
I think there should be an internationally recognized standard for Common Lisp. I don’t see what is to be gained by aborting the Common Lisp effort today just because it happens to not be the best solution to a commercial problem. For those who believe Lisp is dead or dying, what does killing off Common Lisp achieve but to convince people that the Lisp community kills its own kind? I wish less effort would go into preventing Common Lisp from becoming a standard when it cannot hurt to have several Lisp standards.私が思うに、国際的に認知されたCommon Lispの標準があるべきだ。それがたまたま商売上の問題に対する最良の解決策でないからといって、今日のCommon Lispへの取り組みを捨てて何が得られるのか、私には分からない。Lispが死んだか死にゆくものだと信じている人々には、私はこう言いたい。Common Lispを殺してしまうということが、Lispコミュニティが同族殺しをしていると人々を確信させる以外に何を達成するというのか。複数のLisp標準があってもいっこうに構わないのだから、Common Lispが標準となることが邪魔立てされないよう私は望む。
On the other hand, there should be a strong effort towards the next generation of Lisp. The worst thing we can do is to stand still as a community, and that is what is happening.一方で、次世代のLispに向かう強力な取り組みもあってしかるべきだ。今私たちにできる最悪のことは、コミュニティとして何もせず突っ立っていることだ。そしてそれこそが実際に起きていることなのだ。
All interested parties must step forward for the longer-term effort.関係団体はすべて長期的な取り組みに向かって歩を進めるべきだ。
I think there is a mistake in following an environment path that creates monolithic environments. It should be possible to use a variety of tools in an environment, and it should be possible for those who create new tools to be able to integrate them into the environment.環境に関して、一枚岩の環境を構築しようという道を選ぶのは間違いだと私は考える。環境ではさまざまなツールを使えてしかるべきだし、新しいツールを作った人がそれを環境に統合できてしかるべきだ。
I believe that it is possible to build a tightly integrated environment that is built on an open architecture in which all tools, including language processors, are protocol-driven. I believe it is possible to create an environment that is multi-lingual and addresses the software lifecycle problem without imposing a particular software methodology on its users.言語処理系を含めてすべてのツールがプロトコル駆動であるオープンなアーキテクチャの上に、緊密に統合された環境を構築するのは可能だと私は考える。多言語に対応していて、ユーザに特定のソフトウェア方法論を押し付けることなくソフトウェアライフサイクルを扱うことができる環境を作り出すことは可能だと私は考える。
Our environments should not discriminate against non-Lisp programmers the way existing environments do. Lisp is not the center of the world.我々の環境は、既存の環境がしているように、非Lispプログラマを差別するものであってはならない。Lispは世界の中心ではないのだ。
Even though Common Lisp is not structured as a kernel plus libraries, it can be implemented that way. The kernel and library routines can be in the form of .o files for easy linking with other, possibly non-Lisp, modules; the implementation must make it possible to write, for example, small utility programs. It is also possible to piggyback on existing compilers, especially those that use common back ends. It is also possible to implement Lisp so that standard debuggers, possibly with extensions, can be made to work on Lisp code.Common Lispはカーネルとライブラリの組み合わせとしては構成されていないが、そのように実装することはできる。カーネルとライブラリルーチンは他の（非Lispかもしれない）モジュールとリンクしやすいよう.oファイルの形にしておけばよい。この実装は例えば小さなユーティリティプログラムを書くことが可能でなければならない。また、既存のコンパイラ、特に共通のバックエンドを使うものに頼る形にすることも可能だ。Lispコードに対して（おそらく拡張を追加することで）標準のデバッガを使えるようにLispを実装することも可能だ。
It might take time for developers of standard tools to agree to extend their tools to Lisp, but it certainly won’t happen until our (exceptional) language is implemented more like ordinary ones.標準ツールの開発者たちがLisp向けに彼らのツールを拡張することに同意してくれるには時間がかかるかもしれないが、我々の（例外的な）言語がもっと普通の言語と同じように実装されない限り、それは全く起こり得ないのだ。
I believe it is possible to implement a Lisp and surrounding environment which has no discrimination for or against any other language. It is possible using multi-lingual environments, clever representations of Lisp data, conservative garbage collection, and conventional calling protocols to make a completely integrated Lisp that has no demerits.Lispとそれを取り囲む環境を、他の言語に対するひいきや差別がないものとして実装することは可能だと私は考える。多言語環境、Lispデータの気の利いた表現、保守的なガーベジコレクション、および慣習的（conventional）な呼び出しプロトコルを利用して、完璧に統合されたデメリットのないLisp環境を作ることは可能だと私は考える。
Lisp is still the best prototyping language. We need to push this forward. A multi-lingual environment could form the basis or infrastructure for a multi-lingual prototyping system. This means doing more research to find new ways to exploit Lisp’s strengths and to introduce new ones.Lispはいまだに最高のプロトタイピング言語だ。我々はこれをさらに押し進める必要がある。多言語環境は多言語のプロトタイピングシステムの基礎ないし基盤となりうる。すなわち、Lispの長所を生かす新しい方法を見つけ、そして新しい強みを取り入れるために、さらなる研究を行うということだ。
Prototyping is the act of producing an initial implementation of a complex system. A prototype can be easily instrumented, monitored, and altered. Prototypes are often built from disparate parts that have been adapted to a new purpose. Descriptions of the construction of a prototype often involve statements about modifying the behavioral characteristics of an existing program. For example, suppose there exists a tree traversal program. The description of a prototype using this program might start out by saying something likeプロトタイピングは複雑なシステムの初期的な実装を作るという行為だ。プロトタイプは試験・監視・変更が簡単にできる。プロトタイプは新しい目的に合わせて作られた異質な部品から作られることがよくある。プロトタイプの作成を説明する際には、既存のプログラムの振る舞いを変更するという表現が用いられることがよくある。例えば、ツリーをトラバースするプログラムがあるとする。このプログラムを用いたプロトタイプの説明は、このような言い回しで始まるかもしれない：
let S1 be the sequence of leaf nodes visited by P on tree T1 and S2 the
leaf nodes visited by P on tree T2. Let C be a correspondence between
S1 and S2 where f: S1 ! S2 maps elements to corresponding elements.
ツリーT1上でPが訪れるリーフノードのシーケンスをS1とし、
ツリーT2上でPが訪れるリーフノードをS2とする。S1とS2の間の対応関係を
Cとする（f: S1 ! S2 が要素を対応する要素にマップするものとする）。
Subsequent statements might manipulate the correspondence and use f. Once the definition of a leaf node is made explicit, this is a precise enough statement for a system to be able to modify the traversal routine to support the correspondence and f.続く文章は対応関係を操作し、fを用いるものになるかもしれない。いったんリーフノードの定義が明確になれば、システムが対応関係とfをサポートするようにトラバースルーチンを変更するために十分に正確な記述になる。
A language that describes the modification and control of an existing program can be termed a program language. Program languages be built on one or several underlying programming languages, and in fact can be implemented as part of the functionality of the prototyping environment. This view is built on the insight that an environment is a mechanism to assist a programmer in creating a working program, including preparing the source text. There is no necessary requirement that an environment be limited to working only with raw source text. As another example, some systems comprise several processes communicating through channels. The creation of this part of the system can be visual, with the final result produced by the environment being a set of source code in several languages, build scripts, link directives, and operating system calls. Because no single programming language encompasses the program language, one could call such a language an epi-language.既存のシステムの変更と制御を記述する言葉は、プログラム言語（program language）と呼ばれうる。プログラム言語は一つないし複数の下位にあるプログラミング言語（programming language）の上に構築され、実際にプロトタイピング環境の機能の一部として実装されうる。この視点は、環境とは、ソーステキストを作成することも含めて、プログラマが動作するプログラムを生み出すことを支援する仕組みであるという洞察に基づいている。環境が生のソーステキストを扱うことだけに制限される必要はない。また別の例として、チャネルを通してやり取りするいくつかのプロセスから成るシステムもある。システムのこの部分を作り出すのは視覚的であってもよい。それに付随して環境によって作り出される最終的な結果は、いくつかの言語で書かれた一連のソースコードと、ビルドスクリプトと、リンク命令と、オペレーティングシステムのシステムコールとなる。プログラム言語は単一のプログラミング言語でできているわけではないので、そのような言語はエピ言語（epi-language; 間言語）と呼んでもよいだろう。
I think there will be a next Lisp. This Lisp must be carefully designed, using the principles for success we saw in worse-is-better.来るべき次世代のLispというものがあると私は考えている。このLispは、我々がworse-is-betterに見た成功の原則を用いて、注意深く設計されねばならない。
There should be a simple, easily implementable kernel to the Lisp. That kernel should be both more than Scheme -- modules and macros -- and less than Scheme -- continuations remain an ugly stain on the otherwise clean manuscript of Scheme.単純で容易に実装できる、Lispのカーネルとなるものが必要だ。そのカーネルは、Scheme――モジュールとマクロ――を超えるものでありと同時に、Scheme――継続が、それさえなければきれいなSchemeの手稿についた醜いしみとなって残っている――よりも小さなものでなければならない。
The kernel should emphasize implementational simplicity, but not at the expense of interface simplicity. Where one conflicts with the other, the capability should be left out of the kernel. One reason is so that the kernel can serve as an extension language for other systems, much as GNU Emacs uses a version of Lisp for defining Emacs macros.カーネルは実装上の単純さを重視すべきだが、インタフェースの単純さを犠牲にしてはならない。一方が他方と衝突するところでは、機能はカーネルの外に置かれるべきだ。一つの理由は、カーネルが他のシステムの拡張用言語として使われうるようにだ。ちょうどGNU EmacsがLispの一種を使ってEmacsマクロを定義しているように。
Some aspects of the extreme dynamism of Common Lisp should be reexamined, or at least the tradeoffs reconsidered. For example, how often does a real program do this?Common Lispの極端に動的な性質のなかには、再考されるべき側面がある。そうでなくても、少なくともトレードオフは再検討されるべきだ。例えば、本物のプログラムがこのようにすることは、どれだけあるだろうか？
(defun f ...)
(dotimes (...)
...
(setf (symbol-function 'f) #'(lambda ...))
...)
Implementations of the next Lisp should not be influenced by previous implementations to make this operation fast, especially at the expense of poor performance of all other function calls.来るべきLispの実装は、この演算を高速化するために従来の実装からの影響を受けるべきではない。特に、他のすべての関数呼び出しの効率が悪くなるような犠牲を払ってはならない。
The language should be segmented into at least four layers:言語は少なくとも4つの層に分割されるべきだ：
In the first layer I include conditionals, function calling, all primitive data structures, macros, single values, and very basic object-oriented support.1番目の層に私は、条件式、関数呼び出し、すべての基礎データ構造、マクロ、単値、非常に基礎的なオブジェクト指向のサポートを含める。
In the second layer I include multiple values and more elaborate object-oriented support. The second layer is for difficult programming constructs that are too important to leave to environments to provide, but which have sufficient semantic consequences to warrant precise definition. Some forms of redefinition capabilities might reside here.2番目の層に私は、多値とより進んだオブジェクト指向サポートを含める。2番目の層は、環境が提供するに任せるにはあまりに重要すぎる、難易度が高いプログラミング上の構造、しかしそれでいて正確な定義を正当化するだけの意味論的な重要性が十分にある、そういうもののためにある。何らかの形の再定義機能はここに置かれるかもしれない。
In the third layer I include sequence functions, the elaborate IO functions, and anything else that is simply implemented in the first and possibly the second layers. These functions should be linkable.3番目の層に私は、シーケンス関数、手の込んだ入出力関数、その他1番目の層と2番目の層に単純に実装できなかったものすべてを含める。これらの関数はリンク可能であるべきだ。
In the fourth layer I include those capabilities that an environment can and should provide, but which must be standardized. A typical example is defmethod from CLOS. In CLOS, generic functions are made of methods, each method applicable to certain classes. The first layer has a definition form for a complete generic function -- that is, for a generic function along with all of its methods, defined in one place (which is how the layer 1 compiler wants to see it). There will also be means of associating a name with the generic function. However, while developing a system, classes will be defined in various places, and it makes sense to be able to see relevant (applicable) methods adjacent to these classes. defmethod is the construct to define methods, and defmethod forms can be placed anywhere amongst other definitional forms.4番目の層に私は、環境が提供でき、またそうすべきであるが、標準化されなければならない機能を含める。典型的な例はCLOSのdefmethodだ。CLOSでは、総称関数はメソッドから成っており、各メソッドは特定のクラスに適用可能である。1番目の層には完全な総称関数のための定義式――つまり総称関数およびその全メソッドの定義が一箇所に集まったもの――がある（第1層のコンパイラがそれらをどう見たいかを反映している）。名前を総称関数に結び付ける手段も用意される。しかしながら、システムを発展させていく途上で、クラスはさまざまな場所で定義され、関連した（適用可能な）メソッドがクラスの隣に見えたほうが道理にかなっている。メソッドを作るその仕組みはdefmethodで、defmethod式は他の定義式の中のどこにでも置ける。
But methods are relevant to each class on which the method is specialized, and also to each subclass of those classes. So, where should the unique defmethod form be placed? The environment should allow the programmer to see the method definition in any or all of these places, while the real definition should be in some particular place. That place might as well be in the single generic function definition form, and it is up to the environment to show the defmethod equivalent near relevant classes when required, and to accept as input the source in the form of a defmethod (which it then places in the generic function definition).しかしメソッドは、そのメソッドが特殊化された（specialized）クラスのそれぞれについて、そしてそれらのクラスのサブクラスのそれぞれについて関連している。であれば、ユニークなdefmethod式はどこに置くべきだろう？ 本当の定義はどこか特定の場所に置かれるべきである一方で、環境はプログラマがこれらの場所のどこからでもメソッド定義を見られるようにすべきだ。その場所は単一の総称関数の定義式にあってもよく、必要に応じてdefmethodの同等品を関係したクラスの近くに見せ、defmethodの形式のソースを入力として受け入れる（そして総称関数の定義にそれを置く）ことは、環境の仕事だ。
We want to standardize the defmethod form, but it is a linguistic feature provided by the environment. Similarly, many uses of elaborate lambda-list syntax, such as keyword arguments, are examples of linguistic support that the environment can provide possibly by using color or other adjuncts to the text.我々はdefmethod式を標準化したいが、それは環境によって提供される言語学的な機能だ。同様に、例えばキーワード引数のように、手の込んだlambdaリスト構文の多用は、環境がテキストを修飾する色などを使って提供することが可能な、言語学的なサポートの例だ。
In fact, the area of function-function interfaces should be re-examined to see what sorts of argument naming schemes are needed and in which layer they need to be placed.実際、関数対関数のインタフェースの分野では、引数に名前を付ける方法としてどのようなものが必要か、そしてどの層にそれを配置すべきか、再検討すべきだ。
Finally, note that it might be that every layer 2 capability could be provided in a layer 1 implementation by an environment.最後に、第2層の機能はすべて、環境によって第1層の機能として提供されうるかもしれないことに注意してほしい。
The Lisp community has too few application writers. The Lisp vendors need to make sure these application writers win. To do this requires that the parties involved be open about their problems and not adversarial. For example, when an expert system shell company finds problems, it should open up its source code to the Lisp vendor so that both can work towards the common goal of making a faster, smaller, more deliverable product. And the Lisp vendors should do the same.Lispコミュニティにはアプリケーションを書く人間があまりに少ない。Lispベンダはこれらのアプリケーションの書き手が成功することを確実にする必要がある。これを実現するには、関連する各陣営が自分たちの抱える問題に関して、敵対的ではなくオープンである必要がある。例えば、エキスパートシステムシェルの企業が問題を発見したならば、Lispベンダに自分たちのソースコードを開示して、より高速でより小さくより納品が容易な製品を作るという共通のゴールに向かって両者が働けるようにすべきだ。そしてLispベンダも同様にすべきだ。
The business leadership of the AI community seems to have adopted the worst caricature-like traits of business practice: secrecy, mistrust, run-up-the-score competitiveness. We are an industry that has enough common competitors without searching for them among our own ranks.AIコミュニティのビジネスのリーダーたちは、ビジネス慣行のうちでも最悪の、まるで風刺画のような気質を選んでしまったようだ：秘密主義、不信、弱い者を叩くことも辞さぬ点数稼ぎ式の競争心。我々の業界では、自分と同程度の相手を探すまでもなく、万人にとっての商売敵が十分にいるのだ。
Sometimes the sun also rises.日がまた昇るときもある（Sometimes the sun also rises）。