11

1 つずつ応答してください。

それが正しくない理由を説明する場合は、一般的な記述を避け、具体的な例を挙げてください。

4

17 に答える 17

27

すべての括弧がコードを判読不能にすること。約2週間後、まともなテキストエディタを使用すると、それらに気付くのをやめることができます。

[ETA-長年のLisperであるKennyTiltonによる引用を見つけました:「括弧?括弧は何ですか?Lispプログラミングの最初の月以来、括弧に気づいていません。Lispの括弧について不満を言う人に聞いてみたいです。新聞の単語間のすべてのスペースに悩まされています..."]

于 2008-09-24T21:16:13.200 に答える
20

Lisp はインタープリター言語なので、非常に遅いです。

Common Lisp Hyper Specの関数逆アセンブルを見てください。

SBCLと呼ばれる Common Lisp の実装には、多くのプラットフォーム用の効率的なネイティブ コンパイラ バックエンドが付属しています。

于 2008-09-24T12:10:56.223 に答える
20

私の好きな誤解: それは反復や OOP など、どんなプログラミング スタイルでも思いとどまらせる "関数型言語" だというものです。

真実からかけ離れたものはありません。

まず第一に、「Lisp」は、話者が意図する意味によっては、実際には言語ではなく、言語ファミリーです。このファミリには、多かれ少なかれよく知られていて広く知られているメンバーがいくつかあります。SchemeCommon LispEmacs-Lisp、およびAutoLispは伝統的なものです。最近では、NunewLISP (実際には最新の LISP というよりも「oldLISP」に似ていますが、ともかく)、Arc、およびClojureもあります。

確かに、Schemers は関数型スタイルを好み、反復を思いとどまらせて再帰を優先しているように見えます。しかし、私が知る限り、Schemers は実際には Lisp の世界では少数派です。少なくとも、Lisp を研究や研究の対象ではなく、プログラミング ツールとして実際に使用することを考えるとそうです。

AutoLisp や、Scheme と Common Lisp 以外のすべての Lisp の方言についてはあまり知りませんが、Common Lisp は、命令型プログラミングやオブジェクト指向プログラミングを避ける単一パラダイム言語ではないことは確かです。実際、Common Lisp は、私が知っている中で最も強力なクラスベースのオブジェクト システムを備えており、アスペクト指向プログラミングなどをすぐに組み込むことができます。

Lisp は、実際には、新しい方向への実験を最も奨励し、最初からサポートされていないプログラミング パラダイムを最も簡単に組み込む言語ファミリであるように私には思えます。これには、命令型プログラミングが含まれます。Common Lisp には GOTO もあります!

于 2008-09-24T12:19:19.667 に答える
13

人工知能のためだということ

于 2008-09-24T12:09:28.117 に答える
12

多くの人がlispはリスト指向の言語だと思っています(それが意味するものは何でも)。

lispersの間でさえ、lispの最も重要なことの1つは、consセルと、それらを使用して構築できる単一リンクリスト(sexp)であるというのが広く信じられています。lispを他の主流言語よりも生産的な言語にする本当の理由を理解していないと信じている人(これは私の主観的な意見です!)、そしてlispがなければほとんどそれが何であるかを理解していませんゲーム内の短所セル。

lispをそれが何であるかを作るために重要であり、sexpなしで簡単に実行できるもののランダムな選択:

  • REPL
  • 実行時に利用可能なコンパイラ
  • 動的型付け
  • 構文抽象化(マクロ)
  • クロージャ
  • 編集(および脳による「解析」)が簡単な単純な構文

いくつかの説明:

簡単に言えば、動的型付けとは、場所に型ではなく実行時の値があることを意味します。これは、すべての要件を事前に把握しておらず、プロジェクトの進行に伴ってアプリケーションが絶えず変化している場合に重要な助けになります。私の経験から、これははるかに多くの場合です-静的型付けが写真にある場合にのみ、はるかに多くの障害があります。

おそらく多くの人が、consセルとsexpが柔軟なマクロシステムにとって重要であると主張するでしょう。重要なのは、構文が単純で、解析されるデータ構造を操作するのが簡単なことです。sexp構文とリストを一緒にすることは良い候補ですが、他にもたくさんあります。

私はparensには満足していますが、他の部分、つまりプログラムコードを表すためにcons'dリストを使用することには満足していません。これは、重要な欠陥があるためです。データを乱さずにランダムなもので注釈を付けることはできません。それはすでにそれで表されています。たとえば、プログラムコードを表すこのようなcons'dリストに、2日前にJoeが編集したという事実を注釈として付けることはできません。その形式を、lispコンパイラにとって意味のないものに変える必要はありません。これらのアノテーションは、DSLがより複雑になり、マクロが小さなコンパイラに変わり、DSLをlispにコンパイルするにつれて、ますます重要になります。

于 2008-09-25T11:04:50.790 に答える
11

お気に入りの誤解があるかどうかはわかりませんが、プログラマーが「LISP」について話し、なぜそれを好まないのか/不適切である/アカデミックである/プロジェクト X では決して機能しないと話しているのをよく見かけます。彼らが「LISP」と言うとき、彼らが本当に意味するのは「Scheme のサブセット」を意味する「Scheme」を意味することを除いては、問題ありません。好きではなかった」。

この方向からは、Lisp(s) に対してかなりの不合理な偏見があるようです。合理的な偏見はまったく別のものです。

于 2008-09-24T21:04:32.667 に答える
8

私の好きな Lisp の誤解: CL は本当に CthuLhu を意味する!

冗談はさておき。あらゆる種類の Lisp 方言に関して最も広く普及している誤解は、s 式の構文の括弧への依存可読性を損なうというものです。他のプログラミング言語の大部分。

于 2008-09-24T12:25:28.623 に答える
6

ほとんどの誤解は、Lisp に限らず、単なる煩わしさだからです。しかし、Lisp の歴史 (特にHistory of LispThe Evolution of Lisp )を読んだときに本当に衝撃を受けた Lisp についての誤解が 1 つあります。

多くの人々にとって、Lisp は遅いインタープリター言語であることが知られていますが、実際には、最初に機能するインタープリターができてから約 1 年も経たないうちにコンパイラーができたと思います。次の履歴は、最適化を目的とした長い作業リストです。その結果、いくつかの Lisp の実装は Fortran を数の粉砕で打ち負かしました!

神話の最も可能性の高いソースは、多くの人が自分自身でインタプリタを作成するSchemeに関するCSコースからLispを知るようになることです. おそらく彼らの多くはこのコースを嫌うようになるでしょう。なぜなら、このコースは計算可能性や再帰についての美しいが複雑な概念を教えてくれるからです。その後、コースの問題を Lisp の問題と同化させてしまいます。

于 2008-09-24T12:19:14.300 に答える
4

Lispのすべてがリストであり、他に効率的な複雑なデータ構造はありません。

違います。Common Lispには、クラス、構造、ハッシュテーブル、多次元配列、可変文字列などがあります。これらはそれぞれ効率的に実装されています。たとえば、SBCLコンパイラは、配列アクセス用に最適化されたインラインネイティブコードを出力します。

于 2008-09-25T08:08:55.003 に答える
4

「宇宙は Lisp で書かれている」. しかし、明らかにそうではありません

于 2008-09-24T12:08:49.333 に答える
3

Lisp には IDE がないため、メモ帳を使用して、余分な括弧をすべて数え続ける必要があります。

実際、かなりの数があります。Common Lisp の場合、Windows と Linux の両方でEmacs とSLIMEを使用するのが最適です。リスナー (評価するため)、インスペクター (結果を監視するため)、デバッガー (ステッピング付き)、高度にカスタマイズ可能なエディター (結局のところ、これは Emacs です) を提供します。SLIME は 10 の異なる実装をサポートしています。

于 2008-09-24T13:57:28.357 に答える
3

Lisp はスタンドアロンの実行可能ファイルを提供できません。

SBCL を使用すると、簡単な関数呼び出しで Lisp VM の現在の状態を単一の実行可能ファイルに保存できます。この実行可能ファイルを開始すると、元の状態から開始され、保存時に指定した関数またはラムダが呼び出されます。

于 2008-09-24T12:50:51.667 に答える
3

プログラミング言語であること。今日の Lisp は、それぞれさまざまな実装を持つ標準であるCommon LispSchemeを含むプログラミング言語のファミリーであり、 ClojureArcなどの多くのものもあります。

于 2008-10-27T15:19:35.633 に答える
1

人々は Lisp を使って難しい問題に取り組んでいるので、言語自体も難しいに違いありません。

再帰は難しいです。関数の固定点が難しいしかし、それらはStructure and Interpretation of Computer Programs の第 1 章をほとんどカバーしていません。これは、Scheme が難しいからではありません。実際には、Scheme がとても簡単だからです。

于 2009-06-09T01:52:18.253 に答える
1

「CLOS」はプログラミング言語であり、Lisp は解釈された機能のみの言語です。本当に、CS の教授から聞いたことがあります。そして、これらのプログラミング言語の概念の本の1つに、それを示唆する誤解を招く図があったと思います.

今日の大学の CS 教師 (特に若い教師) は、Java、C、および C++ を使用して教育を受けており、おそらく「プログラミング言語の比較研究」または「プログラミング パラダイム」と呼ばれるコースで、Scheme または Common Lisp のいずれかを学びました。おそらく Lisp 言語が好きではない誰かによって教えられ、関数、リスト、シンボル、および高階関数について教えられました。限目。その後、彼らは学んだことを教えることになります。

  • Lisp はプログラミング言語の 1 つです
  • Lispは解釈されます
  • Lispは遅い
  • Lisp は AI 言語です (私が最後に Robert Sebesta の本をチェックしたとき、それはまだそう主張していました -- しかし、新しい版があるので、彼はこれを修正したかもしれません)
  • Lisp は OO をサポートしていません (!!!)
  • Lisp は関数型言語です (他のパラダイムを最小限にサポートするのとは対照的に)
  • Lisp にはデータ型はありません
  • Lisp にはリスト以外のデータ構造がありません (したがって、数の処理には役に立ちません)。
  • 「Lisp はもはや使用されておらず、最も重要な関数型言語であるため、このコースでのみ使用されています。」

私は非常に知的な教授が Common Lisp で行列の乗算の例を示しているのを見ました - もちろん、行列をリストとして表しています!

于 2009-05-31T03:35:51.533 に答える
-2

人々は括弧を Lisp のせいにします。それらなしでリスト配列指向言語をどのように実装するかを彼らに言ってもらいたい...

于 2008-09-24T12:10:35.647 に答える
-5

十分に高度なアプリケーションは、ライン ノイズと見分けがつきません。

于 2008-09-24T12:07:52.520 に答える