Why Lisp Did Not and Never Will Gain Enough Traction
kresimirbojcic.com
kresimirbojcic.com
Indeed, criticizing "lisp" is difficult because it isn't really clear what you mean. Common Lisp? Well that has a lot of work done for you. Scheme? That's deliberately minimalist because it's not meant for everyday work until you go outside the core spec (e.g., PLT Scheme's libraries). Clisp? MacLisp? What?
Lisp didn't take off because it didn't take off. There isn't some deep unconscious wisdom being tapped by the masses that we can read with tea leaves and subtlety. These things are random. There is a parallel universe not far from this one where Anic is a big deal and Pike took off in place of Python.
Because to assume otherwise that would imply that everyone knows every language and some are uniform winners over others. Do you know every language you have rejected? Heck, do you even know the general characteristics of Lisp, or Haskell, or ML, or Anic, or Pike, or APL? No, and to really try and learn all of them would take a lot of time unless you're quite gifted. So the premiere and popular programming languages are as unpredictable as fashion.
All you and I can do in our quest to be great software engineers is try and choose tools that split the difference between The Best For the Job and the Best We Can Manage.
Compare a Noir or even bare Compojure web service vs. a Sinatra web service. Is there really a big winner on brevity?
Anyways, I can give you bullshit benchmarks if you want. The numbers are sort of meaningless, the benchmark synthetic, the methodology poor but it's almost all against the server's favor.
(GET "/hello" [] {:status 200 :body "Yo!"}))
~ > httperf --hog --server localhost --port 9999 --uri=/hello --num-conn 5000 --num-calls 1
...
Connection rate: 4769.8 conn/s (0.2 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 0.2 avg 0.2 max 3.8 median 0.5 stddev 0.1
Connection time [ms]: connect 0.0
Connection length [replies/conn]: 1.000
...
Reply rate [replies/s]: min 0.0 avg 0.0 max 0.0 stddev 0.0 (0 samples)
Reply time [ms]: response 0.2 transfer 0.0
Reply size [B]: header 98.0 content 3.0 footer 0.0 (total 101.0)
Reply status: 1xx=0 2xx=4999 3xx=0 4xx=0 5xx=0
Again, these numbers are not precise or useful. They're just there to put some flags in the ground for further exploration should you want to do a rigorous comparison.
3ms vs. 0.2ms
So we might be talking about order of a magnitude here?
I don't have to personally know every language. Languages grow in popularity by picking up users. It is clear lisp was and is very popular with certain segments of programmers, and ever caught on with others.
You know, it was fairly popular for a time.
> I don't have to personally know every language. Languages grow in popularity by picking up users.
This is a tautology.
But let's pretend for a second what you meant to say was "Languages deserve the usership they gain in a sort of mindshare stock exchange." Then let's rewind 10 years and show you Clojure, Ruby, Java, and Javascript.
Can you ever imagine someone from 2002 picking Javascript over those alternatives? Someone sane, I mean. All praise to the pragmatism of the 'net, but Javascript's popularity is a function of its largely unrequested deployment and the failure of competing products (mostly due to artificial and non-technical business-enforced nonsense).
And yet here we are with Javascript being so popular that startups are raising $9m just to build frameworks in them. And yet by any reasonable metric Javascript is a "worse" language. The most highly-recommended starter book for javascript is "The Good Parts", because a whole lot of the language is just so bad it has to be ignored or worked around.
All we're really doing is appealing to popularity as a justification for using perceived popularity instead of real technical metrics. Which is–to some extent, anyways–fine and good; it certainly is traditional for people to do this. But let's not pretend we have access to some deeper insight while we're doing it.
Their rise has been <sunglasses> meteoric.
Javascript is not the only language that surpassed Lisp in popularity, far from it.
But does that theory actually limit what we'd predict about the future? Does it retroactively predict all the past data that we've seen? As you pointed out, Lisp was quite popular for a bit.
What if we just said, Lisp isn't popular because it didn't get/stay lucky?
That anti-theory isn't quite as satisfying, but at least it doesn't pretend at knowledge that it doesn't have.
One really nice thing, in my opinion, about JavaScript programmers is that they don't sit around kvetching about why the wrong language won. We all know it was a fluke, but the fluke happened, and here we are, so you can either squawk about languages, or get real things done instead, and improve the tools and software that you have.
I'm afraid I have to dispute this. I'm about as dedicated a Lisper as you'll find -- learned it at the feet of Bernie Greenberg, Gerry Sussman, and David Moon in the late 1970s, and still use it when I get the chance. (Oh and I think my Symbolics machine still works, though I haven't fired it up in several years.) I was around during the time you're probably thinking of -- the AI bubble of the mid-1980s -- and even then, Lisp was the language a lot of people loved to hate, if they knew anything about it at all.
There was some interest in Lisp, to be sure, but I think "fairly popular" is putting it too strongly. It has always been a fringe language.
On another note -- it struck me the other day that if history had gone a little differently, we might be using Dylan instead of JavaScript. Oh well...
But you're right, it never had the singular popularity that Javascript, Java, or Python now enjoy. Sorry if in my haste I gave a false impression. Not what I meant to imply.
Care to qualify how Clojure obsoletes Ruby or Python? Both of those languages have great tools (rails, for example) that those in the Clojure communities have great respect for. As a Clojure and Ruby/Rails programmer, I share your enthusiasm for Clojure and lisp, but I can't see Clojure pushing either Ruby or Python out of the water any time soon.
I am surprised a Clojure programmer would have much respect for Rails. Its aggressive share-nothing approach leads to inconsistency, poor performance, awkward architectures, and over-reliance on external state management.
Perhaps one might admire it for making a bold claim about configuration vs. convention, but a valid criticism of Rails is that they went so far along the convention line in rebellion of bad tools like Spring that now they get accused of excessive magic.
> But I can't see Clojure pushing either Ruby or Python out of the water any time soon.
Like I said, success is fashion. But then, people said this to me about Git Vs. SVN after I gave a tech talk to a bunch of ruby folks about how git would take over the world. Two people left that talk and went on to found Github, so... "High Fashion."
Clojure has all the power of Ruby's dynamism, but with a better solution to the expression problem (protocols are namespace contained, allowing for monkey-patching that doesn't taint the world). It has access to a lot of fantastic high-performance libraries. It can safely deal with high degrees of parallelism with a degree of ease few environments can claim. It has a minimalist syntax which can compete with even the most terse and convention-driven ruby syntax (i.e., Compojure vs. Sinatra).
Similar complaints can be leveled at Python with less of a performance angle and more of a power angle; Clojure gives you access to many of those features that the python community feels are "too awkward" to use in the OO world, but are entirely natural in the Lisp world.
So yeah, every time someone writes a server in Node.js I think to myself, "You could have done it in Clojure and had just as much dynamism during development, just as easy a deployment story, and also perform easily an order magnitude faster under load, and you don't have to run like a scared child from parallelism."
Wrt Python I know I'll do fine w/ Django, Flask, Jinja2, Psycopg2, Tornado...
When evaluating what tool to use for a project, there are many things to take into account other than the technical superiority of the tools. Relevance Inc, one of the strongest backer of Clojure, still make use of Rails for client projects. Rails' huge web dev ecosystem really made many common tasks as simple as importing a gem here and there and making a few method calls. It all comes down to the right tool for the right job. I'm interested in your take on how Rails' "share-nothing approach", awkward architectures etc.
> Clojure has all the power of Ruby's dynamism
Yes, and then some. Without repeating what you have already said, I would add efficient persistent data structure to the Clojure's list of awesome tricks. Doing functional programming in ruby and python, for example, will force you to trade value immutability with efficiency -- a penalty that one does not have to pay in Clojure.
Clojure is definitely gathering a lot of following. Like many others, I have picked it up, played with it, and never looked back.
But going back to what was said before. Yes, Clojure is awesome. No, Clojure is not obsoleting Ruby or Python any more than those obsoleted PHP, at least not now.
If you need deeper support for vector math, scientific calculations, and the like then Incanter is probably what you want. It does all the complicated fast math stuff that always benefits from carefully planned and hand-tuned libraries.
The benefits to scientists are the developer efficiency (rapid prototyping), comprehensive libraries (scientific functions and plotting), interfaces similar to MatLab (eg. slicing), and its standing in the scientific community. It would sort of defeat the purpose to spend valuable research time to reinvent the wheel in another language -- though I would switch to a LISP variant in a heartbeat if there was comparably functionality.
This kind of smugness[1] is one reason why Clojure will never take over the world. It seems to be some kind of unwritten rule that every Clojure evangelist has to knock another language in any post anywhere [2]. Ugh.
I am a great admirer of Rich Hickey (the man is a genius), and am happily using Clojure in my present project, but this kind of triumphalist rhetoric is a big turn off. I don't think Clojure "obsoletes" Ruby or Python, anymore than Haskell or Erlang "obsoletes" the various lisps.
[1] This attitude seems particularly endemic amongst people who've moved to Clojure from the early Ruby on Rails community, where sneering at alternative frameworks was part of the culture.
Rich Hickey, while justifiably proud of his language, as he should be, never makes silly statements like this.
[2] see http://news.ycombinator.com/item?id=4272186 for an embedded gratuitous swipe at Scala in an otherwise insightful post.
You can say I am some sort of hater and now it's Rails's turn, but I've been consistent with this even when I was a full time rails programmer [1]. You can find essays by me on the inadequacies of Rails dating back years now [2]. The very things I was complaining about in 2007 are now the glaring flaws in modern Rails. So I made the decision to strike out for tools that don't have a cultural bias against progress in areas I believe important.
So, if I am a Smug Lisp Weenie, then surely I am also a Smug Scala Weenie. And a Smug Erlang Weenie. And a Smug Haskell Weenie. And a Smug Ruby Weenie. And a Smug Hadoop Weenie. And a Smug C weenie... Because one thing I've made very clear is that I think attachment to tools is the problem. We should always aim to use the best tools at our disposal, and I think the place where Python and Ruby are the best tools are shrinking under the onslaught of the competition. Argument from familiarity is something I simply cannot bear to listen to anymore.
If believing this makes me smug then I guess I am smug.
[1] http://www.oreillynet.com/ruby/blog/2007/06/multicore_hardwa...
[2] http://dave.fayr.am/posts/2008-11-20-the-opposite-of-momentu...
Oh but that's not what I said. I said that claims of Clojure "obsoleting" Ruby/Python reek of smugness once prevalent in RoR and Common Lisp communities, and do turn off intelligent people. You can like and evangelize Clojure without making such rabid claims, especially when they are unsupported by data or strong arguments.
"We should always aim to use the best tools at our disposal,"
This is a non controversial position. The "smugness" is in going beyond such sane positions and declaring Clojure to be some kind of uber Ruby/Python killer without any supporting data or arguments.
"and I think the place where Python and Ruby are the best tools are shrinking under the onslaught of the competition."
This is more dubious. Do you have any supporting data? What do you see as "competition" to Ruby or Python? Clojure? in terms of deployed systems, Clojure is barely a blip (wrt RoR, say). I know many intelligent devs using and liking Clojure, but also other intelligent devs using and liking Python and Ruby. I even know (horror!) people who know all three and don't always choose Clojure.
Also, it is pretty hard to characterize Clojure as an "onslaught" on Ruby in any fashion (afaik Rich Hickey doesn't have such an onslaught as part of his goals for Clojure development), or as an "obsoleting" language, which is a very strong claim. Strong claims require strong supporting evidence.
In fairness to you, you did say " I think that .. " which brings me to
"Argument from familiarity is something I simply cannot bear to listen to anymore."
Totally agreed. Now apply that to your Clojure evangelism/praise. ;-)
Fwiw I am working on a Clojure project, and quite like the language. It is extremely well designed and (given the limitations of the JVM) very elegant.
But I don't have a stake in proclaiming it to "obsolete" Ruby/Python etc - at least not without some very convincing arguments - certainly not just "argument from familiarity" ;-)
All that said, I gladly concede that Clojure is some kind of ultra uber language in your experience, in the interest of stopping this thread from expanding fruitlessly.
PS: Decent essays btw. Now apply the same critical eye to Clojure :)
Actually, it is. Basically when someone says, "____ is smug," what they're really doing is making a soft, attitude based argument for dismissing the more substantive arguments. Same as calling someone a hater.
> You can like and evangelize Clojure without making such rabid claims, especially when they are unsupported by data or strong arguments.
I can support the arguments quite well. And I can make the same argument for Go, Scala, Erlang, and Dart. We simply haven't had the space or opportunity to really expound on it here, since the context is a post that attacks "lisp" with spurious complaints.
> Strong claims require strong supporting evidence.
This is true, but what you're doing is ignoring the context of the conversation after the fact to try and weaken my position. I can make a case for these claims, and in fact in many of my blog posts I have made a case for these claims. Saying I never have in this thread is a little disingenuous.
> I even know (horror!) people who know all three and don't always choose Clojure.
You then have the horror of knowing me, the person you have mischaracterized as a Clojure evangelist instead of a modern software tools evangelist.
> at least not without some very convincing arguments
Allow me to just list out Clojure's strong points with respect to Ruby, since that's close at hand. Because you keep acting like I an a Clojure fanatic, dedicated with laser-like precision to the cause of promoting Hickey's work, let me re-iterate: _I COULD DO THE SAME WITH A HALF-DOZEN OTHER TOOLKITS._
1. Ruby and Clojure are both dynamic langages with a variety of beyond-the-Java features but... a. Clojure's answer to the "expression problem" is safer, faster, and cleaner [1]. b. Clojure has explicitly modeled multi-methods, something that observations of the industry suggest would be useful for clarifying a lot of existing code [2]. c. Clojure can support functional programing and OO programming directly. It often ends up having "cleaner" (less punctuation and repetition) expressions of OO call stacks than its host language, Java. [3]
2. Clojure and Ruby both have rich collection libraries, but... a. Clojure's core data structure libraries are somewhat richer (e.g., better set support, some better numerics), and safer in multi-threaded use because of their persistent design. b. Clojure's libraries implement the same "pass in a block" pattern as Ruby, but with more universal names in most cases, and with more consistency (which is important due to the thrush combinators). c. When the standard persistent data structures cannot meet your performance needs, high performance mutable structures are available from the Java toolkit. Ruby usually has to appeal to C to get faster results, the binding process of which is fraught with peril even with 1.9 (and is excruciatingly difficult in 1.8 due to fundamental design mistakes).
3. Both languages support concurrency primitives but.... a. Ruby's concurrency primitives never allow for parallel processing except in a tiny minority of implementations, whereas in all but a tiny minority of implementations Clojure's primitives do. b. Ruby's concurrency primitives are basic, whereas Clojure not only offers the Java primitives (themselves ranging from basic atomic references to the contents of java.util.concurrent) but also offers a Software Transactional Memory implementation which emphasizes reasonable performance and ease of use.
4. Both communities value brevity and meta-programming, but... a. Clojure's half-hygenic macros with quasi-quoting provide an approachable way to make arbitrary syntax extensions to the language; in this Lisp is only challenged by other Lisps and perhaps the Haskell and ML world. b. Many similar abstractions like Sinatra vs. Compojure exist in the "Ruby and Clojure"-verse, but because of macros the Clojure side can always go further. In the context of the above points, Clojure almost always has a significant performance advantage, too.
5. Both languages have excellent deployment strategies... a. Ruby has a suite of integrated in-language tools and a lot of service vendors that directly support it for distributed software projects. b. Clojure is deployable almost anywhere Java is deployable, which is "almost almost" everywhere. c. Clojure has a mixed blessing in that it has access to ".war" and "uberjar" type deployments. These can be more confusing, but often eminently more easy for an operations (or devops) team.
I'll stop for now, but I want to re-iterate I could make cases against many popular languages for a variety of other languages when the situation warrants. For example, when correctness and ease of distributed processing is your goal, Erlang is unmatched.
[1] http://kirindave.tumblr.com/post/658770511/monkey-patching-g... for more on this.
[2] http://homepages.ecs.vuw.ac.nz/~alex/files/MuscheviciPotanin...
[3] http://java.ociweb.com/mark/clojure/article.html and grep for "noisy" for a casual treatment.
Whether they actually prove anything like your conclusion, I'll leave to the judgement of the other readers.
(rest of this too long reply deleted as too snarky and not worthy of HN. Sorry guys)
That's quite a jump to an (invalid) conclusion.
Sure, no programmer has knows of all the languages he does not use or has rejected. But that doesn't mean that there is not a reason some language gain traction and get to be known by lots of programmers and others do not.
You seem to have the simple minded view that simply because I haven't heard of all the languages I don't use, it is random which ones I do use. That's not how it works.
It works by statistics and aggregates. I may not know language X I do not use, and I might know Y, which I do use. But this is not random, it's because of various forces at play, that made Y more widely known and X less so. For example, C provided raw speed with less memory use at a time it was very crucial, was easy to learn, had free/cheap compilers available, it was the language UNIX was written in, and it was simple enough. Oh, and portable. Those things got it traction. Lisp was mostly used in academia-AI, was slow at the time, compilers cost an arm and a leg and Lisp Machines even more so, and was associated with the "AI winter". Those are some reasons it did not do well.
But then:
> But this is not random, it's because of various forces at play, that made Y more widely known and X less so.
Where "various forces" is furious handwaving for the sheer randomness that made that set available to you. And let's say in a slightly different history that set is slightly different (but still contains your current choice), how do you know you would have ended up the same?
But perhaps I am being lamentably simple minded. Every decision you make is deliberate and justifiable.
You keep using that word, random. I don't think it means what you think it means.
A coin toss is random. C picking up for the stuff we did in the eighties is not random. Lisp losing traction after the AI winter is not random. Javascript gaining traction with the web is not random.
That the creation of C was effected by random events (the experiences of Ken Thompson, the position of AT&T, the decision to provide the source, etc), does not mean that the success was random.
The success was logical and repeatable given the needs of the era and how the language came to be. To put it in another way, if another language had taken the role of C in the industry at the time, it would have been pretty similar to C, and with external qualifications (availability of source, portability, etc) similar to C.
From this aspect, the (random) fact that it was C after all and not some other C-like language, doesn't matter at all. The language that would have filled C's role would have quacked like C, and that is the non-random, and substantial part.
Read the "Worse is better" for some background.
Why is a coin toss any more random than a specific language gaining traction? It's called "(extreme) sensitivity to initial conditions." Many of which are neither observable nor predictable.
Because my argument was not about a "specific" language.
It was about C-capability language gaining and Lisp-capability language losing ground at that era.
That the C-capability language was C itself, well, that be more or less random.
But that people DID need a portable, close to the metal, constrained with regards to memory use, pointer using, simple to create compilers for, close to assembly language at the time because CPUs and memory were constrained, that was not random, that was a necessity.
And, no, there wasn't "extreme sensitivity to initial conditions" to that. The initial conditions varied at the ten odd years it took for the language to gain traction. And Lisps (including CL, Clojure etc) have been going up and down since the early sixties. It's not like some initial condition set the tone, tons of decisions, several of them important and with predictable consequences set the tone.
And why didn't Fortran win? It meets these requirements. Didn't Forth exist back then too? That meets these requirements.
That is, the part where I wrote:
my argument was not about a "specific" language. It was about C-capability language gaining and Lisp-capability language losing ground at that era. That the C-capability language was C itself, well, that be more or less random.
Either the languages competing were close to what was needed for the machines of the era and the dynamics of the marker (in which case they were more or less similar and which one won was random) or the languages had very different characteristics (in which case which "style" of languages won can be explained).
Languages close together (e.g C and Pascal) won or lost for less significant and more random reasons than the ones that led whole language families to win or lose.
In particular, the phrase "back in a day" is used twice and I'm still not 100% certain whether it means that the actions were performed in a single day (which would be odd phrasing) or, more likely, if it's meant to be "back in the day", in the sense of "at an unspecified point in the past".
That said, I don't wish to put people off from blogging in English, especially considering it was an interesting article that I would not have been able to enjoy if it was written in Croatian. My (intended to be friendly) advice is to recruit native-English proof-readers. I think you won't need them for long.
And that is not a bad thing. But really, how many Picassos and Da Vincis and Michelangelos have we produced so far? That's not something you could ever call "mainstream"...
I think that the failure of Lisp to gain traction is probably better attributed to the other point about too much minimalism being madness. Some of the forms in Racket are pretty crazy.
Many- most perhaps - developers don't want that. They want a golden road to deployment, a KISS mechanism to write basic code to do basic things and keep doing them. Flexibility and power expand the solution space too much for their taste.
Well, that's OK for them. I'll just be doing my Lisp as much as I can.
CS people like to abstract away the computation from physical hardware, but the apparent fact is computation _is_ physical, and it's limits lie in physics and not in mathematics or philosophy (see Shor's algorithm for instance).
It's only natural to write programs in a language that follows the same flow as the underlying physical computer. A classical computer is represented by it's assembly language, thus it makes sense to have languages like C. Concepts like "stateless programs" don't even exists in a classical computer. It's as crazy as trying to build a quantum algorithm that does away with measurements!
In addition the physical world does not work anything like a stateless machine. As most useful programs imitate a physical process rather than a pure mathematical object, the notion of writing programs in such languages is not-intuitive and requires transformation of the actual problem at a both low (hardware) and high (software output) level.
Finally I would like to speculate that the whole concept will never be intuitive in the future (post-quantum computer era). In the era of quantum computers, because they will always be physical objects with a particular state, and it's this very fact that they have a well-defined state allows us to perform a computation.
The same thing can be said about "which model of computation resemble physical reality." Each of us can have different mental models of physical systems. Personally, the functional paradigm is closer to my mental model than declarative, but imperative still feels the most natural. This isn't a statement about reality, but rather about how you think about it.
That being said, of course it matters the way you write your software. There is a huge gap between actual CPU instructions and Lisp. Between Lisp and the machine is an automated, soft layer of emulation, which may or may not be optimal and is extra work anyway.
F=MA is a function, and it isn't mutable. I could calculate force from some other function (e.g. Gm1m2/r^2). I can compose those functions together to get a new function. Still nothing mutable. I could continue this to create a model of a physical system that turns into one big function. That function models the system, and it can take some outputs to give whatever outputs you want. All without storing state internally.
So, it's certainly possible to accurately represent physical systems without keeping track of state along the way.
Classical state of a particle lives in the 2n-dimensional manifold known as phase space. The coordinates of the phase space are the configuration space and the corresponding conjugate momenta. The state is a single point on the phase space, corresponding to the initial conditions of the problem. The Hamiltonian determines the time evolution in the phase space, which is a trajectory.
To make is simpler for you to understand: 1. Position and momentum couples form the physical state. And of course, for any physical system, it exists. 2. You need 2 initial conditions to solve a 2nd order differential equation. You can't solve a differential equation without initial conditions (of course to use this fact, you would need to understand that F=ma is a differential equation, not a function) (Maybe it's better if you read some good introductory text, such as Feynman Lectures on Physics Vol 1, Chapter 9).
If still not clear for you: the initial state in a two body problem is determined by the initial position and velocity. They are the initial conditions of your "function" F=ma, which is actually a second order differential equation. F determines how this initial state will change over time.
If the latter, pg makes a good argument in section 4.8 of On Lisp:
"So yes, reading a bottom-up program requires one to understand all the new operators defined by the author. But this will nearly always be less work than having to understand all the code that would have been required without them.
If people complain that using utilities makes your code hard to read, they probably don’t realize what the code would look like if you hadn’t used them. Bottom-up programming makes what would otherwise be a large program look like a small, simple one. This can give the impression that the program doesn't do much, and should therefore be easy to read. When inexperienced readers look closer and find that this isn’t so, they react with dismay."
You know, I don't think this is true at all. Concision can make things harder to read, because you have to understand everything you read from scratch. A language where some common patterns come with a bit of boilerplate allow you to orient yourself via that boilerplate. The visual representation of a common pattern provided by the sugary syntax of some languages is, in one sense a waste of space and typing, but it can make code easier to read than a more concise language would be.
Compare a language which forces you to write this
ll = []
for x in xx:
if bar(x):
ll.append(x)
Contrast the above with
ll = [x for x in xx if bar(x)]
filter bar xx
I find Ruby way much more natural.
xx.select { |x| bar(x) }
Even Clojure is better
(filter (fn[x](bar x)) xx)
or
(filter #(bar %) xx)
That said, in Python, you have to take what you can get, though. And generally I expect more people are familiar with Python than Haskell. Probably I should've used Ruby. Oh well.
filter foo xx
filter foo xxPseudocode is better expressed in Python than Lisp, therefore much better in the academic world.
My point stands: READABILITY.
Lisp's parenthetical syntax is not, and never has been, its problem. You say "parenthesis" as a cute excuse to avoid doing any meaningful defense of your rejection of lisp.
I've wondered for years why people latch onto the parenthesis thing. When I learned lisp for a class, I never gave it a second's thought. To me it feels like people are looking for a handy reason to put Lisp down, perhaps either because they don't understand it or because they do understand it and they are jealous of some of the features of Lisp.
Personally I prefer both Forth's RPN and C/C++ (Algol?) style notation to Lisp's s-expressions.
However, I do like the overall elegance that this brings to the code, where code and data are the same. Which is why I also like Postscript -- it does the same thing but in an RPN style (a function is actually an executable array).
Also, there is great support from lisp-friendly editors to handle parentheses management (e.g. paredit for emacs http://emacswiki.org/emacs/ParEdit).