Why isn't LISP more widely used?

Question

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)?

Answer 1

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

Answer 2

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.

Answer 3

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

Answer 4

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

Answer 5

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

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

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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

Answer 12

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.

Answer 13

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.

Answer 14

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.

Answer 15

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

Language vs. Platform

Answer 16

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.

Answer 17

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 http://ww.telent.net/cclan-choose-mirror to http://ftp.linux.org.uk/pub/lisp/cclan. 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 telent.net has been down extremely long?

Answer 18

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 :)

Answer 19

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.

Answer 20

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

Answer 21

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.

Answer 22

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.

Answer 23

Lisp needs love. A new lisp.org 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.

Answer 24

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.

Answer 25

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

Answer 26

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
  2*x

get(routine)(a1, a2, a3)
define{double x}@
  2*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...

Answer 27

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.

Answer 28

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.

Answer 29

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

Answer 30

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. http://clojure.org

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.

Anders

Answer 31

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.

Answer 32

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

Answer 33

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.

Answer 34

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.

Answer 35

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.

Answer 36

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

Answer 37

Two Words : AI Winter

Answer 38

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.

Answer 39

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.

Answer 40

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.