One theory that people often bring up vis-a-vis readability of lisp is that people seem to have a harder time parsing symbols than words (so all the parens makes it harder to look through a file).
Compared to python or coffeescript, it feels like there's a lot less noise
i am not particularly gifted at computer science and especially not programming languages. by necessity, the only languages i know are JavaScript and lisp. so I am always surprised to hear lisp is "unreadable" as opposed to "unfamiliar".
I think that Lisp got a reputation for being unreadable because some Lisp programmers have the tendency to get too far into macros to extend the language, resulting in a language that other developers have not seen before.
I think that's pretty much a straw man. Where is all this terrible macro-laden Lisp code? Well, it's probably not totally made up, but you run into overcomplicated abstractions in every language.
Somehow it seems more likely that people are put off by the slightly "isolationist" culture of Lisp, or the historical clash between Lisp and Unix, or whatever, and then this "unreadable" idea is like a rationalization for not liking the language? This is just a hunch...
You could make all kinds of arguments for the difficulty and obscurity of Haskell, yet it's winning ground quite effectively. I think this basically started with the success of GHC and Cabal/Hackage in creating an infrastructure that's familiar and efficient.
The Lisp world always had good infrastructure engineering. The main compilers (SBCL, CMUCL, etc) are very impressive! But it takes a very intensive kind of community engagement nowadays to stay up to date.
I still think Lisp could have a renaissance. Maybe it's already going on with Clojure. And of course Emacs is quite strong.
The ideal of programming seems to be software architectures based on layers of coherent abstraction. That's very, um, abstract, and there are different ways to do it. With OO, you imagine objects cooperating in layers. With Haskell-like functional programming, you use a mathematical style of abstraction, trying to find theories and algebras that make sense and compose, building applications out of combinations of well-typed values, etc.
Paul Graham describes the Lisp style in his texts on Lisp. You can see it in Emacs's various DSLs (for defining customization parameters, for traversing buffers, etc). It encourages abstraction layers built so as to form mini-languages. So a library can easily provide custom syntactic forms. Instead of having a small number of syntactic forms (if, for, etc) and an expression language based on function application, Lisp is syntactically extensible.
Programming is not a solved problem! We still aren't really sure about how to design programs, how to create coherent abstraction layers. The Haskell approach is very interesting, but not totally fleshed out. People are still working out the best way to structure concurrent I/O pipelines with error handling, for example. I sort of lost my train of thought, but Lisp is very interesting!
It's not a straw man for me -- it's what I think of a lot of Lisp code.
I think it's really instructive to compare things written in the early days of Clojure to Clojure right now. Some times I just want to find the author of some code block, shake them, and yell "No! The only reader macros you are allowed to use are ', `, and #() !". Absolutely beautiful language, but way too easy to make unreadable.
I'm not justifying Lisp's reputation, I am trying to explain it. Whether Lisp's reputation is justified or not is immaterial to my comment. Personally, I believe that the reputation is not justified.
I like scheme to be honest, especially the racket style of preferring define over let. Combined with well chosen variable names, list comprehensions, pattern matching and optional square brackets, all but the trailing ))))) becomes not a problem.
My theory is that it has to do with not having any operators, except parentheses, and using exclusively prefix notation, where other languages allow infix for doing arithmetic. Also, in Scheme loops are usually recursion, which means they have no standard form and they are upside-down from usual (the loop condition and increment are near the bottom, where the recursive call is).
Say what? Both replies are saying that macros can make it tough to read. (Though, personally, I don't have a problem with most macros -- just reader macros.)
To what, I don't know.