

Why Lisp Did Not and Never Will Gain Enough Traction - drmrkela
http://kresimirbojcic.com/2012/08/14/why-lisp-did-not-and-never-will-gain-enough-traction.html

======
KirinDave
None of these applies to Clojure, and by and large Clojure basically obsoletes
Ruby and Python unless you have concerns about the jvm startup time (which you
can work around with Nailgun, but many people don't). No, seriously, Clojure
is a uniform attack on everything of value in the Ruby, Python and Node.js
world, only with fantastic performance and more flexible syntax.

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.

~~~
dhkl
> by and large Clojure basically obsoletes Ruby and Python

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.

~~~
KirinDave
> Both of those languages have great tools (rails, for example)

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

~~~
krickle
You have successfully gotten me to commit myself to looking into Clojure. Any
good resources on learning/setting up, or should I go by the seat of my pants?

~~~
dhkl
I find _Clojure Programming_ (<http://www.clojurebook.com/>) to be an easy and
practical introduction of the language. It often compare and contrast the
Clojure way of doing things vs scripting languages like Ruby. After that, _Joy
of Clojure_ (<http://joyofclojure.com/>) dives deep into the whys of the
language. Even though it was written against Clojure 1.2, it covers advanced
topics like continuation passing style that were left out of _Clojure
Programming_.

~~~
krickle
Cheers; this is going to be fun weekend :)

------
donall
I don't mean to nit-pick, but although I found the content to be very
interesting, I also found it difficult to follow because it feels like the
author's grasp of English isn't quite where it needs to be (although it's very
close).

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.

~~~
drmrkela
Hey, thanks for the feedback. I was supposed to be "back in the day". But I
feel it is best to just throw it out since it sounds kind of fake.

------
outworlder
The 'ball of mud' analogy is spot-on. An artist can create wonderful
sculptures with it, but a beginner won't be able to do much, besides flinging
it around and making a mess.

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

------
jonathanyc
I think that this article was posted a while back. I agree with most points,
except for the one about lack of "pre choice" - I've been playing around with
Racket (formerly PLT Scheme) for a while, and the one thing I've been amazed
at is the amount of choice. There are a ridiculous number of built-ins.

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.

~~~
dsrguru
The failure of Lisp to gain traction historically might also be a result of
marketing. Now that people are associating Clojure with things like startups,
Heroku, concurrency, and the JVM, it seems to be catching on outside of the
Lisp community.

~~~
dsrguru
I just found this chart (<http://tinyurl.com/9f7pxnq>) of languages Clojure
users came from [or are still using] from cemerick's 2012 State of Clojure
survey, which suggests that Clojure is not only catching on outside of the
LISP community, but almost exclusively so.

------
pnathan
Lisp being too minimalistic or offering too many choices is an interesting
argument. It's not wholly untrue. Lisps culturally offer power and
flexibility.

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.

~~~
bokchoi
It's not that developers don't want flexibility or power. It's that it comes
at a cost of collaboration with other developers and tools.

------
agumonkey
Dick Gabriel, IIRC, mentioned that many PL research was done in lisp, but your
PhD would look dull if it was just a set of lisp macros, so students devised a
concrete syntax and built a separate native compiler. I believe lisp as an
atom will never be more popular than in the Symbolics era (lisp from top to
metal, hard to beat), lisp genes,though, are all over the place recently.

------
rbanffy
One other thing to consider is when it's so easy to roll out your own
[server|language|framework] no single implementation gains critical mass and
fragmentation prevents newcomers from joining in.

------
MaysonL
And Beethoven will never beat out the Beatles. It's a pop culture, baby! Live
with it.

------
rbanffy
How much is "enough"?

~~~
drmrkela
I don't know. Maybe to be in the top 10 on TIOBE index? It's paradoxal that
you have this superior paradigm that not only is not dominating but it's not
even in top 5 languages that are used. (Not to mention that all dialects
account for that 13-th place, so if you disperse percentage on all of them -
they are of the chart)

------
scoith
Tbe reason that functional programming languages, including LISP, will never
dominate the world is because most people are doing engineering, not maths or
getting out CS papers.

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.

~~~
dbecker
I don't think the relationship between a language's model of computation and
the physical computing mechanism is particularly important. It's more
important for a language to follow our MENTAL model of computing. Fortunately,
the mental model of computing can change over time as you become familiar with
new paradigms.

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.

~~~
scoith
I think there is a confusion here: our "mental" grasp of a physical process
and intuition is tightly related to how the world works. We develop our
intuition from real-world experience. They're not two separate things. This's
also why quantum physics is so non-intuitive for us, and why we struggle
dealing with it (counter-intuitive it is, we do it anyways, because that's
just the way the Nature works --it's not something man-made like Lisp). That
being said, the physical processes don't depend on people's understanding.
Physics doesn't depend on how you think about the world. The quantum state (or
a classical state) is there, and it won't go away just because you want
mathematical elegance or try to see things in a different way in your inner
world as hard as you can.

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.

~~~
dbecker
There are plenty of ways of accurately representing reality that don't rely on
mutable state.

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.

~~~
scoith
Please tell me you were trolling. Or that you're 10. Otherwise go read some
basic mechanics from Goldstein's Classical Mechanics. And learn some basic
mathematics.

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.

------
mbleigh
Parentheses.

~~~
KirinDave
If this _really_ is what turns you off to Lisps, then probably programming is
only going to get harder and harder for you.

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.

~~~
e40
In fact, the syntax of s-expressions is the key to Lisp's power. The form of
program and data are the same, which allows the powerful macro facility and
the functions read and eval.

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.

~~~
colomon
When people say they hate "parentheses" in Lisp, I'm pretty sure what they
really mean is "I hate s-expressions." You may find them natural to work with,
but it's pretty clear most programmers do not. Witness the crazy amount of
work compiler writers put into writing parsers that could be trivially done
away with if they just switched to using s-expressions.

Personally I prefer both Forth's RPN and C/C++ (Algol?) style notation to
Lisp's s-expressions.

~~~
KirinDave
S-expressions are neither wonderful nor terrible. They are just A Decision.
Certainly you can have bad syntaxes and good syntaxes, as well.

