
The Lisp Curse (2011) - jlturner
http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
======
jwr
I used to read these kinds of articles with interest, back in my Common Lisp
programming days. They would worry me. Back in the day, I would even sometimes
participate in language advocacy discussions.

These days, I don't care at all — I just write great apps that work (fast).
Some code runs on the JVM, some code runs in the browser, some runs in both
places. I get to use an impressive set of libraries from at least three
different ecosystems (Clojure/ClojureScript, Java, Javascript). I get to use
fantastic languages with impressive concurrency support. I deliver
applications which customers pay money for.

For me at least, Clojure made this kind of writing totally obsolete, in the
span of several years.

~~~
Scarbutt
You need to add something like python or ruby to your arsenal for quickly
writing scripts that start up fast ;) or do you use nodejs for this?

~~~
jwr
Startup time is something of a red herring for me, kind of like "give me a
single EXE or your language is useless" used to be in the Common Lisp world. I
don't encounter this problem in practical use. But then, I don't use Clojure
to write scripts that I then run hundreds of times from the shell (but why
would you want to do that, rather than write a program that does what is
needed to hundreds of files at once?).

------
nabla9
Lisp is programmable programming language, especially Common Lisp. It works as
programmer amplifier. Better you are, more you benefit from it.

I challenge anyone to watch this lecture from Christian Schafmeister and say
they are not impressed:
[https://www.youtube.com/watch?v=8X69_42Mj-g](https://www.youtube.com/watch?v=8X69_42Mj-g)
and
[https://www.youtube.com/watch?v=0rSMt1pAlbE](https://www.youtube.com/watch?v=0rSMt1pAlbE)

~~~
tosseraccount
What popular programs are written in Lisp?

~~~
stray
The software I produce at work is Ruby. I don't know that it's popular -- but
it is central to a large company's operations.

But I generate and validate that Ruby code with Common Lisp -- in other words,
I write Lisp that writes correct, idiomatic Ruby.

I would be very surprised if I were the only person doing this.

~~~
eudox
Have you written about this somewhere? I've love to read more about it.

------
kazinator
Replicating "pre-AI-winter" success is like trying to replicate "pre-dot-com"
success, et cetera. The past is the past. Such things all depend not on
technical reality but on what was the predominant belief among some non-
technical decision makers. Old Lisp was funded by institutions. There were so
many dialects because multiple institutions were actually developing Lisp
using local talent. That required funds, and dispensation of funds requires
that someone is rationalizing that dispensation based on some beliefs, and
those beliefs are very distant from specific technical ideas like "multiple
dispatch is a beneficial in OOP".

What remains is that the Lisp design contains numerous elements which are
great ideas, which, if they are nicely implemented in their proper form, give
you a great programming language.

That doesn't translate to being able to return to the time when you're
showered with institutional money to just go wild hacking on whatever you
like.

------
mbrock
I don't think there's much explanatory power here at all, actually.

Some of the most popular languages today, from a web development perspective
at least, are JavaScript, Ruby, and Clojure.

One of them is an actual Lisp with full-blown macros and a lot of Emacs users.

The others are also extremely expressive, dynamic, and amenable to
metaprogramming.

I don't think there's a single, simple, beautiful explanation for why Common
Lisp isn't more widely used. Mostly it just has an undeserved bad
reputation... partly because articles like this show up all the time,
reinforcing the stigma of Lisp as a weird language for bipolar geniuses, or
whatever.

~~~
adambard
I am a _big_ fan of Clojure, but you're definitely overstating its popularity
relative to Javascript and Ruby. I would put at very least PHP, and Python
ahead of it as well, and Java and C# probably see more web work done with
them. Clojure is just not in the same league in terms of popularity as any of
these.

~~~
mbrock
It's still very possible to hire Clojure developers, people know about it and
are willing to learn, it's got a good reputation, and so on.

------
zwieback
In 1988 I was an intern at HP Labs and my project was 50% Lisp and 50% C, the
latter half dealing with time-critical IO and low-level routines crunching CAD
tablet input.

At the end of a day working on the Lisp portion, which assembled sketched
lines into a CAD model I went home happy and relaxed with a feeling of
accomplishment. At the end of the C days I felt tense and slightly worried,
thinking about ways of more cleverly detecting what the user was trying to
sketch on the tablet.

In my 20+ years of programming I never returned to Lisp and I don't quite know
why I don't miss it. I have a vague nostalgia for Lisp but I think modern
programming languages give us enough tools to get our job done without feeling
too much shame about abandoning the purity of Lisp.

Also, the proselytizing has not helped. I think the "Blub paradox" article
embodies the mindset that was ultimately the nail in Lisp's coffin.

~~~
mwfunk
I had to Google the Blub Paradox
([https://en.wikipedia.org/wiki/Paul_Graham_%28computer_progra...](https://en.wikipedia.org/wiki/Paul_Graham_%28computer_programmer%29#The_Blub_paradox))
but I see what you mean. It's based on the idea that someone who disagrees
with you about something can't be acting rationally, rather that they are
somehow incapable of perceiving your wisdom. Sometimes that is the case, of
course, but I don't think that explains why Lisp isn't the universal language
that everyone writes everything in.

I have a lot of warm fuzzy feelings about Lisp as well, but a lot of Lisp
advocacy has been of the "One True Language" variety as opposed to "right
tools for the right job, and here's why Lisp might be the right tool for you".
It doesn't affect my perception of Lisp, but it doesn't help market it either.

~~~
force_reboot
The name doesn't help at all. "Blub" has connotations of bumbling stupidity
even without knowing what the "Blub Paradox" is.

------
cperkins
I read the article and thought a lot about it, but I'm not buying it. The
acceptance problems for Lisp haven't been because it is "too powerful" or that
lone wolf hackers won't work together.

The author makes an example of the many Object Oriented (OO) systems, but he
performs some bait-and-switch there. Those many OO systems were for _Scheme_,
not Common Lisp. And Scheme is intentionally a tiny Lisp. For a long time,
Scheme was focused on being the smallest possible Lisp. Common Lisp on the
other hand, while it briefly went through an OO experimentation period, really
only has one OO system: CLOS.

Also, the whole Emacs line is off target too. What has that to do with the
expressive power of the language? And why ignore the two extremely powerful
commercial Common Lisp IDE's out there? So is the point that Common Lisp isn't
successful because there isn't a better free IDE?

And the "lone wolf/80%" isn't doing it for me either. The Common Lisp
specification was the work of many bright minds and is brilliant. And it
stands in complete opposition to the situation the author attempts to
describe.

I'm not saying that Lisp in general (Scheme, Common Lisp, and Clojure) has
been successful, or that Common Lisp in particular has been. If the standard
is mindshare and acceptance they have not been successful. There are histories
and causes aplenty, but being too powerful is not one of them.

------
winestock
I'm the author of this essay. This must be at least the third time that it has
appeared on Hacker News. I'm starting to get sick of it, myself, but I keep it
up because so many people like it (at the bottom of the page, you can see the
translations; all done gratis by volunteers).

I wrote it during a period when I was especially fascinated with Lisp and got
caught up in the theorizing to which the Lisp community can be prone.
Nowadays, I freelance in front-end web development and doing Lisp hacking is
something that I put on the back-burner.

~~~
Scarbutt
so you just use javascript? I'm in that period of fascination, any practical
advice? ;)

~~~
winestock
For now, yes. My life has taken some unexpected detours, these past few years,
so I have to focus on work rather than inspiration.

~~~
pareidolia
Have you ever put (any, as in CL, Scheme etc.) Lisp into practice? I got the
impression from the essay that you think that everything in a Lisp consists of
macros, which is not the case.

------
jdblair
A personal anecdote:

I stumbled on LISP and Scheme around the time I graduated from high school in
1991. I became interested in LISP from learning about classic AI research. I
found a professor my first year in college who mentored me in an independent
study of LISP. I then learned scheme doing a self-study with SICP.

Despite all of this, I've never done any paid work in LISP, and I've spent the
majority of my career writing C. I can't write a LISP program from scratch
from memory any more.

However, I've found that the ideas of functional programming and the concept
of the read-eval-print loop have colored my understanding of software design
in a really positive way. I remember when I learned TCL in the mid 90s it was
immediately obvious that TCL is just LISP on strings (read-substitute-print).
Lua is also very LISP-like, with tables instead of lists.

------
lmm
Power is a weakness in a programming language, not a strength - some of the
most interesting research languages today are not even Turing-complete. It's
easy to add expressiveness to a clunky language; it's much harder to add
limits to an expressive language that prevent expressing nonsense.

~~~
kazinator
"Expressive power" and "computational power" aren't the same thing.

Turing's original Universal Machine (you know, the moving read/write head over
an indefinitely long tape of symbols) is not expressive at all; a simple task
like adding two integers on that machine requires a completely arcane, verbose
piece of gobbledygook to be prepared on the tape, where you cannot tell at a
glance which part of it is the program, and which is the integers to be added.
It is less expressive than 4 + 4 in a calculator language that doesn't have
loops.

Expressive power is, in its barest essence, the freedom to assign an arbitrary
meaning, from some domain, to a new combination of symbols, such that every
symbol in that combination refers to some entity in that domain only.

It behooves us to have a general-purpose language with as much expressive
power as we can get our hands on.

It is not hard at all to add restrictions in domain languages created inside
an expressive language. For instance if you make an x86-64 assembler in Lisp,
it will be just as restricted as any other assembler; it will diagnose
unrecognized opcodes, bad addressing modes, etc.

~~~
lmm
> For instance if you make an x86-64 assembler in Lisp, it will be just as
> restricted as any other assembler; it will diagnose unrecognized opcodes,
> bad addressing modes, etc.

But it won't enforce those things at compilation time in the type system,
because it doesn't have one. You might have a macro that checks them, but it
would be ad-hoc.

~~~
mbrock
Another commenter already said that Common Lisp indeed does have a type
system. It's possible to circumvent, but that's Lisp for you.

You can very easily write an assembler in Haskell that doesn't verify any of
that stuff statically. Learning to do advanced kinds of static verification
with Haskell's type system is actually rather difficult, and usually requires
language extensions.

Using a macro that checks those things seems like it could be a very pragmatic
way to provide safety. It might also let you verify properties that would be
hard to figure out how to verify using only Haskell-style type checking.

Indeed, Haskell programmers often use QuickCheck to do ad-hoc verification of
type class laws, for example, since they can't be proven in the type system.

~~~
lmm
> Learning to do advanced kinds of static verification with Haskell's type
> system is actually rather difficult

Perhaps. But it benefits greatly from being a consistent way of doing things:
everyone does their static verification the same way, because the language
supports exactly one way of doing it.

> and usually requires language extensions.

Sometimes. But again at least those extensions are relatively standardized,
rather than completely ad-hoc as a macro can be.

> Indeed, Haskell programmers often use QuickCheck to do ad-hoc verification
> of type class laws, for example, since they can't be proven in the type
> system.

Yeah, that's one of the reasons I'm excited about Idris. But even in your
example, QuickCheck is again a standardized way of doing this.

~~~
mbrock
Well, all you need to do in a macro to provide error checking is to assert or
raise a condition when something is wrong. That's pretty standard.

In Haskell land, you can do wonderful things like Servant, the statically
verified API server—but that kind of code is very advanced, and written by a
shadowy cabal of type level wizards. I think there is less of a standardized
way of doing this stuff than one might expect.

I'm not really sure what you mean by "standardized." Common Lisp is an actual
ANSI standard... But you seem to be referring to the existence of common
practices.

I'm not convinced that the problem you describe is actually a problem, and I'm
not convinced that Haskell or Idris will end up being more successful in the
mainstream than Lisp.

(I'm a huge fan of Haskell, Agda, and static/dependent typing, for the
record.)

~~~
lmm
> Well, all you need to do in a macro to provide error checking is to assert
> or raise a condition when something is wrong. That's pretty standard.

Sure, but the conditions that lead you to do that can be arbitrary Turing-
complete code. IIRC in unextended Haskell what you can do at type-level is
more restricted; certainly you're guided towards a particular way of
structuring your constraints. That in turn makes it more practical for other
tools to support your constrained sublanguage.

I think the future of programming lies in constrained (BWIM non-Turing-
complete) languages and provably correct code. I guess we'll find out.

------
jcfrei
previous discussions:

[https://news.ycombinator.com/item?id=3808194](https://news.ycombinator.com/item?id=3808194)

[https://news.ycombinator.com/item?id=2450973](https://news.ycombinator.com/item?id=2450973)

------
kruhft
For those that are interested, here's some livecoding streams of me developing
and working in a Lisp I'm developing Sigil:

[https://www.livecoding.tv/burtonsamograd/videos/](https://www.livecoding.tv/burtonsamograd/videos/)

See the 'building a language' parts for actual lisp programming, the rest is
JS webdev.

Sigil is a minimal lisp with only the basic primitives (cons, car, cdr, cond,
null, atom, lambda and a few others) and macros. The project is an experiment
in building a lisp from the axioms and seeing how far one can go without
having to add to the underlying lisp implementation (which is in javascript).

------
Animats
This is not the curse of LISP; it's the curse of compile-time macros. Any
language extensible at compile time has this problem. C++ has it. (See Boost).
Rust seems headed there. You can even do this with C macros.

There was, around 1990, a fad for "extensible languages".[1] It died, because
the resulting code was so hard to read, with program-specific syntax for each
program. Don't go back there.

[1]
[http://www.cas.mcmaster.ca/sqrl/papers/SQRLreport47.pdf](http://www.cas.mcmaster.ca/sqrl/papers/SQRLreport47.pdf)

~~~
sklogic
I really hope that extensible languages are the future. It is unfortunate that
a majority of their users had no clue on how to properly extend the languages.
It's about a time to fixe it.

> resulting code was so hard to read,

DSL code is the _easiest_ to read and maintain. No "general purpose" language
would ever match this.

> with program-specific syntax for each program.

As if it's something bad.

> Don't go back there.

You failed to understand the entire concept.

~~~
rndmio
> You failed to understand the entire concept.

I don't think so. As the article states, this is a social/community issue, if
every application has it's own language and syntax that is a huge barrier for
others coming to work on it. You might not care about that but most large
pieces of software are not written by one person. Beyond that you come to
issues of code and skill reuse. A lot of people dislike the expressibility of
Go, but it's hard to write code that someone else can't easily come and read
and understand.

~~~
sklogic
> As the article states

The article is plain wrong.

> if every application has it's own language and syntax that is a huge barrier
> for others coming to work on it

And this is quite obviously not true. A _well designed_ (note the emphasis!)
DSL makes any app/problem domain/library/whatever much more accessible than
any kind of a "general purpose" language can. Simply because DSL does not
obscure the essence of the problem.

> Beyond that you come to issues of code

Code reuse with DSLs is way beyond anything the inferior languages can
achieve. I witnessed cases where 30+ years old DSLs got revived by
reimplementing them from scratch, immediately making an entire (huge) code
base available on a new platform, with new tools and bells and whistles.

> and skill reuse.

One should never care about those pitiful "language" skills. They're
worthless.

~~~
weareconvo
Your argument here seems to be that even if the majority of programmers find
Lisp and all its derivatives to be difficult to read, we're wrong.

~~~
AnimalMuppet
No, it's more of a No True Scotsman. People have written DSLs that are
unreadable, but those DSLs weren't Well Designed(TM). So their failures don't
count against DSLs, because only well designed DSLs count.

I think empirical evidence is that DSLs are easy to make not readable,
especially as they evolve. Then again, that's true of almost everything,
including assembly language programming, structured programming, object
oriented programming, and functional programming (did I miss anything?).

------
diogofranco
There are many good points in this article and even the variety of Common Lisp
implementations in existence attest to the author's point. It seems that
everyone is rolling out their whole new CL implementation.

That said, even if it were true that the power of lisp turned out to be it's
curse, one should be careful to generalize this way about _lisp hackers_ ,
_80% projects_ and lack of documentation. The language might tempt you to
become the hacker portrayed in this article, but it certainly doesn't fight
you should you want to follow best practices.

~~~
pareidolia
Having multiple implementations wasn't a problem for Java (Sun JDK, IcedTea,
JRockit), noone thinks much of the different compilers available for the C
family (GCC, CLANG, Microsoft C compiler, Intel's C compiler), consider Ruby
with MRI, JRuby, or Python. I could go on.

Members of the Lisp family seem to be judged by a different standard. I don't
know why that is.

My perspective: the implementations attest to good documentation and
collaboration. SBCL by itself is an admirable artifact with extensive
documentation that's been maintaned since 1999 (when it forked from CMUCL).

So what gives?

------
agumonkey
Reading this I wonder if the everybody rewrites everything is that much of an
issue. The benefits of it-crowdsourcing capitalized through libraries isn't
obvious to me. Some languages make it necessary to distribute the cost of
libraries through groups. Maybe Lisp allows to skip that and go straight at
the problem. I remember one article about a guy looking at a Graph library for
Java. He found two, generic, typed, object and all that; they were more a
problem than a solution. He made its own thing in Lisp and called it a day.

------
DanielBMarkham
I like it. It's a keeper. Also the argument is a bit overstated.

 _"...The moral of this story is that secondary and tertiary effects
matter....Employers much prefer that workers be fungible, rather than
maximally productive...[in regards to creating a larger framework] The reason
why this doesn't happen is because of the Lisp Curse. Large numbers of Lisp
hackers would have to cooperate with each other..."_

So here's what I see. I see a lot of frameworks and libraries composed by
folks using other languages. Many of these, yes, are much more complete than
one, totally-custom-made solution by some Lisp hacker. And yes, large numbers
of people participate in creating and maintaining these larger frameworks and
systems.

I also see large corporations _bleeding_ cash because they wanted silo'ed,
fungible programmers. Got seven architectural tiers, each with its own
framework? Hell, you're going to need seven extremely specialized programmers,
kid. Time to get on the phone with the recruiter.

So they purchase these specialists. All the buzzwords match. The specialists
sit down at the magic frameworks, the ones all the cool kids over the last two
years have decided to support. Life is good. For about ten minutes. Then
something is required that's not in the frameworks. Or the framework is broken
under this one particular edge case.

Suddenly we need somebody who's general purpose again. Except -- and this is
especially nice -- that's not the guy we hired. So seven layers of experts sit
struggling with seven oddball issues. Googling Stack Overflow. Hacking the
crap out of things. Making a total mess.

And at the end of the day, if we're lucky, something ships. Something with
little problems here and there that requires seven different areas of
expertise to figure out. Plan on maintenance being fun.

The next day version 2.0 of the framework on layer 5 ships. Now if you want
maintenance programmers, for layer 5 they have to know both version 1.0 and
2.0

More complexity continues. It's fun for everybody.

Compare this to the guy who uses a standard language, decades-old libraries,
hacks out a partial solution (but good enough to ship) in a few days and then
moves on to something else. Now tell me that the framework guys have a better
technology development model. I ain't believing it.

I'm not saying become a lone wolf and never work with folks. I'm saying that
"working with folks" can completely kill any kind of value you're trying to
create. Do it wisely.

------
xrange
I wonder why there is all the anguish around why Lisp hasn't flourished, and
seemingly less anguish around APL, or even Smalltalk. Is there a reason it
engenders so much loyalty? Is it the idea that macros allow you to extend the
language, and that seems like the pinnacle of the programming hierarchy? Could
there be insight gleaned from looking at programming languages as a fad or
style?

~~~
tanker
I think it is because, for a lot of people, Lisp is fun.

If Lisp flourishes, more people would get to use it at work.

Lisp not flourishing means less fun.

Also, when I've worked in Lisp it just seemed like the right way to do things.
Everyone likes to do the right thing, so anguish results when you seem denied
the opportunity to follow the path you feel is right.

That said, I think the author was right and the community issues and ease of
building your own solutions will limit Lisp as a language family.

~~~
lokedhs
I can definitely subscribe to the idea that Lisp is fun. The application I
have been writing (featureful chat application like Slack) has a server side
completely written in Common Lisp by myself. Why do I work on it even though
it's unlikely that it will ever draw anyone away from Slack?

Because it's fun.

Is it possible to do the same in another language? Sure, Slack is proof that
it's possible. But would I have persisted in actually doing it without any
hope of profit? No, because programming in other languages is a chore, and the
only light at the end of that tunnel is the finished product.

With Lisp, the journey is a reward of its own.

Yes, I know the same thing has been said by Haskellers and others, but I doubt
it was ever said by a C++ programmer.

------
arijun
I think that Clojure mitigates these issues quite a bit for a couple reasons:

\- The core library is has enough built in that many questions are answered
using built in solutions (e.g. what is done with objects elsewhere is very
frequently done with maps and functions that operate on maps) \- The language
designer (Rich Hickey) is very opinionated, and the language tends to attract
people who agree.

There still are multiple choices when it comes to solving some problems (Om vs
Reagent vs Rum vs etc.), but is that really that much different than other
languages? Javascript has a million choices for the same domain.

------
bch
"BBM" == Brilliant Bipolar Mind. The acronym is used in "The Lisp Curse"
citation of The Bipolar Lisp Programmer, but defined elsewhere in material not
cited.

------
bitwize
People who care what other people think about the programming languages they
use write essays like this.

The rest of us just shut up and hack some Lisp.

------
PaulHoule
The homoiconic thing is not all it is made up to be. That is, you can take
(say) Java and parse it to an abstract syntax tree and the manipulate the
tree.

Assuming you have a good toolbox of operators, working with that kind of AST
is not much harder than working with s expressions. Maybe it is easier if you
can build a general notation that can be generalized for multiple languages
and also represent more ordinary data such as json formatted, relational, rdf,
etc.

~~~
retrogradeorbit
I couldn't disagree more. Working with that kind of AST is many orders of
magnitude harder than Lisp macros. None of it is first class. You brush over
it in your comment like writing a Java parser is trivial. My clojure parser
returning the AST in its entirety is: (read-string (slurp "my-source.clj")).
What does your Java one look like?

The proof that it is so much harder is that no one ever does it. Yet people do
this all the time in Lisps. If its "not much harder" I'd expect to see more of
it, but I don't, because it is just so much work.

Aside from parsing, what about templating. Yes, you can manipulate the AST
once you have it, but what would templating AST look like? Would it look just
like the Java code? With the syntax quote in clojure it looks very much like
the output. How would you even begin to template syntax in your hypothetical
Java implementation?

~~~
PaulHoule
1\. I am not writing a parser, one already exists and can be brought in about
as easy as your code sample. 2\. I am translating the AST to rdf which lets me
work on the AST with production rules 3\. If I wanted templates I would use
templates. What I do do is start out with an abstract representation and then
apply say 20 simple transformations that step by step fill in the details to
get to code. Speed is OK because we have indexes, rete networks and other
tricks. 4\. People are not doing it yet and this is why people are saying code
reuse is hard, etc. 5\. The transformations are written in a sparql derived
rule format that itself uses the transformation system to add features by
composition.

~~~
retrogradeorbit
I feel like you are being disingenuous. Do you have any experience with Lisp
macros? Please enlighten me. Show me how you parse Java, into rdf, and then
into AST in one line. And a link to this "already existing" parser would be
great. Also, can you link me to some examples of this sparql derived rule
format so I can compare.

~~~
PaulHoule
See

[http://www.eclipse.org/articles/Article-
JavaCodeManipulation...](http://www.eclipse.org/articles/Article-
JavaCodeManipulation_AST/)

as for SPARQL derived rule format see

[http://spinrdf.org/](http://spinrdf.org/)

although we've done a bit to humanize the syntax and try to add back some of
the features that were common in production rules engines back to the 1970s.

------
draw_down
I think this is not properly accounting for the difference between something
that's 90% done, and something that is done. (Nothing is ever finished, of
course, but you know what I mean.) As we all know, the difference between the
two is not simply a gap of 10 percentage points. Far from it.

Teams of people were required to write Haskell and Dr Whatshisname tossed off
Qi by himself. OK, but people use Haskell, does anyone use Qi? If not, then
it's not a problem for Qi to be 90% done. And that's a lot easier to
accomplish by oneself.

------
justnotforme
A lot of thoughts about lisp; are written by zealots; who like to create the
impression that they are playing with some kind of dangerous mind amplifying
meta language; and if you start using it; you might accidentally unleash
creatures from the id. But then you look at it; and find it is simply a
programming language.

------
arijun
Should add a (2011) to the title.

~~~
dang
Added.

------
chetanahuja
_" It's so damn hard to do anything with tweezers and glue that anything
significant you do will be a real achievement. You want to document it. Also
you're liable to need help in any C project of significant size; so you're
liable to be social and work with others. You need to, just to get
somewhere."_

Oh is it time already for another "C is for idiots" thread from Lisp
supremacists again? If Lisp fanboiz were slightly less busy ridiculing the
rest of the world over how stupid everyone else is, they might even have had
some time to pay attention to silly things like performance and tooling. That
might help the adoption a bit more than the supercilious rock throwing that is
almost exclusively the tone of every single article/post from Lisp lovers.

~~~
raspasov
C is the king of raw performance, there's no denying that. But for the vast
majority of high-level, user-facing applications today it's a bad fit.

Clojure is more than fast enough for serious server side programming, often
coming close to Java in performance with minimum amount of tuning needed in
the average case. When you add multithreading into the mix, it's not even a
contest; the amount of time you'll have to spend to make an idiomatic Java or
C++ run both correctly and fast is gargantuan compared to a language where
concurrency was built-in from the start.

