What is your favorite misconception about Lisp?

Question

Please respond with one by one.

If you explain why it is not true then try to avoid general statements and provide particular examples.

Answer 1

Any sufficiently advanced application is indistinguishable from line noise.

Answer 2

"The Universe is written in Lisp". But apparently it's not.

Answer 3

That it's for Artificial Intelligence

Answer 4

People blame lisp for parenthesis. I would like them to say how they would implement a list-array oriented language without them...

Answer 5

Lisp is an interpreted language and thus it is really slow.

Look at the function disassemble in the Common Lisp Hyper Spec.

A Common Lisp implementation called SBCL comes with an efficient native compiler backend for a number of platforms.

Answer 6

I don't have a "favourite" misconception, because most misconceptions, and not only about Lisp, are just annoyances. But I have one misconception about Lisp that really shocked me when I read Lisp's history (specifically History of Lisp and The Evolution of Lisp).

Lisp is known to be a slow interpreted language my many people, but in reality it had a compiler something about less than one year after having its first working interpreter, I think, and the following history is a long list of work targetted at optimization that resulted in some Lisp implementations beating Fortran at number crushing!

Most probable source of the myth is that many people get only to know Lisp from a CS course about Scheme, where they write themselves an interpreter. And probably many of them get to hate the course because it teaches them beautiful but complex concepts about computability or recursion, and they then assimilate their issues with the course with their issues with Lisp.

Answer 7

My favourite misconception: that it's a “functional language” that discourages iteration or OOP or whatever programming style you can name.

Nothing could be farther from the truth.

First of all, “Lisp”, depending on the meaning intended by the speaker, isn't really a language at all but a language family. There are a couple of more or less well-known and widespread members of this family: Scheme, Common Lisp, Emacs-Lisp, and AutoLisp are the traditional ones; nowadays, there are also Nu, newLISP (which is actually more like an “oldLISP” than a modern one, but anyway), Arc, and Clojure.

It's certainly true that Schemers seem to favour a functional style and discourage iteration in favour of recursion. However, as far as I can tell, Schemers are actually a minority in the Lisp world, at least when considering practical usage of Lisp as a programming tool as opposed to a research or study subject.

I do not know much about AutoLisp or all the other Lisp dialects beside Scheme and Common Lisp, but what I do know is that Common Lisp is definitely not a single-paradigm language that eschews imperative or even object-oriented programming. In fact, Common Lisp features the most powerful class-based object system that I know of, incorporating stuff like aspect-oriented programming out of the box.

Lisp seems to me to actually be the language family that most encourages experiments in new directions and most easily incorporates programming paradigms that aren't supported from the get-go. This includes imperative programming. Common Lisp has even got GOTO!

Answer 8

My favourite lisp misconception: CL really means CthuLhu!

Jokes aside; by far the most widespread misconception regarding all manner of lisp dialects, is that the s-expressions syntax reliance on parenthesis harms readability, when in fact it is this very trait that helps to make lisp code a lot more terse, clear and readable than the majority of other programming languages.

Answer 9

Lisp cannot provide standalone executables.

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.

Answer 10

Lisp has no IDE, so you must use notepad and continuously count all the superfluous parenthesis.

In fact, there are quite a few. For Common Lisp, it is best to use Emacs with SLIME both under windows and linux. It provides a Listener (to evaluate), an Inspector (to watch results), a Debugger (with stepping), a highly customizable Editor (this is Emacs after all). SLIME supports a 10 different implementations.

Answer 11

I don't know about having a favorite misconception... but one I often see that programmers talk about "LISP" and why they don't like it/it's inappropriate/it's academic/it'll never work for project X. Which would be fine except, when they say "LISP" they mean "Scheme" by which they really mean "a subset of Scheme" by which they really mean "a half remembered subset of Scheme from that AI or languages course 5 years ago that they didn't like".

There seems to be quite a bit of irrational prejudice against Lisp(s) from this direction. Rational prejudices are something else entirely.

Answer 12

That all the parentheses make code unreadable. After about two weeks, and with a decent text editor, you just stop noticing them.

[ETA - just found a quote by long-time lisper Kenny Tilton: "Parentheses? What parentheses? I haven't noticed any parentheses since my first month of Lisp programming. I like to ask people who complain about parentheses in Lisp if they are bothered by all the spaces between words in a newspaper..."]

Answer 13

Everything in Lisp is a list, there are no other efficient complex data structures.

Not true. In Common Lisp there are classes, structures, hashtables, multi dimensional arrays, mutable strings, etc. Each one of those are implemented efficiently. For example, the SBCL compiler emits optimized inline native code for array access.

Answer 14

many think that lisp is a list-oriented language (whatever that means).

it's a widespread belief, even among lispers, that the one great and most important thing about lisp is the cons cell and the singly linked lists that one can build up using them (sexp's). people who believe that don't understand the real reasons that make lisp a more productive language than the other mainstream languages (this is only my subjective opinion!), and don't understand that lisp could pretty much be what it is without having the cons cell in the game at all.

a random selection of things that are important to make lisp what it is, and that are easily doable without sexp's:

• REPL
• compiler available at runtime
• dynamic typing
• syntactic abstractions (macros)
• closures
• simple syntax which is easy to edit (and to "parse" by the brain)

a few explanations:

simply put, dynamic typing means that not the places have type but the runtime values. this is an important help if you don't know beforehand all your requirements, and your application is constantly transforming as the project evolves. from my experience, this is by far most of the case - only with much more obstacles when static typing is in the picture.

probably many would argue that the cons cell and sexp's are crucial for a flexible macro system. the crucial thing is a simple syntax and a simple to manipulate data structure it is parsed into. the sexp syntax and lists together are a good candidate, but there are many others.

i'm happy with the parens, but i'm not happy with the other part, namely using cons'd lists to represent program code, because it has an important deficiency: you can't annotate it with random stuff without disturbing the data that is already represented with it. e.g. i can't annotate such a cons'd list representing program code with the fact that it was edited by Joe two days ago, without turning that form into nonsense for the lisp compiler. these annotations are more and more important as your DSL's become more complex, and as your macros turn into small compilers compiling your DSL into lisp.

Answer 15

That it is a programming language. Today Lisp is a family of programming languages including Common Lisp and Scheme, which are standards with various implementations each, and also Clojure, Arc and many others.

Answer 16

That "CLOS" is a programming language, and that Lisp is an interpreted, functional-only language. Really, I heard that from CS professors. And I think there was some misleading chart in one of these Programming Language Concepts books that suggested that.

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:

• Lisp is one programming language
• Lisp is interpreted
• Lisp is slow
• Lisp is an AI language (the last time I checked Robert Sebesta's book, it still claimed that -- but there is a new edition, so he may have fixed this)
• Lisp has no OO support (!!!)
• Lisp is a functional language (as opposed to minimally supporting any other paradigm)
• In Lisp there are no data types
• Lisp has no data structures except lists (and hence is not useful for number crunching)
• "Lisp is not used anymore, and is only used in this course because it is the most important functional language"

I even saw a very intelligent professor giving an example of matrix multiplication in Common Lisp -- representing the matrices as lists, of course!

Answer 17

That because people tackle hard problems using Lisp, the language itself must be difficult.

Recursion is hard. Fixed points of functions are hard. But they barely cover chapter 1 of Structure and Interpretation of Computer Programs. That's not because Scheme is hard -- it's actually because it's so easy, the hard stuff is all that's left to do!