Ask HN: Why should we learn Lisp?
What did you achieve by learning Lisp? What insight about programming/life did you get out of Lisp?
14 comments
Learn it because you're curious about it. If you aren't curious about it, don't bother.
Some people learn it and it becomes important in their lives. I'm one of those. Others don't seem to get much out of it.
If you're someone who doesn't get much out of it, then you won't lose much if you don't learn it.
If, on the other hand, you're one of those that it can enrich, then you'll be missing out on a lot if you don't learn it.
There are a few ways that Lisp can be important.
One way is by being a small set of concepts with large ramifications. Alan Kay (the creator of Smalltalk) famously described it as "the Maxwell's Equations of software", meaning that the short page of pseudocode that defines Lisp also defines all of computation.
In case you want to know what short page he was talking about, it's a page from the Lisp 1.5 manual, which you can find here:
https://michaelnielsen.org/ddi/wp-content/uploads/2012/04/Li...
What Kay meant, as he has explained before, is that once you understand that page, you understand the foundations of computation, and can use them to build anything you need.
Realizing that all of computation is embodied in a small set of concepts that can be written down on less than one page and understood in a brief moment is an empowering realization. It means that there is a small toolkit that offers you unlimited expressive power. It means that a set of tools you can hold in your hands offers you the power to build worlds.
Another way Lisp can enrich you is by providing a programming system of unsurpassed flexibility and interactivity. Old-fashioned Lisps (and Smalltalks) are designed to redefine themselves as they run, enabling you to build up structures of arbitrary complexity by interacting with them, and to interrogate, comprehend, and modify those structures while they continue to run.
Different kinds of programming systems provide different levels of support for interactivity and livecoding. Old-fashioned Lisp and Smalltalk systems are at the extremely interactive end of the spectrum, and are worth learning just to see what that looks like. Not everyone prefers extremely interactive programming systems, but, again, if you're someone who does, then you'll be missing out if you don't experience what it's like to redefine some part of a running program and watch it adapt in real time to your new definitions.
Another way Lisp can enrich you is by illustrating what happens when you make it really really easy to manipulate code.
Most programming languages' source code is made of text strings. Lisp code isn't. Lisp code is made of s-expressions--that is, lists and atoms. Yes, you typically write it in the form of text strings, but the text strings are not Lisp code; they are one possible serialization of Lisp code. Others are possible.
(Historically, some Lisps have offered editors that bypass text strings and work directly on s-expressions in memory. One such editor is INTERLISP's S-Edit.)
When you give your text to Lisp, it starts by deserializing it into actual Lisp source code. Because the source code is made of lists and atoms, which are standard, first-class Lisp data structures, the source code is really really easy to operate on. You can walk its structure, take it apart, analyze it, put it back together, transform it, rewrite it, and so on, all using standard, built-in Lisp functions.
A C compiler does all of these sorts of things in the process of compiling C code, but it doesn't typically expose its internal data structures or the functions that operate on them to you, the programmer. Lisp uses standard, built-in data structures to represent its source code--data structures that are available to you as a user. It uses standard, built-in procedures to operate on the code--procedures that are part of the standard API of the language. Everything it uses to process and compile source code, you can use for your own purposes just as easily.
That circumstance makes it unusually easy to write a wide variety of coding tools in Lisp, including code walkers, analyzers, macro processors, editors, interpreters and compilers, optimizers, code-coverage tools, cross-referencers, and so on. It can be inspiring to work with rich Lisp development environments and see what people build when it's so easy to work with source code. It's one of the reasons that so many experiments in language design have emerged from Lisp. It's also a reason that Lisp programmers come to like the idiosyncratic parenthesized syntax that seems to unappealing at first. That syntax--those s-expressions--are part of what makes it so easy to work with Lisp code.
If your reaction is, "so what?" then Lisp may not be for you. If you're intrigued, then I recommend you learn more about Lisp. You might find that it enriches your life.
I'd say the main hazard is discovering that you really love it, and that it's relatively hard to find employers who will pay you to work with it all day. On the other hand, if you do happen to love Lisp, and you do find a job working with it, it's worth the wait.
Some people learn it and it becomes important in their lives. I'm one of those. Others don't seem to get much out of it.
If you're someone who doesn't get much out of it, then you won't lose much if you don't learn it.
If, on the other hand, you're one of those that it can enrich, then you'll be missing out on a lot if you don't learn it.
There are a few ways that Lisp can be important.
One way is by being a small set of concepts with large ramifications. Alan Kay (the creator of Smalltalk) famously described it as "the Maxwell's Equations of software", meaning that the short page of pseudocode that defines Lisp also defines all of computation.
In case you want to know what short page he was talking about, it's a page from the Lisp 1.5 manual, which you can find here:
https://michaelnielsen.org/ddi/wp-content/uploads/2012/04/Li...
What Kay meant, as he has explained before, is that once you understand that page, you understand the foundations of computation, and can use them to build anything you need.
Realizing that all of computation is embodied in a small set of concepts that can be written down on less than one page and understood in a brief moment is an empowering realization. It means that there is a small toolkit that offers you unlimited expressive power. It means that a set of tools you can hold in your hands offers you the power to build worlds.
Another way Lisp can enrich you is by providing a programming system of unsurpassed flexibility and interactivity. Old-fashioned Lisps (and Smalltalks) are designed to redefine themselves as they run, enabling you to build up structures of arbitrary complexity by interacting with them, and to interrogate, comprehend, and modify those structures while they continue to run.
Different kinds of programming systems provide different levels of support for interactivity and livecoding. Old-fashioned Lisp and Smalltalk systems are at the extremely interactive end of the spectrum, and are worth learning just to see what that looks like. Not everyone prefers extremely interactive programming systems, but, again, if you're someone who does, then you'll be missing out if you don't experience what it's like to redefine some part of a running program and watch it adapt in real time to your new definitions.
Another way Lisp can enrich you is by illustrating what happens when you make it really really easy to manipulate code.
Most programming languages' source code is made of text strings. Lisp code isn't. Lisp code is made of s-expressions--that is, lists and atoms. Yes, you typically write it in the form of text strings, but the text strings are not Lisp code; they are one possible serialization of Lisp code. Others are possible.
(Historically, some Lisps have offered editors that bypass text strings and work directly on s-expressions in memory. One such editor is INTERLISP's S-Edit.)
When you give your text to Lisp, it starts by deserializing it into actual Lisp source code. Because the source code is made of lists and atoms, which are standard, first-class Lisp data structures, the source code is really really easy to operate on. You can walk its structure, take it apart, analyze it, put it back together, transform it, rewrite it, and so on, all using standard, built-in Lisp functions.
A C compiler does all of these sorts of things in the process of compiling C code, but it doesn't typically expose its internal data structures or the functions that operate on them to you, the programmer. Lisp uses standard, built-in data structures to represent its source code--data structures that are available to you as a user. It uses standard, built-in procedures to operate on the code--procedures that are part of the standard API of the language. Everything it uses to process and compile source code, you can use for your own purposes just as easily.
That circumstance makes it unusually easy to write a wide variety of coding tools in Lisp, including code walkers, analyzers, macro processors, editors, interpreters and compilers, optimizers, code-coverage tools, cross-referencers, and so on. It can be inspiring to work with rich Lisp development environments and see what people build when it's so easy to work with source code. It's one of the reasons that so many experiments in language design have emerged from Lisp. It's also a reason that Lisp programmers come to like the idiosyncratic parenthesized syntax that seems to unappealing at first. That syntax--those s-expressions--are part of what makes it so easy to work with Lisp code.
If your reaction is, "so what?" then Lisp may not be for you. If you're intrigued, then I recommend you learn more about Lisp. You might find that it enriches your life.
I'd say the main hazard is discovering that you really love it, and that it's relatively hard to find employers who will pay you to work with it all day. On the other hand, if you do happen to love Lisp, and you do find a job working with it, it's worth the wait.
I'm a Lisp programmer amongst many other languages, but its quite sad that people quite often tend to say some anecdotal quotes from Graham or Raymond when this question is asked without really giving a good practical reason on why to learn this language. Truth is that you can do basically everything that Lisp can do in any other language only the clearness and conciseness on some things might change.
Best reason to learn it is just if you have some curiosity towards it, just go and learn it. Especially if Lisp might be something out of your comfort zone this could give lots of different ideas on your other work even though I might not use Lisp ever again. To me, Lisp tends to be my first go to language when I want to write something quickly and prototype something, which is mainly due to built-in interactivity in the language that allows this.
To me, what makes Lisp great is the fact how it generalizes the interaction between you and the machine. Basically everything that we as programmers do is to interact with data (programs being data for compilers), which Lisp makes almost indistinguishable from the code itself. This kind of approach with S-expressions makes data representation very easy and clean which the reduces your cognitive overhead since you don't need think about how the data is structured, since S-expressions itself provide an minimal syntax for it.
Best reason to learn it is just if you have some curiosity towards it, just go and learn it. Especially if Lisp might be something out of your comfort zone this could give lots of different ideas on your other work even though I might not use Lisp ever again. To me, Lisp tends to be my first go to language when I want to write something quickly and prototype something, which is mainly due to built-in interactivity in the language that allows this.
To me, what makes Lisp great is the fact how it generalizes the interaction between you and the machine. Basically everything that we as programmers do is to interact with data (programs being data for compilers), which Lisp makes almost indistinguishable from the code itself. This kind of approach with S-expressions makes data representation very easy and clean which the reduces your cognitive overhead since you don't need think about how the data is structured, since S-expressions itself provide an minimal syntax for it.
My closest encounter with LISP was a long project with Wolfram Mathematica. Can you elaborate which tooling and set of "standard libraries" you use? I'm doing day to day work in Python ("batteries included") and reall would like to make the switch.
Personally I come from Common Lisp world, so can't say much about other Lisps tooling. In CL I just mainly use couple of different implementations, whatever might suit for the job best. Mainly SBCL with some CCL and ECL thrown in there. Library-wise not much out of the ordinary. Either just built-in tools or maybe some usage of the most common libraries like alexandria (basic utils), cl-ppcre (regex), uiop (OS stuff), usocket (sockets), bordeaux-threads (threads), Closer-MOP (meta-object protocol) and some web tools like Clack with Hunchentoot or Woo etc. So nothing really out of the ordinary in CL.
The language spec of Common Lisp is pretty large (not necessarily a good thing) so the built-in libraries offer a lot so you don't necessarily need much third-party libraries. Issue with this along side the size of the spec is the fact that the spec is old, so it's missing some crucial stuff from it like threading etc. in which these third party libraries comes in handy.
The language spec of Common Lisp is pretty large (not necessarily a good thing) so the built-in libraries offer a lot so you don't necessarily need much third-party libraries. Issue with this along side the size of the spec is the fact that the spec is old, so it's missing some crucial stuff from it like threading etc. in which these third party libraries comes in handy.
"LISP is worth learning for a different reason — the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot." -- Eric S. Raymond
Completely agree! I learned LISP, but have never 'worked' in the LISP language. But the understanding of logic I gained has been a part of my foundational understanding when developing.
"Will Change The Way You Think About Computing."
> Have you read SICP? https://www.amazon.com/Structure-Interpretation-Computer-Pro...
> Have you read SICP? https://www.amazon.com/Structure-Interpretation-Computer-Pro...
To answer your questions, try one of these books (they're nearly identical):
https://mitpress.mit.edu/books/little-lisper-trade-edition
https://mitpress.mit.edu/books/little-schemer-fourth-edition
Exercises in recursion, not so easy to do in other languages, and they really expand your thinking.
https://mitpress.mit.edu/books/little-lisper-trade-edition
https://mitpress.mit.edu/books/little-schemer-fourth-edition
Exercises in recursion, not so easy to do in other languages, and they really expand your thinking.
By knowing Lisp/Scheme I found it easier to understand the core concepts in JavaScript. Brendan Eich set out to implement Scheme in the Netscape browser. Due to marketing and business management pressure he ended up creating a hybrid of Scheme and Self (a successor to Smalltalk) using a C-like syntax. Unfortunately, along the way JS lost the homomorphism feature of Lisp. That is partly the reason we have so many transpilers to JS.
I always say I write scheme because it's fun. Fun, like back when I discovered JS in 1999. I do it to keep my soul.
Some other languages also had this effect. F# and factor are the most notable. Guile scheme is the only one I use daily though.
Some other languages also had this effect. F# and factor are the most notable. Guile scheme is the only one I use daily though.
Eric Raymond and Paul Graham are more eloquent than I, so read this[0].
[0] http://www.paulgraham.com/avg.html
[0] http://www.paulgraham.com/avg.html
By learning Lisp, and staying involved in it, I got a better handle on almost every topic in computing, with a better framework for thinking about it, and coding about it.
If you can overcome the shame of having so few slocs to show for your
handiwork (as opposed to the hundreds of lines required in an
overwrought language like C++), then you can get on with life outside
programming.