views:

1710

answers:

17

Please respond with one by one.

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

A: 

Any sufficiently advanced application is indistinguishable from line noise.

Hans Sjunnesson
That's more perl.
TraumaPony
How did that quote go ? Perl - the only language that looks the same before and after an RSA encryption :-) I personally find it nice (perl, not lisp) - brackets annoy me, on the other hand :-)
ldigas
+4  A: 

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

Constantin
But it is! http://www.gnu.org/fun/jokes/eternal-flame.ogg:)
Matthias Benkard
+10  A: 

That it's for Artificial Intelligence

Lou Franco
this one really bothers me!
Luís Oliveira
Yeah, that's the first answer I usually hear when I mention Lisp.That, and LISP in written communication. ;)
skypher
@Luis - Intelligence bothers you ? ;-)
ldigas
A: 

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

lms
Easy!Use M-expressions. ;)
TraumaPony
lisp is not really list-oriented. it happens to have a singly linked list data structure built from cons cells, this is happened to be used for representing program code (a tree), whose syntax is most naturally nested parentheses. lists and cons cells are not fundamental to lisp - a fulltime lisper
Attila Lendvai
+15  A: 

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.

Levente Mészáros
It's not only SBCL. Any decent Common Lisp or Scheme implementation nowadays provide a native code or efficient bytecode compiler.
Nowhere man
Well, lots of Schemes and a couple CLs do compilation to C instead of directly to native code. It's an implementation strategy with many upsides (more portable, makes executable delivery and FFI a cinch) and some downsides (compilation is often much slower, and the speed of the resulting programs can suffer as well).
Pillsy
+5  A: 

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.

Nowhere man
+15  A: 

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!

Matthias Benkard
Flagging a language that contains the controversial LOOP macro as discouraging iteration clearly takes a lot of ignorance. The less they know, the more they judge...
Nowhere man
+7  A: 

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.

Rune Braathen
i feel like the point needs to be made that all the parens do, in fact, make the code hard to read when you first encounter the language. i consider this to be practically an incontrovertible fact.
shsteimer
I find the peculiar indentation style is more of an issue.
Jegschemesch
+3  A: 

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.

Levente Mészáros
That has its drawbacks: http://pupeno.com/blog/the-problem-with-lisp
J. Pablo Fernández
@Levente - yes, but is it "standalone"? Usually, under that term I mean static linked, that doesn't depend on anything else.
ldigas
+2  A: 

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.

Levente Mészáros
You can also use SLIME under OSX.
inglesp
You can also use NetBeans if you are using Clojure, by using the Enclojure plug in, or you can use Eclipse if you are using Common Lisp by using the Cups plug in.
J. Pablo Fernández
I would give this 'half a point' - emacs with SLIME is nice, and all, but it isn't *quite* a full blown IDE. So, let's settle on the middle, and give it 'half a point' :-)
ldigas
+8  A: 

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.

simon
+13  A: 

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..."]

inglesp
+3  A: 

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.

Levente Mészáros
+6  A: 

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.

Attila Lendvai
+1  A: 

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.

J. Pablo Fernández
Indeed. I dislike when people say "Lisp" when they mean "Common Lisp".
Kyle Cronin
The origin of this is perhaps because in the first few years, "Lisp" really did refer to a specific language and implementation. That didn't last long. Now it's an umbrella term somewhat like "assembly".
Jegschemesch
Like "assembly" or "Linux". Why I think this is very bad is because people believe "Linux has a very nasty UI" after seeing Mr Geek's Linux with FVWM so they won't touch Ubuntu. Same happens with Lisp. "Oh Clojure is a Lisp, I'm sorry, we don't like interpreted languages" after using CLisp ages ago.
J. Pablo Fernández
A: 

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!

Jay
Silly question time: what is the 'correct' way to represent matrices in LISP?
Jonathan Leffler
Well, it isn't used that much, you must admit that! I asked a question some time ago (you can find it using my profile) about where is LISP used today, and apart from Autocad and Emacs, and few other minor solutions, there wasn't really that many answers. I would love to be proven wrong, though.
ldigas
About matrices: they're a native Common Lisp type.For a matrix literal, just prepent a # sign on a list: #(1 2 3) is a 1d simple-vector; #2A((0 0) (0 0)) is a 2d-array.You can create arrays with the MAKE-ARRAY function, and access them with the AREF macro:(setf a (make-array '(2 2) :element-type 'double-float))(setf (aref a 0 1) 0.5d0) ;; Set a[0,1] to 0.5(pprint (aref a 1 1))In fact, this will generate code that competes with C in speed.
Jay
About Lisp use: it's not just Emacs and Autocad; Guile is the language for scripting used in some GNU projects, including the Gimp. Also, there's ITA Software using Common Lisp.
Jay
@unknown (google) - okey, yes. But it still doesn't make it exactly a widely used language.
ldigas
+1  A: 

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!

Brendan Foote