111

I don't know enough Lisp to say whether it's good or bad. It seems like everyone who has used Lisp loves it, yet the most popular languages these days are descended from C.

So what is it about Lisp that is so great and why isn't it used more? Is there anything just plain bad about Lisp (other than the incessant amount of parentheses)?

nicael
  • 18,550
  • 13
  • 57
  • 90
Darrell Brogdon
  • 6,843
  • 9
  • 47
  • 62
  • 6
    "Most popular languages these days are descended from C" only superficially. If you look at the features instead of just the use of curly braces, you'll find that modern languages are not that far from Lisp, and getting closer all the time. A program in C# or Python or Ruby, say, will look a lot more like Lisp than it will like C. – Ken Jan 10 '10 at 05:54
  • 11
    A good example of a language that looks like C but acts more like Lisp is JavaScript. A lot of it's design is similar to Scheme. – JAL Jan 10 '10 at 06:04
  • Good point, Ken: an increasing number of features that used to be unique to Lisp (first class functions, functions as data, even macros) are arriving in other languages. And the feedback isn't one-way: Lisp is evolving new techniques and idioms in recognition of other languages (e.g. CLOS in response to the success of the object-oriented paradigm). – itowlson Jan 10 '10 at 06:07
  • 6
    Lisp has taken ideas from all over, but CLOS in response to what? CLOS (1986-1987) was largely a standardization of earlier object systems for Lisp, e.g., Lisp Machine Lisp (1980) included Flavors. I don't think that "the success of the OO paradigm" was yet apparent in 1980: "C with Classes" was only a year old (and still 3 years away from being renamed "C++"), and I don't know that Simula-67 was ever very popular. Lisp has a bunch of other advanced features that popular languages today don't have; OO happens to have gotten successful, but Lisp didn't get it because (or when) it was popular. – Ken Jan 10 '10 at 07:31
  • 1
    I don't think that everyone who used Lisp loves it. My experience is different. Try to ask computer science students who started with Scheme. Probably about 10% will love it, 30% will respect it and 60% will hate it. I also don't think most popular languages are descended from C. – Rainer Joswig Jan 12 '10 at 09:08
  • Rainer: My experience is that most people using it love it, but then, I've never seen it in an academic setting. In school, where people are forced upon it, I think that 10/30/60 applies to every language. That matches pretty well with what I saw with more mainstream languages in high school and college. – Ken Jan 12 '10 at 16:01
  • Ken, that says little. There are not that many Lisp jobs and those are taken by people who like Lisp - with a few people who like some other languages better, but find no job for that and take a Lisp job as an acceptable alternative. The Java job market is much larger and many people use it because they have to - they can't choose the tool. It's the company/boss/client who has chosen for them. If there were more Lisp jobs, you would have more people using it just for economic necessity. – Rainer Joswig Jan 12 '10 at 19:16
  • Rainer, can you be more specific about the reasons why people hated Scheme? I bet the reasons are either parentheses/prefix notation (which is a superficial problem that takes used to, like with RPN calculators) and maybe the fact the Scheme tends heavily towards functional programming, which is unnatural to most people (including me), but Common Lisp doesn't have this problem. – J S Jan 13 '10 at 06:31
  • Rainer: Do you disagree that the 10/30/60 split applies to other languages in academic settings? Lisp-in-industry may be a vanishingly small sample but {Java,C,C++}-in-academia isn't. I think it would be entirely accurate to say that over 60% of students I've worked or studied with have hated C and C++, and Java only slightly less. – Ken Jan 24 '10 at 19:55
  • the amount of parentheses are not really a problem, there are editors that handle parentheses balancing for you – ChrisBlom Mar 26 '14 at 18:51
  • I think that school damaged Lisp by teaching it badly : (. Clojure at least fixed many of the perceived problems of Lisp by pattern matching, arrays, and hash tables by default instead of cons/cdr/car and by having slightly more syntax to make it easier to parse. Macros and homoiconicity is the main awesome thing about Lisp, and only available in say the infix languages like Julia or Dylan. I usually code in Python so I use parinfer which makes editing Lisp seem like editing Python its awesome and it also dims the parens. https://shaunlebron.github.io/parinfer/ – aoeu256 Aug 29 '19 at 14:13

7 Answers7

85

Lisp is good because it has a very minimal, simple, regular syntax.

Lisp is bad because it has a very minimal, simple, regular syntax.

Daniel Earwicker
  • 114,894
  • 38
  • 205
  • 284
  • 6
    What's bad about a minimal, simple, regular syntax? – oskarkv Apr 27 '13 at 11:56
  • 41
    @oskarkv - a totally regular minimal syntax means that there is no bias towards any particular use. This sounds good, until you encounter the Pareto principle: it is more efficient to be biased towards the most commonly occurring cases, and stop pretending that all cases are equally likely. If 20% of your customers are in NYC and 80% in LA, does it make sense to sit on the fence, somewhere on the Kansas/Oklahoma border, so as to remain "unbiased" in geographical terms? Or more sense to go where most of the customers are? We prefer languages that skew their features towards likely problems. – Daniel Earwicker Apr 29 '13 at 10:15
  • 5
    Lisp syntax is really good. I learned Haskell after Clojure, but by then even Haskell's syntax felt like a hindrance. The uniformity of Lisp's suntax is great. So, I don't exactly know what bias you are talking about. Bias towards inflexibility? Sounds bad. – oskarkv Apr 29 '13 at 11:34
  • 5
    It does sound bad when you put it like that. I didn't put it like that! How about bias toward the most common occurrences, the most likely situations? These are (of course) relative terms, so it depends what you're doing. If you genuinely lack any information about what you will be doing, there is no point trying to prepare. But it's probably not true - you do have information, and so you can prepare ("bias") yourself towards the most likely situations you need to be ready for. – Daniel Earwicker Apr 29 '13 at 12:12
  • Lisp's syntax is neither good nor bad. It's just a tree. Code editors are bad because they make you edit a tree using text and parentheses characters, which is absolutely insane. – iono Jul 13 '22 at 11:33
  • @iono How should editors edit Lisp? Can you give an example of an editor that does it right? – csmathhc Nov 26 '22 at 20:17
  • @csmathhc Unfortunately, they don't exist yet (in any remotely mature form). hazel.org and "Fructure" for Racket (https://www.youtube.com/watch?v=CnbVCNIh1NA) are two good tangible gestures in this direction. In my imagining, our current status quo – editing code as text – is roughly as *relatively* inefficient and stifling as programming via punchcards appears to us in the modern context. There's a whole world of society-transforming possibility out there; programming could and should be so, so, SO much faster and more accessible. – iono Nov 28 '22 at 16:34
77

“Lisp is a programmable programming language.”
— John Foderaro, CACM, September 1991

Here’s my view:

On the surface, Lisp is a nice, simple functional programming language. There’s almost no syntax, and all the pieces fit together in logical ways.

If you dig a little deeper, read SICP, and write a metacircular evaluator, you discover two things: One, the whole interpreter (given just a few primitives) is just barely a page of code, and two, the relationship between code and data allows for elegant programming techniques.

Once you’ve fully absorbed this, it feels like other languages are set in stone when they only allow you to say a few things. Lisp can build any abstraction at all if you can define syntax and semantics for it.

nbro
  • 15,395
  • 32
  • 113
  • 196
Josh Lee
  • 171,072
  • 38
  • 269
  • 275
  • 1
    You could in theory embed any language into Lisp like Rust, Ruby, C, Java, Python, Erlang. So the s-expression version of Python (Hy) and the of Rust is called (Risp) [although I don't know how stable these are]. If you write code in Hy instead of Python you have the ability of macros and structural editing like parinfer/paredit(https://shaunlebron.github.io/parinfer/). Macros allow you to embed your own DSLs in Lisp, and they can also be used to turn slow code to fast code via compiler macros. You can also turn Python(Hy) code into Rust(Risp), by transforming the sexp tree. – aoeu256 Aug 29 '19 at 14:28
  • 1
    I've also heard this saying multiple times. Would you eliberate a bit more @aoeu256 ? – Student Mar 23 '20 at 21:03
58

Lisp is the Chuck Norris of programming languages.

Lisp is the bar other languages are measured against.

Knowing Lisp demonstrates developer enlightenment.

I've heard of 3 weaknesses (and their counter-arguments):

  1. Dynamic typing.

    There's an argument for statically typed languages out there revolving around giving the compiler enough information to catch a certain class of errors so they don't happen at runtime. But you still need to test.

    This article argues for dynamic typing along with more testing: Strong Typing vs. Strong Testing.

  2. Hard to pick up.

    There are actually two parts to this: learning and tools.

    Lisp takes some effort to really "get", but it's worth it, because learning Lisp really will make you a better programmer in other languages. For instance, once you really "get" closures, you'll understand Java's inner classes. And once you "get" first-class functions, you'll be depressed every time you use a language without them.

    I've read The Little Schemer and am reading Practical Common Lisp, which are both excellent.

    Next are the tools. I'm on a Mac, so I've zeroed in on Aquamacs Emacs (makes Emacs livable for a novice) and Steel Bank Common Lisp (SBCL).

  3. Lack of libraries.

    I can't tell for sure yet, but I doubt it. For building web sites it looks like Hunchentoot and Elephant provide a good set of tools. But really I don't see Lispers complaining about the lack of libraries (maybe because Lisp is so powerful they just aren't needed?).

rickmode
  • 115
  • 2
  • 4
  • 4
    To address (3) - Have you looked at Clojure? – viksit Apr 21 '10 at 00:17
  • 5
    "But really I don't see Lispers complaining about the lack of libraries (maybe because Lisp is so powerful they just aren't needed?)." I would correct last statement to "(maybe because Lisp is so powerful they just aren't needed FOR THEM ?)" This makes a huge difference. – Agnius Vasiliauskas Dec 01 '10 at 22:41
  • 58
    Does not say a thing why lisp is great , downvote from me. – Kilon Dec 09 '11 at 13:38
  • 34
    Downvoted because "X is awesome! X is great! X is like Y, which is also great because I say it is great!" is not an answer to "Why is X regarded as great?". The political reference is also inappropriate and unhelpful (most people don't even think libertarianism is a good idea). The three points are helpful, but I wish they weren't "It has weakness A... But it's actually not even a weakness!". – Superbest Mar 10 '12 at 19:59
  • Dynamic typing isn't a fundamental part of Lisp, it's just an implementation deal. If you take a look at Typed Racket, you may be surprised at how well static types work with Lisp. (It does gradual typing beautifully.) – porglezomp Jun 17 '15 at 16:50
  • 6
    Lisp is the Chuck Norris of programming languages. so that's what makes it so good. Got it. Downvoted. – NiCk Newman Nov 10 '15 at 23:35
  • 1
    Downvoting for not giving reasons for why lisp is good. – Prathik Rajendran M Jan 05 '18 at 17:12
  • 1
    "Lisp is the Chuck Norris of programming languages" So that's what makes it so good. Got it. UPVOTED! – the chad Jan 09 '19 at 18:21
  • Closures are mainstream dude, ever heard of JavaScript or Python? Java and C# have them too and so does C++. We need to focus on homoiconicity, generic polymorphism, macros, and structural editing (allows you to edit the AST of your program rather than the text). Parinfer lets you edit Lisp code like it was Python or Haskell https://shaunlebron.github.io/parinfer/, and its much easier to learn than paredit IMO. – aoeu256 Aug 29 '19 at 14:18
26

"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."

Greenspun's Tenth Rule

Paolo
  • 22,188
  • 6
  • 42
  • 49
17

Here's some helpful links:

Greg Hewgill
  • 951,095
  • 183
  • 1,149
  • 1,285
  • 1
    On Lisp is great (I am just halfway through, although I admit the macros are getting a bit dense); but you need to know Lisp to read it. Apart from this little problem it's a great book not just about Lisp, but about software engineering in general. – J S Jan 12 '10 at 06:33
  • The "List - Reasons for Using" link is dead. – Adam Zerner Mar 11 '23 at 05:25
  • @AdamZerner: Fixed link. – Greg Hewgill Mar 12 '23 at 19:53
10

The first chapter of Peter Seibel's excellent Practical Common Lisp covers his reasons for liking Lisp. Bottom line is the phrase "programmable programming language" -- the ability to customise the language to your domain or preferred style.

itowlson
  • 73,686
  • 17
  • 161
  • 157
  • 1
    So basically one chooses to write DSLs to attack the problems. Doesnt this make code bases difficult to understand to newcomers? – lalala Feb 02 '22 at 09:26
  • 1
    @lalala Code is still abstracted into distinct components, appropriately named, commented etc. In a large enough non-Lisp codebase, you're already reading something similar to a DSL by way of needing to know all the data structures and function signatures involved to have any idea what is being communicated. DSLs generally exist to make simpler, more elegant/powerful interfaces. – iono Jul 13 '22 at 11:44
4

A Lisp program tends to provide a much clearer mapping between your ideas about how the program works and the code you actually write.

Source: http://www.gigamonkeys.com/book/introduction-why-lisp.html

ketan
  • 390
  • 3
  • 6