
Why didn't Common Lisp fix the world? - weeber
https://www.quora.com/Where-did-we-go-wrong-Why-didnt-Common-Lisp-fix-the-world?share=1
======
DonaldFisk
I'll cons this onto my list of reasons why Lisp "failed". Other explanations
are:

Worse is Better: [https://www.jwz.org/doc/worse-is-
better.html](https://www.jwz.org/doc/worse-is-better.html)

The Bipolar Lisp Programmer:
[https://groups.google.com/forum/#!topic/comp.lang.lisp/eicqv...](https://groups.google.com/forum/#!topic/comp.lang.lisp/eicqvm3GXiE)

The Lisp Curse:
[http://winestockwebdesign.com/Essays/Lisp_Curse.html](http://winestockwebdesign.com/Essays/Lisp_Curse.html)

Where Lisp Fails: [http://www.loper-os.org/?p=69](http://www.loper-
os.org/?p=69)

Lisp is still my language of choice. I'm more productive in it than other
languages (C, Java), not because I know the other languages less well, but
because they're less expressive. So, for me, Lisp fixes the world.

Why aren't people using it? There are three things often missed.

(1) People's choice of programming languages perhaps isn't as rational as they
might like to believe. There's a large amount of personal taste involved. For
a personal project, that's no barrier, you can use your favourite language,
but if you're working with a dozen other people, Lisp is unlikely to be
adopted because more people on the team will prefer Java, C++, or Python.
Multiply over all the commercial projects and you can see why you can't build
a career around Lisp programming.

(2) There are accidents of history. When DEC decided to discontinue the
PDP-10, the days of the hacker community built around it were numbered. Those
involved then went on to build Lisp machines, but they were undercut by
cheaper, commodity hardware which ran Unix. Then, the AI winter arrived. It
was bad for Lisp, but Prolog fared far worse.

(3) Linguistic relativity. The Sapir-Whorf hypothesis might be dubious for
natural language, but for programming languages it certainly does apply. If
you're uncomfortable with Lisp, you won't be tackling problems at which Lisp
excels, or (at best) you'll do them in a completely different way, and it will
take you longer. The result is that people think their language of choice is
fine for everything that matters, and the problems they don't tackle don't
matter to them.

~~~
hga
_(2) There are accidents of history. When DEC decided to discontinue the
PDP-10, the days of the hacker community built around it were numbered. Those
involved then went on to build Lisp machines..._

Nit on this bit of history: the PDP-6/10/Decsystem 20 architecture was a dead
end due to its maximum address space of 1 MiB (of 9 bit bytes), but was still
a very healthy line of computers when the Lisp Machine effort started circa
1974, about a decade before DEC dumped the whole line, then a 100 million a
year business (a lot of us looked at that and decided DEC's business sense was
so poor we weren't going to invest any more then we could in their systems,
which of course turned out to be absolutely right).

------
lispm
For those who don't know Peter Norvig, let me mention that he wrote one of the
best Lisp books:

[http://norvig.com/paip.html](http://norvig.com/paip.html)

~~~
dragonquest
Not just one of the best Lisp books; but one of the best books on programming,
period.

~~~
S4M
I think it's a programming book that happens to use Lisp as an example
language to explain AI concepts and algorithms, rather than a Lisp book.

~~~
lispm
Actually not. The book is full of beautiful code, combined with deep Lisp lore
how to write that code.

------
chvid
Why on earth would it fix the world? It was a step forward in the history of
programming languages; but somehow the end of it, the final fix? Why would
anyone expect that?

Programming languages are about providing a useful way for humans to formulate
and implement their ideas. Starting by turning things on their head reverse
polish notation style is bad start as it is counter intuitive to nearly
everyone.

~~~
dunkelheit
My theory is that because programming is mostly about fighting incidental
complexity, it is very easy to believe that if there were some way of getting
rid of it, programs would write itself and programming would be reduced to
sipping daiquiris on a beach.

Lisp (especially compared to C) indeed helps to reduce incidental complexity
to some extent. So it is easy fall into almost religious belief that Lisp is
_the way_ to pure programming bliss. Of course the promise is never fulfilled
because domain complexity and even incidental complexity is here to stay.

~~~
sklogic
> helps to reduce incidental complexity to some extent

This extend stays untapped. You cannot even imagine how far this ability to
eliminate complexity extends.

Of course, it's not just Lisp, it's Lisp (or any other meta-language) combined
with a certain design methodology.

A methodology which pretty much boils down to a notion that "everything is a
compiler". And, since compilers are trivial and there are well known
techniques for eliminating _any_ complexity you can find in a chain of
compiler transforms, this way you can eliminate all possible complexity, no
matter what your domain is.

Yet, I find it amusing that only a handful of people are even aware of this
ultimate methodology.

~~~
pjc50
_since compilers are trivial_

No.

 _and there are well known techniques for eliminating any complexity you can
find in a chain of compiler transforms_

Any complexity? Really?

~~~
sklogic
> No.

Why would you say so? There is nothing simpler than compilers. They can be
broken down into pieces as small as you like which are still independent and
fully sequential. Most of the rewrites you'll ever need to do can be done in a
_total_ language - i.e., you don't even need Turing-completeness for most of
your code.

> Any complexity? Really?

I have not met a kind of complexity that cannot be decomposed into trivial
pieces mechanically using this technique. And I've seen a lot of very
different things.

P.S. And try not to confuse a _size_ with a complexity. E.g., C++ spec is
huge, and implementing a compiler for the full language is a daunting task.
_Long_ , but not _complex_.

~~~
hga
Well, one thing I can tell you is that I've heard that much of the woe that
came from the Common Lisp standard started with the line "any sufficiently
advanced compiler..." in a discussion.

~~~
sklogic
Are we talking about optimisations now? Or still about a _compilation_?
Optimisations are a totally different story. They can bring some complexity
in, but the nice part is that they're totally _optional_ and not required for
_solving_ the problem.

~~~
hga
_Minimally acceptable_ optimizations, because if your implementation is too
slow, they're not optional.

The examples are legion; to go to another domain, look at one of the reasons
the VLIW Itanium failed, except for some numeric code the compiler(s) couldn't
schedule enough operations for those Very Long Instruction Words.

(Perhaps a more primary reason was that x86 code ran too slow, denying
customers an easy upgrade path that due to volume sales might have resulted in
more effort being put into the VLIW compilers.)

~~~
sklogic
Remember, we're not talking about high performance C compilers and all that
here.

We're talking about the programming paradigm where _everything is a compiler_.
Network protocol parsing is a form of compilation, all file formats parsing is
a form of compilation, reacting to the UI events is a form of a compilation,
processing data in whatever ways is a form of a compilation.

Yet, you can only invent any optimisations at all for a small subset of
compiler transformations, so for most of the cases optimisation is just
totally irrelevant.

As for the minimally acceptable optimisations, they're all trivial anyway.
What you'd normally expect to see in most of the IRs is: constant
propagation/folding (trivial), ADCE (trivial), algebraic simplification
(trivial, no matter how ugly it is in, say, instcombine pass in LLVM - they're
just doing it wrong), partial evaluation (trivial), inlining (trivial),
backtracking for the latter two (trivial, but rarely seen, most would resort
to awfully complex heuristics instead), CSE (trivial), escape analysis
(trivial).

What is not trivial is the stuff you'd rarely need in the _high level_
languages, and this paradigm is all about the high level languages indeed.

Not trivial: loop fusion, polyhedral analysis, vectorisation, and, finally,
everything related to the code generation: instruction selection, register
allocation, instruction scheduling, VLIW packing, all that.

You'll never see this stuff in any high level domain specific language - you
already have a common low level backend to take care of it for you anyway.

------
adwf
I often think it's because Common Lisp was one of the last pre-web languages
to be designed (or standardised anyway). Newer languages like
Java/Javascript/Clojure/etc. had the advantage of being able to build a strong
community on the web. Whereas Lisp was just on its way out as the web was
rising.

The hardware and the long standardisation process didn't help either. That,
combined with it being both an old and a new language, meant that when the
spec was done there wasn't the excitement you get with a new language like
Python or Clojure. It missed the boat with building a web community and missed
again in building hype.

However, Norvig is completely correct in saying that just because the CL
language itself may not have taken off, doesn't mean the ideas didn't make it
everywhere.

~~~
paddy_m
Perl and python, and c++. Perl especially was influenced by newsgroups, so
maybe that doesn't count.

~~~
adwf
Yeah, but they arose as the web was starting in the 90s. Whereas Lisp had been
around since the 50's. The standardisation effort wasn't the development of an
exciting new language, just the finalisation of an old one.

------
mtrycz
While i do like the the idea of DSLs and they certainly do have a place, what
I would _love_ to have is to be able to enforce a strict subset of a language
in a piece of code.

Where first there was discipline and hardly passed on conventions, there now
would be statically enforced rule coerction.

I deeply believe that the utility of language is not in what it enables, but
in what it forbids. For example Clojure and Rust have neat mechanisms to deal
with mutability, where you need something extra to mutate a value. Contrast
this to C where you need to go extra lenghts to make things const (ie
nobody'll do it).

Is this even possible without writing your own tools?

~~~
klibertp
Racket.

It's built as a platform for defining arbitrarily simple or complex languages
and integrating them together. You should take a look at it. See
[http://www.ccs.neu.edu/home/matthias/Thoughts/Racket_is____....](http://www.ccs.neu.edu/home/matthias/Thoughts/Racket_is____.html)
:

> To a language designer, Racket is a programming language laboratory. This
> does not mean that the language is unstable. The designers do not change the
> language in a whimsical manner. That is, Racket comes with a unique
> collection of linguistic mechanisms that enable the quick construction of
> reliable languages, language fragments, and their composition. These tools
> are so easy to use that plain programmers can design a language after a
> little bit of instruction. So when a well-trained programmer decides that
> none of the available dialects is well-suited for a task, he designs a new
> dialect and writes his program in it. As Paul Hudak said, “the ultimate
> abstraction is a domain specific language.”

------
smcl
It's interesting to see Peter Norvig replying, but his answer is a little
unsatisfying "oh but it did..."

The more interesting and honest reply in my opinion is ranked in second place
by Robert Smith - sounds like he did some proper reflecting on what it is to
be a Lisp programmer nowadays and what the language's (or implementation,
since this question is for CL specifically) shortcomings are

------
nabla9
"And you're right: we were not out to win over the Lisp programmers; we were
after the C++ programmers. We managed to drag a lot of them about halfway to
Lisp. Aren't you happy?" \-- Guy Steele, Sun Microsystems Labs (about Java)

[http://people.csail.mit.edu/gregs/ll1-discuss-archive-
html/m...](http://people.csail.mit.edu/gregs/ll1-discuss-archive-
html/msg04045.html)

~~~
jeffreyrogers
If Java is halfway to Lisp it's no surprise Lisp didn't take over the world.

~~~
wry_discontent
In what world is Java halfway to lisp?

~~~
wglb
In a world filled with COBOL, C, Powerbuilder, CICS. Oh, and TELON.

~~~
wglb
And there may have also been a language GOOFBOL (where BOL is Business
Oriented Language), but I may have just made that up.

------
hack37
Having recently been introduced to the lisp world (~1 year) it has been a
revelation to me. It really changed the way I see programming and my
expectations of it.

I do not understand how it has not taken over the world.

Background: I have ~15 years of experience in programming. In my spare time I
learn new languages.

~~~
rodgerd
> I do not understand how it has not taken over the world.

> In my spare time I learn new languages.

A moment's reflection on the latter would explain the former.

------
keymone
i feel like a lot of lisps are trying to drag this "everything is a list"
abstraction way too far than they should. clojure takes more practical and
pragmatic approach of giving native residency in a language for useful data
structures like arrays, maps and sets and it (along with many other features)
has totally won me over. it's incredibly important for a language to be
convenient.

edit: and not only me it seems:
[https://www.google.com/trends/explore#q=%2Fm%2F03yb8hb%2C%20...](https://www.google.com/trends/explore#q=%2Fm%2F03yb8hb%2C%20%2Fm%2F06zrb%2C%20%2Fm%2F01tlw%2C%20%2Fm%2F0974fb&cmpt=q&tz=Etc%2FGMT-2)

~~~
nabla9
>i feel like a lot of lisps are trying to drag this "everything is a list"

I think you are speaking out of ignorance here. "everything is a list" is just
a metaphor. Everything is either list or atom and almost everything is atom.

~~~
keymone
> Everything is either list or atom and almost everything is atom.

how can you both say this and that i'm talking out of ignorance? you're
basically confirming my words.

larger point i was making is that "everything is a list" abstraction/metaphor
influenced the decision to not include native representation of other data
structures into the language. because parens are enough to represent
everything. well they aren't enough for people looking for convenient,
practical and simple languages.

~~~
Grue3
No, you're wrong. Common Lisp has hash-tables, arrays and pretty much any data
structure you need. But they are not lists, they are atoms. Hence why almost
everything is an atom. It's well known that linked lists are inefficient in
many ways. Nobody writes programs using only lists.

~~~
keymone
absence of data literals. i'm not sure how can i state it clearer.

------
lcall
While Lisp had big, influential ideas, it wasn't at any time the shortest path
to getting their immediate task done, for "enough" programmers. The successful
languages managed to be the shortest path to "done", for more use cases.

(Which makes me think about my project for managing the world's knowledge,
[http://onemodel.org](http://onemodel.org) and how to be more practical like
fortran or cobol were in their prime, and not primarily idealistic like Lisp
in its prime. Hmm.)

------
starseeker
It lacks a graphical application development framework that's portable and
usable. Java eventually solved this problem (more or less) but neither Garnet
nor CLIM ever reached a level where most Gtk/Qt/* programmers would seriously
consider using them. Web front ends are find for certain things, but for a lot
of the application domains where you might consider Lisp you want a proper
desktop GUI application. (This would have been especially true in the early
years.) The expressiveness and power of Lisp look a lot less attractive when
you run headlong into the practical problems of combining that power with a
modern GUI.

There are still a few problem domains (like Computer Algebra) where Lisp
provides enough benefits to be worth bridging the gap between its world and
modern operating system environments, but by and large the inability to be a
complete solution I think serves as a disincentive to use Lisp.

~~~
_ph_
For portable and easy to use there is LTk, and of course there are bindings to
Gtk and Qt. I think though, if the Lisp community were a bit larger, these
bindings would see more development and more refinement.

------
VeejayRampay
It might not have fixed the world, but it has been an influence on other PLs
and programming in general. It helped bring several interesting concepts to
the forefront and it at least provided an alternative, which is nice and
healthy. LISP didn't "fix the world", but in my view, it helped make it
slightly better.

------
mathheaven
Lisp is only a general idea about syntax and macros. If you want numerical
computations you want a big library like blas, and the problem is about
efficient memory allocation, cache and garbage collection. If you want deep
learning you want a big library.

Lisp is like arithmetic, without more concepts or libraries it doesn't work,
you have to reinvent the wheel.

R provides near 8000 useful packages, that's what makes a language a useful
tool to solve a problem, and it can call routines in C, fortran or use C with
armadillo. To sum up, a language without a great community and specific
libraries is not a way to fix the world, on top of that there are few jobs
using Lisp. Clojure is trying to take advantage of all those java libraries,
that is a good step in the right direction. Clasp is another idea trying to
use C++.

------
lazyant
For the same reason a lot of people can play the guitar but not the violin;
it's easier (at least to get started) and in many cases get the job done so
the other option is not missed.

------
jordigh
I'm pretty sure the biggest reason it hasn't caught on is the syntax.

[http://jordi.platinum.linux.pl/piccies/lisp.png](http://jordi.platinum.linux.pl/piccies/lisp.png)

It's the most frequent complaint uttered against Lisp for a reason. All of the
other things mentioned in the top responses are addressed by modern Lisp
variants. If Rust or Swift were implemented with sexps and everything else
about them were equal, they would have a lot of difficulty winning hearts and
minds.

~~~
pjmlp
Usually people that complain, don't spend time counting the amount of times ()
[] {} appear on their beloved programming languages.

    
    
       print(args) => (print args)
    
       if (cond) { exp1} else {exp2 } => (if (cond) (exp1) (exp2))
       
       array[index] => (index array)
    
    

And so on. On average there is probably the same amount, but visually it kind
of appears to be more.

~~~
thiht
You took _the_ examples where the number of parentheses is the same. Here is a
more honest example:

    
    
        if (a && !b) {expr} => (if (and (a) (not b)) (expr))
    

That's a simple expression and I'm not even sure I managed to match the ()
correctly

~~~
escherize
I agree it's hard to write lisp without a proper editor. Having seen the light
I just can't go back now. The power, ease, and simplicity are not something
I've experienced with non lisps.

~~~
jordigh
I don't know much about Lisp, but at ILC 2014 [1] there were about 40
participants. In a show of hands, absolutely _all_ of them used Emacs to write
their Lisp. I've never seen Emacs unanimity anywhere else.

\--

[http://ilc2014.iro.umontreal.ca/](http://ilc2014.iro.umontreal.ca/)

~~~
escherize
Incedentally I also use Emacs for editing lisp. (emacs lisp and Clojure.)
Learning the hotkeys/concepts behind structural editing of lisp code was life
changing metamorphasis, but quite difficult overall. There's been some
fantastic work done by the Parinfer [1] team to bring the awesomeness of
structural editing of lisp to the masses. The basic idea is that your
parenthesis should infer where they belong by way of your indentation.

I installed Parinfer it on my project: CLJSFiddle[2], and it's not what I'm
used to and doesn't have everything but for a novice it is highly usable -
check it out!

[1]
[https://shaunlebron.github.io/parinfer/](https://shaunlebron.github.io/parinfer/)
[2] [http://cljsfiddle.com](http://cljsfiddle.com)

------
znpy
I bought Graham's "Ansi Common Lisp" book and read it briefly, and tried to
write some code as well.

I also read "Successful Lisp" briefly.

Hoping to give constructive feedback and not to start a flame, here are some
opinions/impressions.

Please note that :

1\. These are mostly impressions, not complete opinions.

2\. I am only talking about Common Lisp. I am not talking about Scheme,
Clojure or other stuff.

Ok then:

1) Lisp feels... Messy. Expecially when you're learning it.

2) Maybe... Too many implementations? This is not a problem per se, but
sometime it happens that not all the implementation implement all of the
features, or implement them differently enough that you have to write the same
code for different interpreters.

Example: [https://github.com/stumpwm/stumpwm/blob/master/make-
image.li...](https://github.com/stumpwm/stumpwm/blob/master/make-
image.lisp.in) see the various #+clisp, #+sbcl and stuff.

3) Batteries not included. The ANSI standard defines the language and pretty
much nothing more. Yeah you have libraries and quicklisp, but it feels fragile
and quite "opaque". Also, I always used SBCL and I am not 100% sure all the
libraries work with all of the interpreters/compilers.

I feel it would be nice to have a new standard that defines a set of
additional API that implementors should implement.

Ideally, it would be nice to have common lisp to be "batteries included" like
Python. But please let's avoid the Scheme SRFI mess.

Consider this: it is a fact that MIT introductory programming class switched
from Scheme to Python because among other things, students were spending too
much time reading libraries manuals and implementation references instead of
writing code.

5) The Common Lisp HyperSpec. Let's say I find it to have a poor usability.

4) Stuff is generally poorly documented, and fragmented. While things like
quicklisp work, it's visible that those are basically one-man projects. This
isn't reassuring.

5) Given the heritage, there is not such thing as a "Lisp community" and the
lack of governance is quite evident in the sense of lack of direction and lack
of uniformity in pretty much everything.

6) Emacs. "It's lisp!". Well actually emacs lisp and common lisp are different
languages, and differences will come up.

Emacs is my editor of choice, but I' starting to grow worried about it.

These are some of the reasons why I decided not to "invest" in Common Lisp.

~~~
hga
_Consider this: it is a fact that MIT introductory programming class switched
from Scheme to Python because among other things, students were spending too
much time reading libraries manuals and implementation references instead of
writing code._

Nope, the decision was entirely political, driven by panic when post-dot.com
crash enrollment dropped by more than half after being a steady 40% of the
undergraduates for decades.

And I believe your specifics are entirely wrong, but I don't know exactly how
the course evolved, e.g. they threw in a couple of weeks of OO that isn't in
SICP as that became popular. But at least in the beginning of the course, it's
all self-contained in the book.

Much of the rest of what you say is spot on, and are some of the reasons I
gave up on mainline/Common Lisp 30+ years ago.

------
sklogic
Norvig nailed it - instead of being sissy about macros altogether the
mainstream languages must rather enforce a certain discipline. And the rules
for the macros done right are very simple and well known.

~~~
jeffreyrogers
Honestly, I don't get the fuss about macros. I haven't seen many (any?) use
cases for them, where they don't make the code harder to understand while
doing something that isn't already straightforward in the base language.

~~~
sklogic
> Honestly, I don't get the fuss about macros.

DSLs are an ultimate solution. And DSLs are best implemented with macros.

> where they don't make the code harder to understand

Macros are there to make code _easier_ to understand.

I just explained it in detail elsewhere:
[https://news.ycombinator.com/item?id=11705170](https://news.ycombinator.com/item?id=11705170)

~~~
jeffreyrogers
Yes, I get theory, but I haven't seen much use for them in practice.

~~~
sklogic
It puzzles me too, that people are not using the most powerful development
technique.

I cannot imagine _not_ using macros for pretty much everything I do.

~~~
wry_discontent
I've written a handful of Clojure and Emacs Lisp, but I don't get macros. How
is a macro different than passing a quoted list to a function?

Maybe I just need to start slinging more lisp, but I don't see how they're
particularly different from functions.

~~~
sklogic
> How is a macro different than passing a quoted list to a function?

Macro is a function that is executed in compile time. Think of it as a way of
extending your compiler with new functionality. For example, your language
does not have support for pattern matching originally. It's not a problem -
you can define a macro that adds such a functionality to a language. You
cannot do it with functions - it must be compiled and optimised before
execution, and functions cannot introduce new identifiers into a scope.

Another simple example would be something like list comprehensions - also
introducing variables and also requiring optimisations in compile time.

And at extreme level, macros can be used to turn your host language into
something totally different. Not just add few new features, but turn it into
another language. Lisp can become an ML or Haskell, or Prolog, or Java, or
whatever else you can imagine. Macros can change syntax, can implement new
semantics. None of it can be done with just functions.

------
chvid
Yes. I have. People with gray beard, strong views on programming languages,
politics and UFOs.

I always assumed that were dressed up for the occasion and not really real;
like someone doing a role playing game or maybe being Santa for the kids
during Christmas.

~~~
weavie
Hmm.. my beard isn't fully grey yet.

~~~
chvid
(Don't worry - it will be). Just making on joke what a "Lisp advocate" is.

But seriously; if you meet people who really understand programming language
design they will have full understanding for other ways of designing a
language than whatever is their specialty. After all there is a reason why PL
is still a developing field.

~~~
wolfgke
> (Don't worry - it will be).

This assumes that weavie actually has a beard.

------
euske
Common Lisp doesn't have type checking and well defined namespace. And it has
eval. That's certainly a no go for people like me.

Most programmers in the world don't have to invent/implement a radical new
idea in five minutes.

~~~
adwf
Eval? The entire point of Lisp macros is toying around with evalulation in a
safe fashion. It's other languages that do it so dangerously that gives eval a
bad name. Lisp is the shining example of how to do it right.

~~~
chvid
AFAIK macros in Lisp are turing complete and executed at compile time.

This means (in principle) that there is no guarantee that a Lisp compile will
ever terminate.

I don't know why the OP is been down voted. Lisp is not for everyone and every
application; I think that is a perfectly reasonable point of view.

~~~
klibertp
The OP is being downvoted because he lies.

Common Lisp does have strong and optional static typing. It does have
namespaces.

As for CL having `eval` - well, this is true at least. But I fail to see how
in the world could that be a bad thing...

~~~
chvid
If a language has an eval construct it is hard/impossible to reason about
types, security and correctness. It also makes it hard to compile it to
machine code.

~~~
adwf
That would be true if we were talking about normal languages eval'ing strings.
Lisp on the other hand treats the code as data and has the full compiler
available at runtime. It can check types at both runtime and compile time, and
it will still compile it down to nice machine code on the fly.

Lisp eval is not the same as other languages, you use it implicitly all the
time. Any occurence of macros or something like `(1 ,(+ 2 3) 4) is playing
around with evaluation behind the scenes.

~~~
sklogic
Macros do not need to be implemented with eval, unless they're _lexically
scoped_ macros. They're just normal function, normally complied just like
anything else.

What is important is an incremental compilation, one top level statement at a
time.

~~~
adwf
Yes, I didn't mean to imply that you needed to explicitly eval with macros.
Rather that the nature of macros themselves is saying, eval this bit at
compile time and that bit at run time. You are implicitly and safely doing
what most languages would need an explicit eval call to do.

