
Why Lisp Is Unpopular - mnemonicsloth
A picture is worth 1K - 3 * 2^3 words:<p>http://www.hq.usace.army.mil/cepa/pubs/jul00/radar.jpg<p>That's a phased-array radar installation that (I understand) was built to detect Soviet ballistic missiles inbound over the North Pole.  Google has more images.<p>The term "Phased Array" has interesting implications here.  It means that received phase information is preserved among the many small antenna elements on each face of the structure.  That only works if the paths traversed by the antenna outputs are all the same length (modulo lambda), with a margin of error around .1 * lambda, where lambda is a representative wavelength of the received signal.<p>This thing uses microwave signals [1], which means we can reformulate the preceding paragraph as follows: You're looking at a picture of a single circuit the size of a large office building, built to a precision of 100 microns.  Now's a good time to point out that little yellow thing in the lower left corner of the image is probably some kind of earth-moving machine.<p>The US military built a number of these installations in Alaska and Canada during the Cold War.  Let's pause here to think about all the structure-hardening and weatherproofing that must have been involved.<p>What does this have to do with Lisp?  It's not an exaggeration to say that building and maintaining these early warning systems required the attention of at least a third of all American microwave engineers [2].  When the Cold War ended, most of them left the big contractors the DoD hired to build the radar and started doing basically the same work for cellular companies [3].  Ten or fifteen years later, mobile phones became ubiquitous.<p>In the case of Lisp, there was no continuity in the transition.  Common Lisp, in particular, was primarily in use by a rarefied group of specialists working on room-sized computers at places like DARPA, thinking about things like AI for driving tanks across central Germany.  When the funding dried up and the specialists had to move on [4], they found work writing C, Perl, or Java on microcomputers.  So Lisp lost its user base and the last of its major hardware platforms (now that you couldn't buy a Lisp Machine any more) all at once.<p>Of course, when programmers discuss Lisp's continuing lack of popularity, <i>regardless of their opinion of the language itself</i>, they seem a lot more willing to blame things programmers ultimately control, like the social habits of Lisp users or the damn parentheses.<p>[1]  I'm not a microwave guy, so some of this explanation is simplistic almost to the point of inaccuracy.  In particular, I don't know what frequency bands these installations use.<p>This is as good a place as any to point out that I also have no special knowledge about Lisp at big organizations after the end of the Cold War.  People who do are strongly encouraged to email me if I've gotten anything wrong.<p>[2]  I don't have a citation for this number, but one of my old professors does.  I'll see if I can get him to email it to me.<p>[3] "3G" cellular technology would be unworkable without big antenna arrays<p>[4] A lot of the "classic" books on Lisp and related topics were written during this period.  SICP, PAIP, and On Lisp, and The Seasoned Schemer come to mind.
======
pTymN
How to make Lisp popular (or as popular as Lisp will ever get):

1) SBCL working very well on the big three PC platforms. 2) Bindings + easy
installation for popular libraries. 3) Education (pg's articles, everything on
planet.lisp.org) 4) Solid debugging, perhaps with things like breakpoints.

There is much activity on all 4 problem items that I identified above, so Lisp
IS getting more popular. I don't know if programming.reddit.com can be a
scientific gauge of how popular Lisp is, but it seems to be mentioned
increasingly often.

Of all the problems Lisp has, parens are much less than the problem that it
takes a gigantic effort to use Lisp with any popular libraries, once you step
outside of the way that the larger community is using it.

~~~
jrockway
I think the problem Lisp has is that very few people are forced to use it. If
you look at the average programmer, he doesn't want to think about
programming, he just wants to press keys an go home. So a language that
requires you to think instead of type is not something that he is going to
flock to.

I think the sad reality is that most programmers aren't very smart, so smart
languages will never become popular.

I'm not sure why it matters though, there are plenty of CL libraries (and
jobs), so if you like lisp you can get by just fine.

~~~
emfle
I think most people prefer languages that let them think about the problem
they are trying to solve, rather than think about what the macros expand to,
or what happens when they call that continuation.

~~~
gruseom
Sure. Nobody would ever write a macro to solve a _problem_.

No wait: on second thought, I surrender to how completely dumbfounded I am by
this comment.

I'm calling Kenny...

~~~
emfle
The point is that "requires you to _think_ " is not a feature, it is a bug,
because that thinking could be put to better use on whatever it is the program
is trying to solve. Everything else being equal, this means that language
features that can be used without much thinking will do better than language
features that can't.

~~~
gruseom
So programmers who work with objects and methods don't have to think about
them, while programmers who work with macros do? Sorry, but this just seems
ludicrous to me.

Perhaps what you mean is that when a construct is _unfamiliar_ to a programmer
then they have to think harder about how to use it?

<http://www.google.com/search?q=blub>

~~~
emfle
I am saying that working with objects and methods requires less high-level
cognitive processing than macros and continuations, not that you don't have to
think about them. This is because the brain can treat the objects largely as
if they were physical objects. With macros that is much harder.

No, I don't mean unfamiliar. Things like parentheses and prefix notation are
unfamiliar to many people, but once learned, they don't require much more
cognitive processing than other notation. There are several things in Java
that are similarly weird until you learn them.

~~~
KirinDave
"I am saying that working with objects and methods requires less high-level
cognitive processing than macros and continuations, not that you don't have to
think about them. This is because the brain can treat the objects largely as
if they were physical objects. With macros that is much harder."

It's not. It's just a matter of practice. Most people find OO modeling natural
(even when it is extremely tortured and difficult) because they've acquired a
comfort with it born of many hours of practice. You might argue that you're
not referring to familiarity with the paradigm, but I think you are, and don't
realize it.

I assure you that a functional style has equal power to abstract as a OO
style. You're right, our brains have a good ability to think of things as sets
of objects. But the lisp style leverages the linguistic propensity to give
words special significance. We're also very good at learning languages and
parsing sentences in context, so the lisp linguistic style leverages similar
natural cognitive abilities.

~~~
emfle
I am familiar with functional programming. In fact, for some reason recursion
and higher-order functions always seemed easy to me (unlike pointers and
virtual methods), but I think that's a quirk of my brain. Many other people
seem to have a lot of trouble with the idea that you can just make a recursive
call and trust that it's going to do what it is supposed to.

Not me personally, though.

 _But the lisp style leverages the linguistic propensity to give words special
significance. We're also very good at learning languages and parsing sentences
in context, so the lisp linguistic style leverages similar natural cognitive
abilities._

Linguistic processing does require more cognitive effort, especially when it
involves something like a macro that can change the context in which it is
invoked. For exactly the same reason, most people are more productive with a
graphical user interface than with a command-line one. This is directly
related to the fact that abstract linguistic processing is more difficult than
manipulation of the tangible, physical objects you find in a GUI.

------
mechanical_fish
_You're looking at a picture of a single circuit the size of a large office
building, built to a precision of 100 microns._

I agree that this is impressive, but remember that you get to cheat: You build
the thing, measure how far off you are, and stick delay lines in the short
branches until everything lines up. Admittedly, if you're off by a hundred
meters the required delays would be embarrassingly large, and the architect
would get teased a lot, but even then I don't think it would pose an
insurmountable problem.

Meanwhile, if the essence of your argument is that Lisp was used by mainframe
guys and wasn't pushed hard enough in the microcomputer world, I can't help
but agree. God, if only I could travel back in time and replace all those
useless Pascal books I read as a teenager with Lisp books...

~~~
dmh2000
>You're looking at a picture of a single circuit the size of a large office
building, built to a precision of 100 microns. I agree that this is
impressive, but remember that you get to cheat: You build the thing, measure
how far off you are, and stick delay lines in the short branches until
everything lines up.

they call that Agile Microwave Engineering

oh, and you must have two microwave engineers working on each delay line.

------
brlewis
There are many hypotheses out there that Lisp lacks popularity for this or
that flaw in the language or in the community. The problem with these
hypotheses is that you can point to similar or bigger flaws in languages that
have grown popular. If a language has good qualities, people will figure out
ways around the problems.

My hypothesis is that Lisp is unpopular for the exact same reason some of us
love it: concise code. Everybody praises concise code, but humans love looking
at things that have repeated patterns. The more you compress information, the
fewer repeated patterns there are to look at.

I wish PG well with Arc, but I don't think popularity will come from fixing
anything that's wrong with Lisp. By my hypothesis, Lisp only becomes popular
by fixing what's right with it.

~~~
stevecooperorg
I really don't find that lisp, at least common lisp, is particularly concise.
Consider lambda functions, one of those things that lisp is particularly
praised for;

    
    
       common lisp: (lambda (x) (+ x 1))
       C#3        : x=> x + 1
       ruby       : { |x| x + 1 }
       python     : lambda x: x + 1
       Haskell    : \x -> x + 1
       

Just in terms of character count, CL is the longest of the lot.

No, the problem with trying to get a lisp under your belt has alredy been
mentioned. Compared to the alternatives;

\- choosing an implementation is a research project (clisp? sbcl? allegro?) \-
documentation is weaker \- libraries are harder to find and install (ASDF vs
Rubygems, Python eggs, etc.) \- emacs/slime is an investment to learn \-
examples are few and far between \- the language itself (the words, not the
punctuation) is inelegant (mapcar, setq, cdadr)

I've tried really hard to learn lisp, and it turns out that actually, while
there may be some platonic lisp that IS great, _actually programming common
lisp_ , now, is a massive effort in struggling in the dark.

~~~
shiranaihito
> \- choosing an implementation is a research project (clisp? sbcl? allegro?)
> - documentation is weaker - libraries are harder to find and install (ASDF
> vs Rubygems, Python eggs, etc.) - emacs/slime is an investment to learn -
> examples are few and far between - the language itself (the words, not the
> punctuation) is inelegant (mapcar, setq, cdadr)

\- Exactly.

Last year I started reading about Lisp etc, and wanted to play with it a
little bit.

These are the exact same obstacles I faced.

If you ask about "IDEs" for Lisp, you're met with downright hostility for not
embracing the glory of emacs with open arms - anything else is just
unfathomable.

Well, what if I'd like to just, you know, start using the language, and not
learn a whole new world of an editor first?

"Why does emacs + SLIME have to be the only viable option?"

That's not a question you can ask, of course, but the answer would be
something like "roll your own" anytime you need anything.

(Oh, and Xach is a prick. He and Krysztov(or whatever) are practically high-
fiving each other on IRC every time they alienate another new would-be Lisper)

As for the implementation research, I sort of came to the conclusion that SBCL
was the way to go, but documentation (for anything?) was pretty scarce, and
ASDF feels like an obstacle too.

Later on, I realized that Scheme is more elegant as a language, but it's more
or less in the same situation as CL.

Compared to these two, something like Python feels much more accessible to me
(being a novice at all), because I get the feeling that I can just start using
things whenever I want to make that effort.

But that's just it - with Python, there's only the effort of learning the
language as you use it.

You learn the standard library as you go, and suddenly you notice you've
accomplished a lot of things and had fun while at it.

\- At least that's how I imagine it will be when I get around to working on my
own super-secret web-startupy project.

With Lisps, you need to make a lot of effort just to get to the beginning, and
that's a big problem.

~~~
rsynnott
You can use CUSP (an Eclipse plugin which provides similar functionality to
SLIME for EMACS), and the commercial impls have their own (admittedly EMACS-
esque) IDEs. There's even a SLIME-derived plugin for vi! It really is worth
the effort to learn EMACS, though.

I'm unconvinced that installing lisp libraries is so very horrible; I've had
far more trouble with python ones, myself.

~~~
shiranaihito
I even tried CUSP back then, but it was somehow confusing (or refused to
work), I don't remember.

Maybe it's because I don't normally use Eclipse.

If someone is interested in other alternatives, here's one:
<http://phil.nullable.eu/>

\- Phil's "ABLE" editor. I tried it too, but it didn't work too well on
Windows (something about CLISP, iirc).

------
gordianknot
The power of a programming language is proportional to its capability for
innate abstraction. If that's true, it follows list-oriented languages are
inherently inferior to their hashtable-oriented brethren. (These orientations
are often misguidedly referred to as "functional" and "object-oriented"
paradigms, which I find to be useless, over-overloaded terms.) Basically, with
list-oriented langs the primary abstraction is a tree, whereas with hashtable-
orientation, it's a graph. I'm talking about the -primary abstraction- (i.e.
what you "think in" when hacking); obviously you can implement any structure
in any powerful enough language. If others don't see it this way please,
illuminate me.

Lists confine one to rigid hierarchies, which have to be compensated for with
dirty (but sexy) hacks like in-language macros. Meanwhile the index of
hashtables is arbitrary, which allows you to do naturally the things you have
to patch in Lisp.

Though hashtables are more powerful and easier to grok, for one reason or
another nearly all (popular) hashtable-oriented languages are total crap (C++,
Java, C#), but in some regard a step up from deformed languages like C (in all
seriousness, how does anybody get by without first-class functions and
hashtables?). My tentacles have only found two decent hashtable-oriented
languages: JavaScript >~1.5 and Io.

Anyway, why is Lisp unpopular? Because it's harder for most programmers to
think in lists than hashtables. Then, why does the lang have a cult following?
Because it's well crafted and consistent, which seems to cause some people to
overlook its shortcomings, even to the extent of seeing design flaws as
features.

But as far as I'm concerned the Language War is over anyway. JavaScript won.

~~~
edu
And what about CLOS? Does not make Lisp, in your words, a "hash programming
language"?

Really I don't get the difference you state between list/hash programming
languages, I've work a little with EcmaScript and I don't know anything about
Io, but I'll put it in my to-do list. Can you, please, extend it? What's the
main difference between them?

Because you say that the primary abstraction of a "list" programming language
is a tree, which I think not. Since a tree is a directed graph without cycles,
you wouldn't have loops. So, at least is a directed graph. But then, which
property has the "hash" language graph that the "list" language graph has not?
It's an undirected graph? It think it is not possible, because if it's
undirected how do make your program to go "forward" and not "backward"?

I hope I'm not too obfuscated and my questions make some sense.

~~~
gordianknot
I've never looked at CLOS. But, what I mean is the "dominant metaphor," which
I suspect is still lists.

I'll just go through my probably plebeian understanding. Arrays are to lists
as hashtables are to objects. An array, in my mind, is a list that only
contains one type and is indexed with enumerated integers. On the other hand a
list can contain any type, but is also indexed with enumerated integers.

In JavaScript:

    
    
      array = [1, 2, 3]
      list = ["one", [[array], 3]]
      array[0] == 1
      list[20] = 23 // list indices aren't necessarily a linear enumeration
    

Of course, arrays and lists are both technically Arrays in JavaScript (a bad
naming choice; I'd have called them Lists). Now a hashtable is typically just
a list that uses strings for indices instead of integers.

    
    
      hashtable = {
        "today":20080403,
        future:function(x) { return this.today + x }
      }
    

A "method" is just a value that happens to be a function. Usually hashtable-
oriented languages choose to abstract away the string, and treat it as a
variable.

    
    
      hashtable["today"] == hashtable.today
      hashtable.method(23)
    

Like with lists/arrays, JavaScript gets hashtables/objects almost exactly
right, but again is subject to some questionable naming choices.

RE: trees and graphs -- I was getting at the relationships between nodes, not
the actual computations, but I'm not comfortable enough with the terminology
to explain exactly what I meant.

~~~
edu
Ok, I think I get you. But then I think you can't categorize programming
languages this way, the default data-structures provided by the language don't
characterize it. In fact, it seems to me that you like most JavaScript because
it's object oriented, it's dynamic typing and functions are first-class.
Features that others languages lack, and not because the "dominant metaphor"
is the hash. Casually in JavaScript the objects are built with hashes (at
least apparently), and can be easily extended.

It's a fun thread :D

~~~
gordianknot
Built-in data structures are a big point of categorization of langs on my end.
To me, the defining feature of Java is its classical structure. If you got rid
of classes, you'd have a different language (in the interface sense). And
interface is really all I'm talking about.

I'm basically just asserting that objects (should) == hashtables. This is
quite literal in JavaScript. Other languages bend the metaphor in different
directions, and obscure it to that no one even knows what "object-oriented"
really means beyond particular idiosyncratic syntax in this language or that.

PG of course talked about this before, in Why Arc Isn't Especially Object-
Oriented:

> I've done a lot of things (e.g. making hash tables full of closures) that
> would have required object-oriented techniques to do in wimpier languages
> ...

I'd argue that he was employing genuine object-oriented techniques, but just
didn't have classical syntax and didn't consider what he had an "object."
Other languages make a point about it, and use special syntax, which fogs the
whole thing. Perhaps some people in "OO" mindsets have the kind of naivete
that C-only hackers I've met have about first-class functions.

Actually, I just realized the whole reason C++, Java, C#, and co. have
"methods" in the first place is just compensation for not having first-class
functions you can stick in a hashtable.

~~~
anamax
If objects == hash tables, any language with decent hash tables, including
lisp, has objects that you're perfectly happy with. Lisp also has other data
types, but their existence means that lisp has more power, not less.

------
edu
I like Lisp a lot, and from my own experience I think that the main reasons
why people dislike Lisp are _prefix notation and parentheses_.

Sure, my experience is only anecdotal and not at all large. But always I've
tried to introduce someone to Lisp (I'm talking of about 5 people, none of
them have converted...) they seem incapable to see further than the
parenthesis and the prefix notation, but specially the parentheses.

I tried to explain them the benefits of being such a regular language, how the
source code is a list which makes it really easy to do meta-programming, the
power of macros, the fact that using a good text editor (Emacs + SLIME) with
an excellent indentation you really don't have to care about parentheses: you
follow the indentation not count parentheses!. Not to speak about the prefix
notation, which they seem allergic to. But all have been in vain.

Lisp is so esthetically different from the other Algol-derived languages that
it, simply, does not fit their brains, which I think is really a pity. Four of
them are Perl programmers, being Perl their blub. They belive and act like
there is no language better than Perl, they can do everything with perl. Whey
I explain macros and metaprogramming they reply that Perl can do that with
_eval_ and _strings_. I've tried that and is, at least, sadomasochistic!

So, after this rant (sorry), I've to restate: the main problem people have
with Lisp are _parenthesis_ and _prefix notation_.

PS: Some of them also worship Microsoft and argue that Windows XP is the best
operating system out there far better than Mac OS X (which none of them have
tried for more than 5 minutes in a row), and that Linux is only good for
severs. Some times I think that they suffer from severe brain damage, but
apart from that they're pretty clever. So... it's an enigma.

~~~
tfinniga
I think lisp's problems started when it wasn't designed for actual use. It is
elegant, functional, and amazingly regular. Usability wasn't a design goal.

If you look at languages in wide use, they're all procedural - everything from
ASM and basic to ruby and python. Similarly, all the pseudocode I've seen has
been procedural. If you ask a lay person to come up with a way of making 20
pb&j sandwiches, you're going to get a list of steps for each sandwich.

I'd argue that functional thinking is not natural, it's learned. Prefix
notation is not as natural as infix notation. It's not just Algol, it's likely
a reflection of natural language, and the forces that shaped natural language.

My prediction is that lisp is going to become more popular in one of two
scenarios. The first is that parallel processing becomes more necessary, and
because functional programming is easier to parallelize, people will learn it.

The second is that lisp is redesigned with usability in mind. The fact that
it's not bad as long as you use emacs+SLIME is not a ringing endorsement. One
of the advantages of, say, ruby is that you don't need an advanced editor to
be productive. The design goal was to make a language that's nice to use, so
it is nice to use.

If lisp were redesigned with usability in mind, I could see it being more
popular. However, the people who like and use lisp enough to try to redesign
it likely aren't bothered too much by the syntax, so it's not something they
try to fix.

~~~
edu
But Lisp is not a functional language. You can do procedural programming with
it, moreover I think that nowadays the usual Lisp program is either
procedural, OOP or a mix.

You really don't need to rely on Emacs+Slime, an editor with a good support
for indentation will suffice. IIRC, pg codes in Vi (or Vim). The idea is that,
like in C/C++, good indentation is enough to determine the nesting so you
don't need to count parentheses or curly brackets.

The last difference, infix vs prefix, I can see that we are more used to infix
notation. But we can't forget that the Algol derived languages use a mix of
them (operators and functions are different!) while Lisp always use prefix
notation, and incidentally put the parentheses surrounding all the expression
(and being the first element the function name).

~~~
tfinniga
Good points. Perhaps the problem is also how lisp is taught? When I learned
lisp, the procedural aspects of lisp were shown, but with the understanding
that they were bad, and not to be used. Probably because it was shown as a
functional language, and was meant to be used as such. Similar to how, say,
c++'s functional programming capabilities aren't really taught.

If the indentation is sufficient, why not just remove the parens completely
and rely on indentation?

Lisp does have an advantage in being regular, which might not be worth giving
up, and Algol descendants are kind of a mishmash, to be fair. To be honest,
I'm not enough of a lisp user to be able to know what a good solution is for
this one. Maybe changing some function names would be useful.. for example
'add' is better than '+', which I read as 'plus'. Repurposing infix symbols as
prefix symbols seems problematic.

If I were redesigning the language, one of the more important things I'd
change is the keywords and builtins. For example, head and tail seem a lot
better to me than car and cdr. A lot of lisp's keywords and functions come
from math, and I'd probably change them to reflect mainstream algorithm design
instead.

~~~
edu
Well, to some extent there exists a unparenthesized version of Lisp: Logo :)

<http://en.wikipedia.org/wiki/Logo_%28programming_language%29>

And for the names used for the keywords and builtins, I agree with you.

About the +/add, I really don't see too much problem.

------
docmach
One problem I have with Lisp is that there are a lot more fanatics than in
other languages' communities. They are easily upset by even the mention of
other languages and seem to see Lisp as the ultimate language with no room for
any others. This produces blog and newsgroup posts extolling the virtues of
Lisp and telling everyone who doesn't love Lisp that there is something wrong
with them. People who say they know Lisp and still choose to use other
languages are looked at as particularly defective. It's not just that they
don't want to use other languages, it's more like they don't want other
languages to exist. They spend at least as much time trying to make other
languages look bad as they do trying to make Lisp look good.

I know this doesn't describe everyone who uses Lisp, but these fanatics are
very vocal and the reason I stopped reading comp.lang.lisp and decided to try
other languages. I am not against being excited about a language and trying to
convince other people to use it. I love Haskell and tell people about how
wonderful it is all the time, but I understand that they have reasons for
using the tools they do. I am more interested in the theory of a language than
in how good it is at solving some practical problem, but some people don't
care at all about theory and just want to get things done. I don't understand
why, but I accept it. I think that the most important thing the Lisp community
can do to be more popular is to be friendly to newcomers and those who
disagree about Lisp's superiority. There are some very helpful and friendly
people, they just need to be more vocal and drown out those who are not.

------
aggieben
My hypothesis has nothing to do with Lisp itself, per-se:

People simply stopped paying attention because of the failed promises of AI -
and in a nod to the parent, some of the talent base probably shifted to other
technologies, and Lisp was left without an ecosystem. It's starting to build
up again.

Beautiful case-in-point: I went to a developer's conference yesterday put on
by one of the big software vendors that my company buys from. I was carrying a
copy of PG's excellent _On Lisp_ to read during dead times. Having that book
out in the open started several conversations with people I wouldn't have met,
incidentally. Each of those conversations went something like this:

 _He: Lisp! Who uses that anymore? Didn't that die out a long time ago?_

Me: Well, it was big during the 80's because of AI, but it's in the middle of
a comeback that started sometime around 2000.

 _He: really!? I thought it was a dead language. Who uses it?_

Me: There are a few companies out there that use it. There are even commercial
offerings of Lisp tools. There's Franz, Inc. which sells AllegroCL, for
example. There are two or three others I can think of off the top of my head.
There are some open source projects that are very active, too.

 _He: but it's just a scripting language, right?_

Me: No, it's really a general-purpose programming language that can be used
for any number of things. It's currently being used for writing web
applications, among other things, but it could be used to write any kind of
software, really. Whether or not it is interpreted or compiled is dependent on
the implementation and how you want to use it.

------
jsmcgd
I think there are various reasons why Lisp has the level of popularity that it
does (I won't say it is categorically unpopular). Unfamiliar syntax, real or
perceived attitudes of the community, number of primitives, the divergent
nature of the language, industrial history, industrial support, editor
support, academic support, perceived performance, programming trends and other
things have all affected the adoption of Lisp.

I'm confident, given time, that all these concerns will be addressed and the
rate of adoption will continue to increase. That's why I think now is a good
time to get involved if you aren't already: be ahead of the curve.

~~~
boucher
That seems like a good list of reasons. I would add perhaps the sheer volume
of code on the net in other more popular languages, compared to Lisp.

I disagree with your conclusion that Lisp is somehow going to take off though.
After being around for what seems like forever, its still a (and I will say
it) categorically unpopular language. If I were a betting man, I'd bet on
JavaScript.

~~~
jsmcgd
I suppose I wouldn't bet against you.

------
pchristensen
I wrote about this a while back
([http://www.pchristensen.com/blog/articles/lisp-the-golden-
ag...](http://www.pchristensen.com/blog/articles/lisp-the-golden-age-isnt-
coming-back-lets-welcome-a-bright-future/))

Basically, there are two Lisp eras - the big AI era and the new pg/Open Source
era. The recent renewal of interest in programming languages, as well as
publicity by writers like pg, Yegge, Raganwald, etc, have led more people to
become interested in Lisp, but it's on an informal, person-by-person basis.
Some of these people (like me) have chosen to stick with it and new Lisp
communities have formed by gradual accretion. But this process has started
later and been more distributed than other languages (PHP, Python, Ruby,
Perl).

In researching things and trying to figure out Lisp setup problems, I've
noticed that there are fewer technical "How do I ..." questions now than a
couple years ago but more usage questions. The technical problems _are_ being
solved and now more stuff "just works" - not completely but much more than in
the recent past. I've noticed this for CLisp, SBCL, ASDF, and other tools.
There's more documentation, more tutorials, etc. Now there are a couple young
web frameworks (UCW, Weblocks), generally accepted libraries for common tasks,
etc. Lisp is growing in popularity and is maybe 1-2 years away from being
"tasteable" - ie you can try it out without a big hassle and a research
project. I think that will be an inflection point, after which growth will
come much faster.

------
mattjones
"Unpopular" needs to be further qualified. Rather than ask, "Why is Lisp
unpopular?", ask, "Why is Lisp unpopular for X?". Lisp is actually reasonably
popular for some things, and it's those things to which existing dialects are
best adapted. Being well adapted to Y often means not being especially well
adapted to X, even if it's for subtle reasons.

It's like asking, "Why are Arctic foxes ( _Alopex lagopus_ ) not very popular
on the African savanna?" Because they didn't evolve in response to the demands
of that environment. The bat-eared fox, _Otocyon megalotis_ , did.

The differences between _Alopex_ and _Otocyon_ aren't so massive that they
seem like totally different kinds of animals. But it would be tricky to
predict exactly what they should be, and develop the right kind of fox in a
lab. Some adaptations are obvious (thick fur), other less so (specialized
circulatory system). I suspect the same is true for programming languages.
It's tricky to determine exactly what makes Scheme better suited to the
classroom than to developing general applications. Perhaps the best way to
solve the problem is the way PG is doing it with Arc, which is to take a very
young, malleable dialect of Lisp and plunk it down in the environment to which
you want it to become well adapted, and then continue development in response
to the demands you encounter.

~~~
stevecooperorg
OK, I'll bite;

    
    
        (mapcar #'why-is-lisp-unpopular? 
                (list system-administration
                      enterprise-applications
                      web-applications
                      embedded-software
                      mobile-phone-apps
                      blogging-software
                      compiler-writing
                      configuration-files))
    

;)

~~~
mattjones
I don't know the specific reasons why CL and Scheme are not very popular for
those things; my general answer is that they're adapted to other things (like
classrooms and smart students' brains). My point is that it's very hard to
figure out, and so the best bet is probably to let a new dialect evolve in
response to the demands of one or some of those environments.

------
hernan7
In my opinion, if you don't learn Lisp at school, picking it up later in your
spare time is going to be quite a task.

After reading and doing the exercises from the Touretzky book and The Little
Schemer, plus some articles here and there on the 'Net my experience was:

1) Lisps have their annoyances like all languages. Lots of little non-
intuitive keywords to memorize, the dotted pairs, quite the baroque
computation model (variables having sub-variables, etc.), the FOR syntax, DO,
etc. Not a deal breaker, but annoying. (Touretzky seems to fixate excessively
on some of these weird traits of Lisp.)

2) If your Math chops are rusty, you are going to have to work twice as hard.
Mine are, and I had to. If you are fresh from taking your Computability Theory
course, then recursion and infix are going to be second nature. If you haven't
been doing Math for a while, it's going to be hard. Another reason to learn
Lisp while in college.

3) You can learn the syntax in 2 hours, yes, but to really know Lisp you need
to really understand recursion, continuations, thunks, macros, multiple
dispatch, all the fine points of object orientation (to understand the CLOS)
and who knows what else. Basically, you need to have a deep understanding of,
well, all of CS? This is not something that can be learned on your spare time
unless you have lots of it.

In my case, I am starting The Seasoned Schemer now, and taking it slowly,
under no illusion that I am going to learn Lisp any time soon. I may well be
that I am one of those "stupid programmers" that are unsuited for Lisp. Oh
well...

------
mfp
OT: According to wikipedia, the PAVE PAWS phased array operates in the 420-450
MHz UHF range, with a corresponding wavelength of 66cm; if the error margin is
really 0.1*lambda, the system is built to a precision of 6cm, significantly
easier to meet than 0.1mm.

Also, it would be easy to compensate any error by controlling the phase of the
fed signals.

See
[http://en.wikipedia.org/wiki/Ballistic_Missile_Early_Warning...](http://en.wikipedia.org/wiki/Ballistic_Missile_Early_Warning_System)

~~~
mnemonicsloth
Thanks!

I was thinking of that very link when I wrote this. Dunno know why I didn't
look more carefully for it.

The number L = lambda/10 is actually part of the standard definition for a
microwave system. Any circuit that has a physical dimension greater than L is
too "big" to use standard circuit analysis, because the voltage and current
values you measure at different points will be different due to propagation
delays, even when those points are connected by a wire with no reactance and
negligible resistance at lower frequencies.

The world's biggest microwave system (biggest machine period, actually) is the
US power grid, even though it oscillates at a measley 60 Hz. Lambda is about
(.6c / 60 Hz) = 1800 miles.

This is proof that, electrically as in so many other things, the Midwest is
180 degrees out of phase with the rest of the country.

------
pg
I don't understand. Is the claim that Lisp is less popular now because years
ago large numbers of programmers working on government-sponsored projects had
to use it, but now proportionately fewer programmers work on government-
sponsored projects?

~~~
wanorris
Yes, I believe the claim is that when huge government projects like this were
completed, all the Lisp programmers left, and had to retrain to find non-Lisp
jobs. This sounds similar to the "AI collapsed and took Lisp with it"
argument.

~~~
pg
There may be something to that argument, but another probably bigger factor is
that there are now other dynamic languages. In 1990 there was no Python or
Ruby. If you wanted to program in that kind of high level style, the only
options were Lisp and Smalltalk.

~~~
mnemonicsloth
The problem with the AI winter argument is that it's half an answer that
satisfies you enough to stop asking questions. If you invoke the collapse of
commercial AI to explain Lisp's current state of disfavor, you then have to
explain why the collapse of the dotcom bubble didn't have a similar effect on
Perl or Java.

Anthropomorphically, you could say that Perl retreated to its base of support
among sysadmins, (Common) Lisp took shelter in big-think research
organizations, and Java reinvented itself as New Cobol.

But that doesn't really satisfy either, because it doesn't tell us why nobody
tried to similarly re-purpose Lisp. That's especially odd, in fact, because
now Everybody Knows that a lisp core is really simple, and Lisp was still on
the radar in academia, where people can be rewarded for re-implementing old
ideas.

The problem with the AI winter argument is that it's half an answer that
satisfies you enough to stop asking questions. If you invoke the collapse of
commercial AI to explain Lisp's current state of disfavor, you then have to
explain why the collapse of the dotcom bubble didn't have a similar effect on
Perl or Java.

Anthropomorphically, you could say that Perl retreated to its base of support
among sysadmins, (Common) Lisp took shelter in big-think research
organizations, and Java reinvented itself as New Cobol.

But that doesn't really satisfy either, because it doesn't tell us why nobody
tried to similarly re-purpose Lisp when DARPA et al lost funding. That's
especially odd since Everybody Knows that a lisp core is really simple, and
Lisp was still on the radar in academia, where people (called grad students)
can be rewarded for re-implementing old ideas.

I think there is a pretty good explanation (with evidence, even!), but it's
not a satisfying one in this community: the end of the Cold War caused a major
reallocation of scarce resources away from expensive one-off projects for the
government, and towards mass-market stuff for consumers and businesses (see
below), and Lisp suffered from some initial disadvantages in the new
environment:

* Limited availability on PC platforms

* Windows Apps were sexier. The internet was sexier.

* Glut of new CS students while the bubble was inflating were mostly taught in Java. (Many of them are sensitive about arguments that lend further support to the idea that their education has turned out to be less valuable than they thought at the time. That may just be my bias showing, though. I think that Math should be relabeled CS, and that "programming" is for autodidacts and trade-schoolers).

* CS is a new field, and industry tends to dumb down research in new fields for a generation or so after disruptive technical innovations. That way, they get enough of the low hanging fruit that it further disruptive innovation is unlikely and their capital is safer. See below, particularly the chapter on the relationship between GE and MIT before WWII.

Social arguments are hard to make here though, because so many people are so
hooked on the "weird and scary and only for elitist pricks" narrative. That's
kind of ironic, because high level corporate executives, if they heard the
current public stand on lisp -- "it may be really productive, but it's too
foreign for most people and I don't feel like learning it" -- could probably
force adoption from above, especially now that cost-cutting is the order of
the day.

[http://www.amazon.com/Leonardo-Internet-Technology-
Culture-R...](http://www.amazon.com/Leonardo-Internet-Technology-Culture-
Renaissance/dp/0801878098)

~~~
wanorris
> If you invoke the collapse of commercial AI to explain Lisp's current state
> of disfavor, you then have to explain why the collapse of the dotcom bubble
> didn't have a similar effect on Perl or Java.

I'm not saying AI Winter is the definitive explanation, but AI collapsed so
thoroughly that there were barely any AI companies still around. Even at the
worst of the dotcom collapse, use of the web was still growing among the
general populace, and the principle leaders like Yahoo, Amazon, and Ebay are
still around.

Your argument about Lisp losing interest because of the PC boom is really
interesting, and I think it has some merit. Still, doesn't it beg the question
of why people didn't just port Lisp to the PC and keep going? That's what
happened with Unix -> Linux.

------
daniel-cussen
One problem I had was getting it installed. If that was easy, I would have
gotten started sooner.

------
meat-eater
The biggest barrier in my opinion is what most people think is "weird" syntax
or the more precisely the absence of it. People are just not used to it. Add
to the that the lack of popular libraries for some modern niceties and it
really adds to it being unpopular.

~~~
dpapathanasiou
I don't understand the syntax complaint: it is simple to learn, and with few
exceptions, applies in all cases.

Other language syntax (C or Erlang, e.g.) is arbitrary and tedious by
comparison.

~~~
gordianknot
It's not "syntax," it's human parseability. Lisp is hard to parse because
humans don't think in lists. Some people are smart enough or naturally able to
overcome that obstacle, but most aren't.

------
ngvrnd
Another problem that LISP had was the era of it's widest use -- an era when
compilers and most programming tools were proprietary, very expensive,
entirely closed and usually dependent on one or another variant hardware
platform. This was also the pre-cambrian era of computer architecture where
the hardware varied so much that porting was a serious issue. Nowadays,
languages which have popped into existance and gained wide acceptance (perl,
ruby, python, for example) were developed in an open-source world. And now,
finally, lisp is catching up in that regard.

------
phr
Actually, that little yellow thing looks to me like a large boom lift. Note
the cage at the front, away from us. For cleaning bird droppings off the array
elements?

~~~
stevecooperorg
yeah. It's the garbage collector.

------
bayareaguy
There are too many disparities between a problem domain (microwave
engineering) and a programming technique (Lisp) to compare the two this way.

I think it more reasonable to compare the popularity of problem domains (e.g
microwave engineering vs robotics) or techniques (e.g. S-Parameter Simulation
and Lisp).

------
adnam
Here's the photo of the radar:

[http://commons.wikimedia.org/wiki/File:PAVE_PAWS_Radar_Clear...](http://commons.wikimedia.org/wiki/File:PAVE_PAWS_Radar_Clear_AFS_Alaska.jpg)

------
lst
Lisp is not unpopular (look at all the programming newbies around!), it's
simply much misunderstood (like many of the high-end solutions, because its
simple looking base is all but trivial...)

~~~
gordianknot
What's the misunderstanding exactly?

~~~
pchristensen
People like stuff that looks familiar but harder. To someone raised on C-style
code, Lisp looks foreign and simpler, two big strikes.

------
sabat
I (((((((have)))))never)been))able))(((to))understand)why((((((it
is)))unpopular))))

