これらの古いLispに対する古い批判のうち、今日でもなお当てはまるものはどれですか？

Common LispのA批判 1984年にスタンフォード大学からのロドニー・ブルックスA.とリチャードP.ガブリエルによって書かれた、いくつかの設計上の決定が議論されているのCommon Lispの正規化委員会によって保持しました。議論の大部分は有効なままですが、その時点で利用可能な技術に言及しており、今日は間違っている可能性がある2つの声明があります。

これらの2つのステートメントは次のとおりです。

言語のコストが多すぎると、「優れたコンパイラーなら誰でも世話をすることができる」という警告で却下されました。誰もまだ書かれていません-また、多大な努力なしに-それが期待されるトリックのほんの一部を行うコンパイラ。

私はCommon Lispの初心者であり、見習いでもあるので、著者よりも具体的になることはできません。彼らは、言語のいくつかの側面に大きな一般性と柔軟性が組み込まれているため、優れたコンパイラーの作成が非常に難しいと述べているようです。

COMMON LISPでは、浮動小数点演算の制御が少なすぎます。確かに、浮動小数点を多用するプログラムの正しい動作は実現できますが、パフォーマンスは大きく異なる場合があります。

私が理解している限りでは、Common Lispで効率的な数値コードを書くことは可能ですが、本来よりも難しいと思われます。

これは30年前です。一般的なフリーソフトウェアの実装（CLISP、SBCLなど）の1つに対してCommon Lispプログラムを作成する場合、今日これらのステートメントをどのように考慮する必要がありますか？

この論文は多くの点で興味深い。

最も興味深い部分はこれです：著者は1984年からちょうど2年後の1986年に論文を偽造しました。BrooksとGabrielは、高度に最適化されたLispコンパイラを開発し、数年間商業的に非常に成功しました。LucidCommon Lisp（PDF）。

このLispコンパイラのメンテナンスは、LispWorksから引き続き利用できます。現在、Liquid Common Lispと呼ばれています。

Liquid CLのコンパイラ最適化については、上級ユーザーガイド：Lispプログラムの最適化の第3章に記載されています。

Lucid CLにはいくつかの商用アプリケーションが記述され、展開されています。例えば、私の故郷では、HVV（Hamburger Verkehrsverbund）の最初の公共交通情報システムが、SUN SPARCstationでLucid CLを使用して展開されました。大きなタッチスクリーンを使用する駅やコールセンターで一般に利用できました。

Lucid CLは、主にUnix / RISCプラットフォーム向けに、そのプロダクションモードコンパイラが高速Common Lispアプリケーションを作成したため成功しました。

ブルックスとガブリエルは1986年にLucid Common Lispについて書いています：

動的に再ターゲット可能なコンパイラは、さまざまなLisp実装のコンパイルを簡単に実行できる手段であることが示されています。Lispシステムをさまざまなコンピューターに移植する手段。共通のソースからさまざまなコンピューター用の高品質で高性能なコードを生成するツール。

したがって、彼らはCommon Lispの批評が困難または不可能であると主張したものを実装したばかりでした。

今日、より高度な実装では多くの最適化が行われていますが、ハードウェアも1984年に比べて1000倍以上高速になっています。その範囲。Motorola 68000のクロックレートは8 MHzでした。

浮動小数点のパフォーマンスと一般に変動するパフォーマンスに関する批判は依然として有効ですが、これは実装者の選択を反映しています。一部の実装は、高性能コンパイラとして開発されていません。それらの主な焦点は、移植性、コンパクトさ、または他のものである可能性があり、したがって、それらは異なる実装目標を持っています。

ユーザー/開発者として、ポータブルコードを記述し、現在サポートされている10以上のCommon Lispシステムをすべて使用する必要はありません。アプリケーションの問題に最適な実装を使用してください。

この論文が1984年に書かれたとき、1メガバイトのRAMと20メガバイトのハードドライブを備え、机の上に座れるコンピューターは大したものでした。当然、Lispが質素なハードウェア上にあるのと同じくらい高レベルの言語の実用性をめぐって紛争が発生します。それ以降に行われたハードウェアとコンパイラの両方の技術の進歩により、言語に存在する数値の非効率性に関係なく、Lispプログラムの作成と実行がはるかに容易になりました。

プログラマは、プログラミングの効率と計算の効率を犠牲にすることがよくあります。Lispは遅い言語かもしれませんが（いくつかの実装ではそうですが、他の言語もそうです）、それはまた、急速な開発のために当然の評判があり、多くのプログラムは十分なパフォーマンスを発揮するために高度に最適化されたインフラストラクチャを必要としません。

Lisp実装の選択は、プログラムのパフォーマンスプロファイルに大きく影響します。たとえば、CLISPは「コードが非常に数値的である場合、CMUCLを好むかもしれません」とすぐに認めます。いくつかの最新のLisp（およびScheme）の実装では、数値型のヒントを指定できます。これにより、数値のパフォーマンスが向上します。

つまり、今日の状況は当時よりもはるかに良くなっています。