请逐一回复。
如果你解释了为什么它不是真的，那么尽量避免一般性的陈述，并提供特定的例子。
所有的括号都使代码无法读取。大约两周后，有了一个不错的文本编辑器，你就不再注意到它们了。
[ETA-刚刚发现一句长期口齿不清的Kenny Tilton的话：“括号？什么括号？自从我学习Lisp编程的第一个月以来，我就没有注意到任何括号。我喜欢问那些抱怨Lisp中括号的人，他们是否对报纸上单词之间的空格感到困扰…”]
我最喜欢的误解是：它是一种“函数式语言”，不鼓励迭代或OOP或任何你能说出名字的编程风格。
没有什么比这更偏离事实了。
首先，根据说话人想要表达的意思，“Lisp”根本不是一种语言，而是一个语系。这个家族有几个或多或少知名且广泛的成员：方案，公共Lisp，Emacs Lisp和AutoLisp是传统的；如今，也有Nu，newLISP（实际上它更像是一个“旧LISP”，而不是现代LISP，但无论如何），弧形和克隆。
的确，Schemers似乎倾向于函数式风格，而不鼓励迭代而倾向于递归。然而，据我所知，Schemer实际上是Lisp世界中的少数人，至少在考虑将Lisp作为一种编程工具而不是一个研究或研究主题的实际使用时是这样。
我对AutoLisp或除Scheme和Common Lisp之外的所有其他Lisp方言了解不多，但我所知道的是，Common Lisp绝对不是一种回避命令式甚至面向对象编程的单一范式语言。事实上，Common Lisp具有我所知道的最强大的基于类的对象系统，它集成了开箱即用的面向方面编程之类的东西。
在我看来，Lisp实际上是最鼓励在新方向上进行实验的语言家族，并且最容易融入从一开始就不受支持的编程范式。这包括命令式编程。Common Lisp甚至获得了GOTO！
这是为了人工智能
许多人认为lisp是一种面向列表的语言（不管这意味着什么）。
人们普遍认为，即使在口齿不清的人中，lisp最伟大、最重要的一点就是cons单元格和使用它们可以建立的单链列表（sexp s）。那些认为lisp是一种比其他主流语言更有生产力的语言的真正原因的人（这只是我的主观观点！），也不明白如果游戏中没有cons单元，lisp几乎可以成为现在的样子。
随机选择对使lisp成为现在的样子很重要的事情，并且在没有sexp的情况下很容易实现：
一些解释：
简单地说，动态类型化意味着不是地方有类型，而是运行时值。如果您事先不知道所有的需求，并且您的应用程序随着项目的发展而不断变化，那么这将是一个重要的帮助。根据我的经验，到目前为止，大多数情况都是这样——只有当静态打字出现在画面中时，才会遇到更多的障碍。
可能许多人会认为，cons-cell和sexp对于一个灵活的宏观系统至关重要。关键是一个简单的语法和一个简单易操作的数据结构。sexp语法和列表结合在一起是一个很好的候选者，但还有很多其他的。
我对parens很满意，但我对另一部分不满意，即使用cons d列表来表示程序代码，因为它有一个重要的缺陷：你不能在不干扰已经用它表示的数据的情况下用随机的东西来注释它，而不会将这种形式变成对lisp编译器来说毫无意义的。随着DSL变得越来越复杂，以及宏变成了将DSL编译成lisp的小型编译器，这些注释变得越来越重要。
我不知道有什么最喜欢的误解。。。但我经常看到程序员谈论“LISP”，以及他们为什么不喜欢它/它不合适/它是学术性的/它永远不会适用于项目X。这很好，除非他们说“LISP”时，他们指的是“Scheme”，他们真正的意思是“Schem的一个子集”，他们真的是指“5年前人工智能或语言课程中他们不喜欢的Scheme的半记忆子集”。
从这个方向来看，似乎有不少对Lisp（s）的非理性偏见。理性的偏见完全是另一回事。
我最喜欢的口齿不清的误解：CL真的是CthuLhu的意思！
抛开玩笑不谈；到目前为止，对各种lisp方言最普遍的误解是，s表达式语法依赖于括号会损害的可读性，而事实上，正是这一特点，有助于使lisp代码比大多数其他编程语言更加简洁、清晰和可读。
我没有“最喜欢”的误解，因为大多数误解，不仅仅是对Lisp的误解，都是令人烦恼的。但我对Lisp有一个误解，当我读到Lisp的历史时，这真的让我感到震惊（特别是Lisp的历史和Lisp的演变）。
许多人都知道Lisp是一种解释速度慢的语言，但事实上，我认为，在拥有第一个可工作的解释器后不到一年，它就有了一个编译器。下面的历史是一长串以优化为目标的工作，导致一些Lisp实现在数量上击败了Fortran！
这个神话最可能的来源是，许多人只是从一门关于Scheme的CS课程中了解Lisp，在那里他们给自己写了一个翻译。他们中的许多人可能会讨厌这门课程，因为它教会了他们关于可计算性或递归的美丽但复杂的概念，然后他们将自己在课程中的问题与Lisp中的问题融合在一起。
“宇宙是用Lisp写的”。但是显然不是。
Lisp中的所有内容都是一个列表，没有其他有效的复杂数据结构。
不是这样。在Common Lisp中有类、结构、哈希表、多维数组、可变字符串等。每一个都得到了有效的实现。例如，SBCL编译器为数组访问发出优化的内联本机代码。
Lisp无法提供独立的可执行文件。
Using SBCL, you can save the current state of your lisp VM into a single executable file with a simple function call. When you start this executable, it will start from the original state and call the function or lambda that you have provided when it was saved.
Lisp没有IDE，所以您必须使用记事本并不断计算所有多余的括号。
事实上，有不少。对于Common Lisp，最好将Emacs与SLIME在windows和linux下都可以使用。它提供了一个监听器（用于评估）、一个Inspector（用于观察结果）、一种调试器（带步进）和一个高度可定制的编辑器（毕竟这是Emacs）。SLIME支持10种不同的实现。
“CLOS”是一种编程语言，和Lisp是一种解释的、仅函数的语言。真的，我是从CS教授那里听说的。我认为在其中一本《编程语言概念》的书中有一些误导性的图表表明了这一点。
CS teachers at Colleges and Universities today (particularly the young ones) were educated using Java, C and C++, and they probably learnt either Scheme or Common Lisp in a course called "comparative studies of programming language" or "programming paradigms", which was probably taught by someone who doesn t like any Lisp language, and taught them about functions, lists, symbols and higher-order functions. Period. Then they end up teaching what they learned:
我甚至看到一位非常聪明的教授在Common Lisp中给出了矩阵乘法的例子——当然，将矩阵表示为列表！
因为人们使用Lisp来解决棘手的问题，所以语言本身一定很难。
递归很难。函数的固定点很难。但它们几乎没有涵盖计算机程序的结构和解释。这并不是因为Scheme很难，而是因为它很容易，剩下的就是难的事情了！
人们把插入语归咎于口齿不清。我想让他们说，如果没有他们，他们将如何实现面向列表数组的语言。。。
