I've heard a lot of people espouse the capabilities of LISP and its omnipotent macros. If LISP is such a great language, why isn't it being adopted more? What problems is LISP facing that is holding it back from (re)emerging as popular language? Is it something about LISP itself ("those brackets!" isn't the answer, is it?!), or its competitors (e.g. the dominance of Java, .NET)?


Most functional programming languages are very hard to learn, which prevents their widespread adoption. It's as simple as that.

if that's your view..i could say the same for OOP ;)
OOP is hard to do correctly. It's not hard to do badly. Functional programming (and I'm referring to true functional programming with no side effects) is hard to do at all.
+5  A: 

When I first saw LINQ I said to myself "this is LISP for C#." So to answer your question, I think that other languages have been incorporating the best parts of LISP into themselves which makes them more competitive against something like LISP and thereby reduces the come back potential of LISP.

Remember that LISP stands for List Processing and LINQ (in C#) gives you amazingly concise power over collections.


There are a few reasons I see:

  • It's difficult to pick up
  • The benefits to most projects are marginal
  • It's drastically different than everything else
  • (Edit) Perhaps most importantly, it's not well used -- it's a chicken-and-egg situation, but companies are usually wary of using a language that isn't well used. Although this may not be the best idea.

That said, a lot of languages are becoming more like Lisp. Python and Ruby have a lot of Lisp's ideals implemented, although the metaprogramming isn't all there yet. And if you look at Nemerle, it's effectively C# + OCaml + Lisp -- wonderous thing.

(To be more clear on Nemerle, it's largely C# syntax with OCaml's variants/matching (also similar to Haskell's matching) and with Lisp's macros -- real macros. In addition, you have real recursion, functions as first-class values, tuples, etc.)

Cody Brocious
I think these reasons are subjective -- they are perhaps manifestations of a common feeling of intimidation about lisp/functional languages, but I don't think there is anything intrinsically difficult about lisp when compared to other languages. (assuming no background in any particular paradigm)
I disagree entirely, even ignoring background. Humans think in a very procedural way. When we want to solve a problem, we make lists of steps. Although thinking in a functional way can make things easier, it's by no means a natural way of thinking. I think that's a fundamental problem here.
Cody Brocious
The Natural Programming Project studied groups of non-programmers to derive syntaxes for new languages, and found that actually, people tended to think in terms of operations on collections of things (eg: map) rather than iteration.
@Cody I strongly disagree with you, I think it's just that most programmers learn nothing but procedural programming for a long time and then fail with lisp. Try picking up Russian after using English for decades.
+44  A: 
Mike Stone
I'm down voting this because you used a webcomic to answer the question.
Jason Dagit
I'm upvoting it for the same reason, and just to be a dork.
I'm upvoting this because Jason is too uptight ;-)
That might be true in Scheme (due to its tail-call optimization requirement), but no other Lisp dialects I know of. I use recursion in Common Lisp no more than in any other language.
Recursion is an elementary building block in computing. I wouldn't call a person who doesn't understand it a programmer at all.
Do you have any idea why people find recursion hard? I, like you, have always found it very simple, but many people I know don't really understand it, and I've never been able to explain it to them. Of course, these types of people are never going to be good programmers anyway, so it doesn't really matter all that much.
Upvoting for the comment about 9-5 programmers - which will be a large set overlap with those who don't get recursion. Likewise I've never found recursion hard, but in practise I find I rarely use it, and where there's a conventional loop of about or even slightly more complexity I go for the loop, principally because recursion always gives me that slight concern over stackoverflows
I'm up-voting this as part of my anger management therapy, my counselor says I should not take time out of my day to chastise people for posting web comics.
Tim Post
+1  A: 

Not the top reason, but I think the lack of 3rd party libraries is also worth a mention.

Ryan Guest
I'm a C# programmer by trade, and I oftentimes wish I could import the ,NET libraries into other, non .NET code I write.
Chris: You might want to look into the Lisp implementations on .NET, e.g. IronLisp and IronScheme.
Cody Brocious
Thanks Cody. I had heard of IronRuby and IronPython, but not IronLisp or IronScheme. Sweet!
+5  A: 

@Guy , @Cody Brocious I guess it is true then

Whoever does not understand LISP, is doomed to reinvent it. ;-)

To an extent, yes, but there's something to be said for mixing the best of both worlds.
Cody Brocious
Of course! Mixing the best of all worlds is exactly what Common Lisp is about. :)
Matthias Benkard
+46  A: 

There has never been a widely accepted lisp environment that:

  • works on multiple platforms,
  • is free or cheap to use, and
  • fully implements the lisp standard.

There are a lot of different lisps out there, and they all have distinct advantages/disadvantages -- most of which are not compatible.

This contributes to the absence of a reliable infrastructure for lisp applications, and other languages have fleshed out in this regard while lisp's community has remained fragmented.

GNU CLISP fits all of your bullet points, I think, but I grant you that it does have its weaknesses. Personally, I still think that better C integration is the most painfully missing feature of most implementations including CLISP.
Matthias Benkard
IIRC, CLISP has issues with threading and (last I checked) was not as complete of an implementation of lisp as SBCL. That could easily have changed in the intervening years though. It also requires cygwin to run in windows, which is a show-stopper for many people.
Not only is CLISP not as complete as SBCL but CLISP intentionally violates the hyperspec (the language standard of Common Lisp). SBCL is finally converging on the bullet points, but this is a very recent development.
Jason Dagit
There's also the lack of straightforward integration with the underlying platform, especially when it comes to deploying created applications.
Chris Hanson
I disagree with this answer. CLISP and SBCL do all this.Saying CLISP doesn't follow the CL spec is like saying GCC violates C99. Also, the hyperspec is a web site, not a standards document.
I'm not sure whether there's a widely accepted C++ compiler that meets all of those criteria. (Substituting C++ for lisp in the last bullet point, obviously.)
Sam Stokes
Surely the diversity of the comments above prove the poster's point? :)
(offtopic) @Sam - actually, there are none. separately compiled C++ templates is a feature implemented by none of the major vendors -- not a problem, because no one actually wants to use that feature.
jfm3: Unless you can point to a specific part of the hyperspec that is in contradition to the CL standard, I an inclined to believe Kent M Pitman (the creator of the hyperspec and the editor of the standard) when he claims that they are essentially identical.
CLISP is not free it is under GPL faschism which makes it unuseable for many companies. It is also a pretty bad environment, GC is slow and no threading/multicore support.
+7  A: 

It's not just LISP, but functional languages in general (ML, Scheme, etc.). The fundamental reasons I see:

  • Large paradigm shift -- thinking in terms of functions, not data
  • "Academic" -- it's taught in schools, but most kids tinkering around with VB/HTML/JavaScript won't encounter it. I was pretty interested in computers growing up, but never heard of LISP until I got to college.

However, there are certain "ideals" from functional languages that do make their way into programs. UNIX shell scripting involves linking commands ("functions") together, like "cat foo.txt | sort | uniq -c" which is a functional way of handling it. You define methods and let the data pass through, not even declaring a single variable.

Some of the ideas from functional languages are very applicable to the real world, but I think they're seen as disconnected.

Common Lisp is not much functional, it's multiparadigm. And thinking in terms of functions instead of data is IMHO wrong (the data structures determine the algorithms, not the other way around).
Also Hascal and Scala are new functional languages and are already getting more widespread use than Lisp...
Bill K
+38  A: 
  1. Popular, self-perpetuating misconceptions. (Just look at the posts here. (a) I never ever keep track of parentheses when programming in Lisp! My editor does that for me. (b) Scheme may be a functional language, but I LOOP happily all day long in Common Lisp, thank you very much.)
  2. Lack of a definitive standard implementation with lots of “Batteries Included.”
  3. Potential newbies' previous exposure to Scheme in a programming languages course, having hated it, and not looking into other Lisp dialects because they superficially look like Scheme. (This is related to #1.)
  4. Lack of a well-supported implementation that works the way a C programmer expects (i.e. using a traditional edit-compile-link-run cycle and being able to seamlessly link C and Lisp code).
  5. Lack of various libraries (the situation is changing for the better right as we're wasting time here, though).
  6. Lack of clear guidance for newbies. Practical Common Lisp does a very nice job providing a Lisp tutorial/textbook, but it still doesn't seem to be visible enough. There is still no real community portal on the web, either.
Matthias Benkard
OK, some versions have loops, but I remember have met some LISPers taht would shun you for thinking "iteration"
That would probably have been a Schemer. :)I agree that some dialects (like Scheme, for instance) are to be considered functional languages and strongly encourage a functional style, but not all Lisps are like Scheme.In fact, even PLT Scheme is more of a CL than a Scheme in many ways...
Matthias Benkard
re #3, I loved scheme when I had courses using it, and for my job as an AutoCAD programmer, AutoLisp is closer to scheme than Common List.
I so agree with #3. Maybe I should look at another lisp...
@crashmstr I'm with you... in my programming languages course, scheme struck me as the most interesting language by FAR because of it's elegance, and paired with the short introduction to lambda calculus the professor gave. Really was tons of fun to learn, and I always think fondly on that class because of it.
Mike Stone
I couldn't agree with you more and would up-vote you many times if I could!
+14  A: 

I've come to believe that the primary reason to use any given language is "How hard is it for the next guy to read". (This is assuming your language produces a reliable program consistently).

The smarter the language is, the more difficult it can be to unravel the last guys great code tricks. Concepts like OO are completely unnecessary from the point of view of someone trying to communicate with a computer, but very helpful in organizing your design and communicating it to others.

Maybe I've just been looking at c-style code too long, but I find polish notation mostly unnatural--cool but tough to grasp what a large block is doing at a glance.

This is the main reason I can't seem to accept Lisp--and I've tried more than once.

Bill K
I've tried as well -- I found a great tutorial here: explains Lisp in terms of real-world problems (XML configuration) . I'm still getting my head around it, but found it an excellent read.
1. Polish notation is not very different from a c function call: just take the opening paren and move it one more step to the left.2. Lisp has solid support for OO through the Common Lisp Object System (CLOS). In fact, I'd even say CLOS is a little bit more powerful than what c++ offers.
@krdluzni Not that I disagree with that, but I still stand by my point that it's not used that much because many developers are uncomfortable with the notation and syntax. Did you have a better reason? You might post an answer.
Bill K
Posted one now.
+1  A: 

My theory is that our brains are set up to be able to naturally process a certain amount of information in syntax. So in reading languages with syntax the "syntax recognition" piece of their brain grabs some of the information, leaving less for the "content analysis" piece to have to process. By contrast with the various Lisp languages there is almost no syntax recognition (other than pairing parens, which information we mostly duplicate with indentation) which puts all of the work on our ability to analyze content.

Of course the trade-off is that by having things that would be done in syntax in other languages not be special in Lisp is that you can manipulate them in macros very effectively. But most users aren't using their language on that level, and so don't notice how much power they are giving up.

Why has this been downvoted into negative territory? I personally somewhat disagree with the point being made, but it's an interesting point nonetheless.
Matthias Benkard
Human brains don't have a syntax processor chained to a semantic processor. We are not compilers. We do pattern matching, and Lisp code just contains a slightly different kind of patterns than C or Java code. Lisp code patterns may even be easier to parse by a human brain.
Nowhere man
+16  A: 

Look at all the misconceptions in these answers and you'll see the number one reason is that the Lisp community failed to get Lisp proper marketing.

There were many Lisp dialects in the past. The surviving ones are basically 2: Common Lisp and Scheme, each with different strengths.

Scheme is an ongoing minimalist language whose main purposes are to serve as vehicle for research projects and to educate students on fundamental concepts about computations and computability. Many people, thus, get pissed at it for the same reason they get pissed at math or any other educational discipline. Then, they think Scheme/Lisp is a toy without real-world purpose.

CL is the industrial-strength ANSI-standard Lisp, basically a very robust and full "batteries-included" standard language, with many strong free and fast implementations and some quality commercial ones with full-blown IDEs. It's not essentially a functional language, instead being a multiparadigm language, though predominantly favoring imperative programming complete with a very robust Object System (CLOS). It also features the famous macro facility for adapting the language for your needs. Last but not least, the implementations compile to very fast code and the runtime can be dynamically patched with new compiled code on-the-fly, possibly after a careful debugging session while the system still runs. No reinitialization means no time spend stopping the systems.

The parentheses are only a problem when you: 1) give only a superficial look at the language and see what stands out; 2) don't realize they are an incredible programming aid for editors (structured editing at its best, unless you use primitive stuff like notepad); 3) don't understand it is one of the reasons Lisp macros are so powerful (because Lisp code is represented as Lisp data, a list).

I think “Batteries Included” is quite relative. Python lets me “import xmllib” and off I go. Of course, “(asdf-install:install :cxml)” is not much more work, but I have to (1) browse the CLiki, (2) look for the CXML docs on the project page, (3) add the dependency to my .asd file... It all adds up.
Matthias Benkard
@Matthias: I'm sure the first time you wanted to do XML in python, you had to look up how to do it. @author: just a note that scheme has those powerful macros, too!
Only disagreement here is that Lisp is predominately functional, not imperative. The multiparadigm qualities of Lisp are such that you can write entirely imperative code and do great work, but the language was very much intended to be used in functional programming.
Ben Collins
+8  A: 

Lisp is a huge paradigm shift: the syntax is different, you may be encouraged or forced to do functional programming and you go from the edit-compile-test cycle to the interactive modification of a running image.

That huge paradigme shift is one of the things that made me love Lisp, because it opens the mind. But most humans are reluctant to change.

Myths about Lisp probably only are excuses to avoid the change and rationalize.

Nowhere man
It's not a paradigm shift if it's the first language you learn.
@TraumaPony: obviously, but Lisp also isn't widely taught as a first language.
Nowhere man
Common Lisp isn't functional. Scheme lends itself to a functional style, although you can write imperative and object-oriented code easily enough if you want to.
Noah Lavine

Two words, parentheses hell! (Just kidding).

I think that functional programming languages in general are just hard to learn, and it is a great paradigm shift from imperative and OO programming. I have over 6 years of experience, and I double majored in CIS and Math at a major state university, and I’m just starting to learn about functional programming and its concepts. Maybe it’s me, or maybe it’s where I live and went to school, but I think that it is more of a systemic problem. Remember, this is a community of Einsteins and Elvises in a world of Morts.

But I think that the state of functional languages has also had some responsibility for their lack of adoption. Think about it. What does it mean to be a purely functional language? To not have side effects. Well, we live in a world of applications that, by their very nature, need to have side effects.

I think that languages such as F# might change this. It takes a good amount of logic from OO and imperative languages and builds in key functional concepts. It also is hooked into a rich application framework (.Net), so that its users can have their cake and eat it to. Hopefully, it will no have the adoption problems of functional languages of the past.

On the bright side, I think that evolution of hardware being increasingly multi core is going to force us all to embrace functional programming, whether we like it or not.

Charles Graham
But OO was a huge paradigm shift from procedural programming. Why did a critical mass embrace OO but not FP?
Note there isn't any programming language without side effects. The interesting feature is to be able to isolate side effects for pure computation...
Nowhere man
+3  A: 

My only exposure to LISP, as seems to be common based on the other responses here, was a Scheme course in college. It seemed like an interesting toy (unlike the other responses, I absolutely loved it and found it incredibly fun to play with), but, whether by fault of the class or by fault of Scheme itself, there was no evidence presented of it having any real-world use, so I didn't do much with it after that class was done.

Dave Sherohman
+5  A: 

Jeff Atwood makes the argument that it's more about the platform than the language:

Language vs. Platform

Jason Baker
+7  A: 

Because LISP proponents spent 40 years telling everyone how great it was and no time showing everyone how great it was with real world projects.

Right. There was a town-gown problem.
Mike Dunlavey
+1  A: 

Until now I still can't get asdf-install to work on Clisp. I just manage to solve the website problem by changing from the original to However, some error like ``undefined function ASDF-INSTALL::READ-HEADER-LINE'' popup with a cryptic advice: You may input a value to be used instead of (FDEFINITION 'ASDF-INSTALL::READ-HEADER-LINE). I know asdf-install works with sbcl, but I think all of us has the freedom to choose any Lisp implementation and everything still works, just like anything working on CPython should work on Jython or IronPython. Lisp really has a lot of works to do. I am curious that when SBCL and Clisp are actively maintain, how come Cliki pages are never update even when has been down extremely long?

+21  A: 

Funny how there are millions of coders wanting to program in XML, yet get scared of a few parenthesis. IMO S-expressions are just shorthand for XML :)

I've always thought exactly what you said. XML is just an unnecessarily wordy version of S-expression syntax. Plus you have to parse it. S-expressions only need to be read or printed.
Mike Dunlavey
And then languages like Ant. I had a coworker extoll to me the virtues of Ant, but deride the parenthesis of Lisp. Hmm...
To put it another way, XML is a longwinded way of expressing S-Expressions.
+2  A: 

Why do you care about whether it is popular or not? To me, popular means it is used by the average people. If you are looking for something good, I think it's better to see what and why the exceptional people are using.

Levente Mészáros
In a perfect world, it wouldn't matter whether it's popular or not. But let's say you're an gifted engineer whose a pro at LISP, and apply at Google. Well guess what? They sure-as-shit won't let you write your code in LISP.
Earning money is obviously a different thing, there are many factors to take into account when you are trying to get a job. You are right, but the question was about something else.
Levente Mészáros
+1  A: 

Well, call it a coincidence, but I've just started studying LISP about a week ago, in my (little) spare time. If you want some real insight, I can suggest you to look at Paul Graham site. Everything he says is just more interesting than what can I write...

Not a surprise, considering HE is the life-long LISP hacker among the two! :)

I taked a look at his works on LISP and suddenly founded I wanted to know more, and began to study it...

+26  A: 

The lack of libraries is the main cause !

We are currently (re)writing fairly large web application in LISP (porting it from java/sql because business logic complexity has grown up to unmanageable proportions).

And we had to reinvent the wheel so many times -- think reverse indexing for full text search, extracting content from XLS/DOC files, SMTP message handling (you might think there are a lot of open libraries available until you start receiving messages from real world -- multiple multipart/mixed international encoding parts in one message sent by Outlook/Outlook Express and such...), decent persistence library is also lacking (apart from proprietary/locked AllegroCache -- all other implementations are immature at best, crappy at least ..), exporting datasets to Excel, handling TCP/IP traffic storm caused by heavy AJAX usage in the UI by 800-2000 simultaneously connected clients (Hunchentoon stalls for several seconds), also try to find a decent date-time library capable of adjusting dates for national holidays and so on and so on.

I'm a team leader and I had to decline continuous requests from team members to switch to Python. Everyone in the team acknowledges and loves LISP syntax, but it is so difficult when you have to (re)write all the libraries needed... I think we are about to switch to Python soon. LISP prototype we created is good and valuable -- it cleaned-up many design issues for us -- but when we speak about applications for the real world - LISP is not ready yet and will not be in the nearest future.

Thank god we have a working Java version to sell to our clients until we experiment with next version of our product - otherwise our small company (only 11 developers) would not be capable of sustaining operation during our LISP experiment.

Many developers think Java is lame and strive for an elegant language with beautiful syntax, but sorry guys - Resin Java2EE Applications Server has rapid response to AJAX connections, popular Java SMTP libraries are capable of handling real-world messages, there is Lucene for full-text search, there is joda-time (with extensions) for date-time handling and so on and so on. With Python it's the same - a lot of proven real world libraries.

LISP is beatiful language but there's no way to write real-world applications in it. And I'm really sorry about that ...

Please excuse me for my bad English - English is not my native language and I already had 3 cups of wine this evening, but nevertheless my message describes a painful first-hand experience.

Sounds like you should buy Allegro CL. The mail libraries, for example, are excellent.Sometimes paying for things is worth it.
Nick, your English is at least as good as mine, and it's the only language I speak (shame on me, I can't even speak my native Gaelic)
Binary Worrier
so, where are all those libraries available that you had to (re)implement?
Attila Lendvai
Well I disagree, there are tons of libraries but they often lack useability. I invite anyone to check UCW or Cells for a start....One thing is that people like to "rewrite" code themselves, this is mostly true for Common Lisp but on can see that in C also
I am Pythonista who is trying to learn Lisp now, and I couldn't agree more with this. It would be great if there would be some online resource or project which would list the Python standard library functions with the CL replacements for all of them, or created the replacements if those were missing.
What do you think about Clojure then? Doesn't it solve the problem with lack of libraries?
+3  A: 

There has been little mention of the attitude of many lisp programmers to people who aren't keen on lisp. Look at the down votes for anyone whose reasons not to use it aren't acceptable. They're actually good answers to the question (which is why lisp isn't widely used not what's wrong with lisp). And instead of trying to win them over the lisp fans just vote them down.

There is a superior attitude amonst many lisp programmers (including some promonent ones) which is very off-putting. In this case, social reasons matter as much technical ones, if not more so.

Daniel James
+5  A: 

Lisp needs love. A new to make newcomers find what they look when asking for themselves "what's Lisp?! how can I learn more?! ok, let me try google about lisp... hmm... Lisp is good". Lisp needs a batteries included package, like Python does. More friendly tutorials to explain the "Lisp world" to newcomers. A Perl CPAN like too.

I think Lisp isn't more widely used because of these basic things. Every language today grows with these, Lisp is a 50-years old language, so we need to create these basic things for her.


First of all, you do know that LISP stands for "Lots of Infuriating Silly Parentheses." But I go along with the lack of libraries.

Contrast that with the Java experience. It came out, and right away, libraries starting popping up everywhere. Lisp never snowballed that way. Too bad.


Peter Chistensen compiled a very good list of places where lisp is used.

+3  A: 

Adoption of computer languages is not controlled by how good it is for writing programs.

Lisp is a testbed of many great concepts and ideas. It is a language that has molded people's views about languages. That's an achievement itself so lisp really deserves to be called great.

The lisp syntax itself is not being adopted widely because it's impractical. Lack of variety in the syntax means you use the syntax you have - you end up writing more.

Good macro systems are alleviating this problem, but not solving it. Actually, macros are pretty violent way to solve things and you know violence leads to more violence. More you step out of the syntax you have, more you get burden and more you alleviate it with macros. When you break out from your syntax, you'll get more syntax to break out from.

Lisp could exist without macros, of course. It could be simply well-designed without macros. But adding syntax carefully has been empirically proved being a good choice.

((get routine) a1 a2 a3)
(define '(double x)
  '(* 2 x))

(a1, a2, a3)(routine)get
@{double x}define

get(routine)(a1, a2, a3)
define{double x}@
#or.. define{double x}{2*x}

You can see that when you are adding small pieces of syntax, trivial things get more trivial. Algebraic notation of functions removes nested parentheses, indentation directly removes parentheses while adding a character to remember. Having different parentheses for quotation is nicer, and so on...

+2  A: 

I think one of the issues people have missed is the prejudices people had in the 80's that dynamically-typed languages were never going to be efficient enough for "real world" programming.

Of course that particular misconception persisted well after commercial Lisp implementations were catching up with C (note all the buffer overflow problems causing security headaches are entirely the fault of the same prejudices!!).

In the 90's the emergence of Java just as people were struggling with the complexities and pitfalls of C++ showed that dynamically typed languages are competitive and these strengths led to Java growing very rapidly - its simplicity and crashproofness expedited the rise of course.

So Lisp got left out, but many of its good ideas won over in the "Java revolution" if you can call it that. In the 80's many people believed full garbage collection (as opposed to reference counting) was incompatible with a general purpose language...

Advances in garbage-collection technology throughout the 80's and 90's have more or less destroyed that argument, but the views of many didn't track the technology advances as they weren't aware of them. Generational GC was the big breakthrough, sometime in the 80's.

So basically Java stole a lot of the space that Lisp could (and probably would) have "won big" in as anti-GC and anti-dynamic-type sentiments gradually faded. And Java was free of course - not that there aren't good Lisps available in free versions, its just that Java was free, there was one version and it was a good version.

(Many non-general-purpose dynamic GC'ed languages have flourished of course, but mainly domain-specific and interpreted/scripting ones).

And I'll end on an observation about Lisp-like (dynamic) v. C-like (static) languages. There is a java source-to-bytecode compiler called Jikes, which is written in C++ and is intended as a more-or-less plug-compatible replacement for javac (the Java compiler written in Java). Jikes is fast. Its very fast, perhaps 10 to 20 times faster than javac. Its faster than it needs to be on modern hardware(!), even large projects compile in seconds. There are no versions of Jikes I have used that haven't CRASHED. Every single one has crashed on one large suite of input Java or another... You have to choose the right Jikes version for the project you are on by trial and error. It has got better, it has got worse, but it crashes. Javac doesn't crash. It's purely in Java so once the java runtime has been debugged it can't crash.

I could also mention the P-code saga, but I'll leave that.

Java doesn't even come close to being a "dynamically-typed" language. Lisp is functional; Java is object-oriented, procedural. They don't even compare!
+2  A: 

Having gone from loving Fortran (horrors!) to loving Lisp (bliss!), then to Pascal, C, C++, and so on, I always felt the main problem with Lisp was that you couldn't easily just write an app, compile it into an executable, stick it on a floppy, and run it anywhere.

All the issues of syntax and parentheses are just a matter of getting used to it, and usually you can get things done in a fraction of the code. For instance, if you want to do symbolic differentiation of mathematical expressions, it's almost child's play. At the same time, there's no harm in saying that LISP means "lots of irritating single parentheses".

At the same time, Lisp is really the poorer for missing out on features that started with Pascal, such as strong typing and optional call-by-reference.

I get bothered by those who denigrate the macros. I'm of the school that says the way of the future is domain-specific-languages, and the power of macros is that you can easily build DSLs on top of Lisp.

Not to say it can't be abused. Programmers who are going to make mountains out of molehills can easily do that in Lisp.

Mike Dunlavey
+3  A: 

There's a lot of accurate information and true-myths here.

"Lisp = Lots of irritating superfluous parenthesis"

Myth. Yes, you'll see "))))))" quite frequently. But in C++ you have ;\n}\n;\n}\n;\n}. It's a joke, but not the real problem.

Yes, Lisp is interesting, but learning X will be too hard -- For X in { functional-programming, recursion, macro-programming, lambda-expressions, ... }

Very Real, at least in perception. Lisp has a nice (enough) imperative programming language living in it too, but too often this gets downplayed. Yes, Lisp is cool. But it can also be boring when you need it to be, such as when rehabilitating from an imperative-OO-only language:

(defun (factorial x)
  "calculate factorial the *boring* way"
  (let ((accum 1))
       (loop for current-factor in 1 to x
             (setf accum (* current-factor accum)))
       (return accum)))

Functional programming adherents -- let us collectively cringe at this code once, get it out of the way. Then give it to our C++/Perl/Java/C# colleague, and say "look, this will ease you through the transition". Give them Defun, Let, Setf, Read, and a couple of Loop and Format examples, just to get started with.

And then tantalize them with some wickedly cool code. That way they'll have tools, confidence, and inspiration.

Where are the standardized libraries?

Fact, but becoming Myth. Convincing the C++ programmers may be easier here -- Until -1 to -2 years ago, the C++ standard didn't even have hash tables. But what about sockets? Xml (shudder) parsing? Web services? It's been a while since C++ developers were cut off from good libraries, and C#/Java developers had standard distributed everything by the time they had the syntax down.

At least, that's basically what I see right now.

Aside: My path to Lisp: VB -> C -> C# -> C++ -> Python -> Common Lisp, with that last step being last month. I'm fairly green, but I think that gives me more

+2  A: 

My biggest issue was that i want to have GUI builtin, easy to run and maintaine without have to add a lot of stuff extra package.

I found that "Clojure" that solve all my problem learning LISP´, is a dialekt that runs in a java vm, witch mean portability, and access to Swing GUI library, woth looking att.

And if you are not and Emacs fan, there is a plugin for Eclipse, still under development but it makes Lisp development more.... year 2009 style.


+4  A: 

I think there are a number of reasons, including the syntax, the fact that it's difficult to learn, and that it is less efficient (or it's at least more difficult to write a compiler that generates efficient code) than other languages like C/C++.

I think one of the biggest issues, though, is the fact that there has never been, to my knowledge, a popular implementation promoted by a large company. When Sun released Java, for example, they did a lot of marketing for it. Similarly Microsoft made a huge marketing effort for C# and .NET. Even back in the DOS days, Microsoft put out QuickC, QuickBASIC and even QuickFortran. There was never "QuickLISP", and there has never been a "Microsoft Visual LISP" either.

These things don't affect the technical suitability of a language but they do affect how it's perceived, and that can have just as much, if not more, influence. It's like the old adage, "nobody ever got fired for buying IBM" - nobody ever got fired for using Microsoft's C++ compiler.

Simon Howard

For me the main cause is: the language is not intuitive. It is confuse.

Carlos Eduardo Olivieri
+1  A: 

Having just spent 6 months (part time) deploying a lisp web server, I would say the main downside when compared to other languages is the lack of a standardised way of talking to foreign code.

So when someone wants to re-use a well written library in another language (OpenSSL perhaps), there is no way for them to do so without using implementation specific hacks.

Some of those hacks are very clever, so developing code to talk to C is easy. Getting it to live long, and be re-used by other lispers, is hard.

John McAleely

Nobody knows why one language is popular and another languishes. Nobody knows why one film will become popular and another will bomb. That's because popularity depends on the decisions of a multitude of complex human beings who don't even (fully) know their own motivations.

+1  A: 

Many dismiss the parentheses issue as a joke and bringing it up leads often to flame wars, but I propose that it is actually a significant factor. Many people are simply put off by the syntax and it doesn't help much to point out that there are text editors that help you balance the parentheses. (Balancing curlies in C manually is quite easy in comparison.)

It may be that for some people, reading LISP is simply more difficult than for others for reasons best explained by cognitive psychology and it isn't a matter of the amount of exposure. Until someone actually tests this hypothesis, we won't know for sure.

For that matter, C at least uses different brackets for different purposes, unlike lisp. Also, the problem is quite real even in C/C++ IMHO: nesting is a problem everywhere; the Python solution is probably the least-bad.
Eamon Nerbonne

Many of the above answers allude to libraries as a source of friction when using lisp. I'm surprised that none have explicitly pointed out that, perhaps more than availability of libraries per se (Common Lisp has quite a number of high-quality libraries...), the issue of library management is itself a significant issue with Common Lisp. Some libraries are available via ASDF-Install, some libraries aren't... ASDF-Install lives in a "tar.gz"-only world and current versions of some libraries are available only via a darcs interface while current versions of other libraries are available only via a git interface, etc.

To top it off, when interlibrary dependencies include version issues, things can turn into a royal first-class hassle since many ASDF libraries don't even bother advertising version information (using :version in the defsystem form).

In short, nothing remotely close to the convenience of a rpm or dpkg-type system (with the ability to deal with interlibrary version dependency issues -- and with access to current versions of the majority of libraries of interest) is widely used with CL.

The efforts invested in cl-librarian, mudballs, and clbuild are worth considering...


Two Words : AI Winter


Scheme is becoming more popular these days (although, pretty much every programming language is), but suffers somewhat from varying consistency between implementations (i.e. popular implementation-specific API in Gambit, Chicken etc), and suffers greatly from a lack of built-in/easily-installed libraries for common tasks. I remember struggling to replace matching characters in a string and having to google the SRFIs (semi-standard Scheme extensions which might be implemented in your Scheme), and despairing at how comparatively easy and obvious it is in, say, Python. Similarly if you want to write a GUI program, some extra work is involved might drive away newbies.

Also, IDE support is a bit patchy. Everything is done in Emacs, which some Lisp fanatics will claim is a good thing (and if you get familiar with Emacs, you probably will enjoy its features), but things like identifier completion and the kind of refactoring/utility support you get when programming Java in Eclipse is sorely missed. OTOH, PLT Scheme's DrScheme is a very promising IDE with a friendly interface, but it has its own limitations (for one, it seems a bit heavyweight).

Common Lisp addresses the library issues to a degree, but there are some headaches (such as asdf-install), and it can be a bit overwhelming.


I'd say syntax is part of the problem, but not that they're uncomfortable with it, more that after seeing it they won't even try.

The bigger problem though is in the industry: It's used, but not enough for people to treat it as one of the big ones. Java/C/C++ are big. Ruby has Rails which gave it a strong push. Python is on the list of criteria for getting hired at Google and other major companies (even if they won't make you use it). Lisp...just exists. It isn't pushed by the industry, and there are too many misconceptions about it not having an object system, or not allowing side effects.


The obvious reason is that most people hate working in Lisp.

That's all, there are some people that love it, but most people hate it, and mostly hate it not because of its structure, of the use of recursion and all that, but the syntax, most people like 'mathematical textbook notation', that's why languages like Ruby and Python were invented, which have most of the expressive power of Lisps, but are still presented in mathematical textbook notation.

As a consequence though they aren't homo-iconic, and thus it's infeasible to compile them to machine code.