Welcome to Omgili,
Omgili ( Oh My God I Love It ;) is a search engine for discussions. With Omgili you can find answers and solutions, debates, discussions, personal experiences, opinions and more... To learn more about Omgili click here.
This is a complete preview of the discussion as it was indexed by Omgili crawlers. Use this preview if the original discussion is unavailable.
Click here to view the original discussion.
 |
|
 |
|
Why isn't LISP more widely used?
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.
|
|
|
|
|
|
|
|
|
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.)
|
|
|
|
|
|
|
|
|
I have heard that recursion is hard to grasp for some programmers, so this may be a factor since recursion is so critical in the language.
I personally find recursion not very hard, but I have seen a lot of programmers struggle with it (more the 9-5 type programmers that look puzzled when you mention fibonacci, or scowl when you try to talk programming during lunch...
But these are also probably a reasonably large subset of programmers).
EDIT: Also, I couldn't help but think of this XKCD:
|
|
|
|
|
|
|
|
|
Not the top reason, but I think the lack of 3rd party libraries is also worth a mention.
|
|
|
|
|
|
|
|
|
@ Guy , @ Cody Brocious I guess it is true then
Whoever does not understand LISP, is doomed to reinvent it.
;-)
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
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.) Lack of a definitive standard implementation with lots of “Batteries Included.” 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.) 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).
Lack of various libraries (the situation is changing for the better right as we're wasting time here, though).
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.
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
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).
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
Jeff Atwood makes the argument that it's more about the platform than the language:
Language vs.
Platform
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
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 :)
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
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...
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
Peter Chistensen compiled a very good list of places where lisp is used.
|
|
|
|
|
|
|
|
|
Programmers either need performance or interoperability.
Java, C#, F# and other statically-typed compiled languages provide performance.
Ruby, Python, Groovy and other interpreted languages with huge standard libraries provide interoperability.
Lisp provides neither.
Cheers, Jon Harrop.
|
|
|
|
|
|
|
|
|
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...
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
For me the main cause is: the language is not intuitive.
It is confuse.
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
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...
|
|
|
|
|
|
|
|