Ask HN: I want to start learning Lisp. Where do I begin?
There are multiple versions of Lisp. Multiple compilers. What is a good one for someone new to pick?
I use VS Code and Vim. Are they suitable for learning Lisp?
I use VS Code and Vim. Are they suitable for learning Lisp?
The documentation for Racket is excellent, see e.g.
https://docs.racket-lang.org/quick/index.html
... and many people have created online resources to adapt SICP to Racket, as well as other learning texts. I like Beautiful Racket, e.g.
https://beautifulracket.com/explainer/lists.html
You can use #lang sicp and start playing around with the free online reformatted SICP text here:
http://sarabander.github.io/sicp/
I recommend getting a print copy of SICP, though, and working through the examples in a real DrRacket environment on your computer.
IMO, if you end up going deep in the "lispy" direction after playing with Racket, you'll probably be drawn to Clojure as it is the Lisp with the biggest "production use" community at the moment. So long as you can put up with some JVM warts, it, too, will be a good experience.
Clojure is Lisp!!! with some nice out of the box semantics like immutability.
(There's also trampoline for mutual recursion cases)
Even a little thing like (recur ...) could be a tiny amount of friction. But good to read, that the usual cases are apparently handled well in the language.
The trampoline pattern is an old trick that can also be imlemented in other languages to avoid stack consumption in mutually recursive calls.
That's unfortunate, that it is an additional function call, which needs to be explicitly written out. I'd guess such is necessary ultimately, because of limitations of the JVM and its limitations regarding recursion.
it comes with its own editor (Dr. Racket) that does some really helpful things for beginners, like hovering over a variable and seeing lines drawn to where it's being used.
It's not the fastest lisp, but that's ok. It's spectacular for learning and has a huge ecosystem too. My "daily driver" is Chicken Scheme, but i wouldn't recommend it to a beginner. The docs just aren't helpful to newbs (and frequently frustrating to me even though it has one of the better set of docs)
Vim is meh for Lisp & Scheme, and I'm a Vim fan. Emacs is great. If you're a Vim user check out Doom Emacs. It's great for us geeks who love vim but want more power and better lisp support. But... start with Dr. Racket for now.
Others have mentioned the SICP book, and it is good but i wouldn't suggest it as as "how to start with lisp" book. Also, watch the free lectures of the course from MIT. Very good, and make it way easier to work through the book.
https://github.com/Olical/conjure
It's written in a lisp, runs as lua and supports: Clojure, Fennel, Racket and Janet with a bunch more to come.
There is always spacemacs: https://www.spacemacs.org/
ClojureScript is great if you're drawn towards the "production use" side as pixelmonkey said and already have knowledge of the Javascript / Node ecosystem.
For me, I decided to start with Common Lisp. I installed SBCL, Slime for Emacs, and started working through the book Practical Common Lisp. By and large this seems to be a workable approach, but I will offer up this caveat. The PCL book is very much "project based" in that the author walks you through building a couple of actual applications. This is a Good Thing™ for the most part, but it does mean that you don't necessarily get things in the order you might expect.
There's a part of me that almost wishes I'd started with a book that takes more of an approach of "programming is ultimately sequence, selection and iteration. Here's how you do sequence in Lisp. Here's how you do selection. Here's how you do iteration. Now here's all the Fancy Lisp Stuff™".
The reason I say that, is because if you have at least the primitives for sequence, selection, and iteration (and maybe some I/O) in your mental toolbox, you can start building more or less arbitrary programs. With the PCL book structure you don't get to, for example, iteration, until moderately deep into the book. You do get there of course, but the early parts left me with an uneasy feeling like "geez, I don't even know how to write a loop in this language yet, when am I ever going to be able to just start coding in Lisp on my own?" if that makes sense.
Possibly one could complement PCL with another book, or online materials, but so far I've mostly just been grinding through PCL and haven't looked at any other Lisp books.
HTH.
> The PCL book is very much "project based" in that the author walks you through building a couple of actual applications. This is a Good Thing™ for the most part, but it does mean that you don't necessarily get things in the order you might expect. > > There's a part of me that almost wishes I'd started with a book that takes more of an approach of "programming is ultimately sequence, selection and iteration. Here's how you do sequence in Lisp. Here's how you do selection. Here's how you do iteration. Now here's all the Fancy Lisp Stuff™".
I feel like I'm in the minority in that I prefer to NOT learn things by just "diving in". I am much more successful when I start from the absolute fundamentals. There are objective pros and cons to either approach, but I suspect the success factor is based on one's personality (or some such).
If you start with the fundamentals, it's hard to know if you have any mastery until you try to do something "real". And then you might get frustrated because nobody taught you, e.g., how to do a network call in this programming language. It's also less rewarding because you can spend hours/days/weeks before actually "doing" anything.
If you start by diving in to a project, it's hard to know if you're doing things "the right way" or if you're just porting over bad habits from some other language you're familiar with. Sure, I got it to work, but is it good, or did I just cement in some bad habits?
The first time I drove a standard transmission car, I didn't stall it a single time. Because I read on the internet for a week about how car transmissions work and the difference between a manual and automatic gearbox. I do the same thing with programming languages. The first thing I want to know is what is the memory model approximately like (everything is a reference, values + references, are allocations cheap or expensive), what is the "philosophy" of the language (everything is an object, function composition is the blessed approach, mutability is bad, types are most/least important), etc. Then I want basic mechanisms: loops, iterators, lists or arrays, threads/futures/coroutines. Etc, etc.
That being said, SICP is kind of nice in that it finds an interesting middle ground where you're definitely learning details of the scheme language (applicative order vs normal order, recursion, etc) while it also feels like the details of the language is not the entire point.
No real point here. Just inspired by your comment and thought I'd share my own experience.
A bit more off-topic, but this resonated with me. I too feel more comfortable when I start with the absolute fundamentals. When something does not work, knowing the fundamentals helps me to reason about why it does not work from the first principles. On similar lines, I did a relevant "Show HN" post here today:
Emacs4CL: https://github.com/susam/emacs4cl (35 lines of ~/.emacs to turn Emacs into Common Lisp dev environment)
It bothers me a little when someone new to Common Lisp or Emacs is encouraged to start off with Portacle or Spacemacs directly without appreciating the extensibility of Emacs and how SLIME fits in the environment. The Show HN post on Emacs4CL I have linked to above is an attempt to promote a more DIY approach to setting up one's development environment for Common Lisp without having to spend a lot of time.
Though, to be fair, if someone says they want to learn LISP and then you tell them to learn Emacs... well, now they have TWO problems! xD
I love and use Emacs. And I also, unsurprisingly, don't like or recommend that people start off with all of these "starter packs".
But at the same time, if you don't already know Emacs and you want to learn LISP, I don't know what I'd recommend.
Here is my attempt to make it easier to get started with vanilla Emacs + SLIME + SBCL without hiding the underlying details like a starter pack does: https://news.ycombinator.com/item?id=25440690
Also, if you are used to the Jetbrains tools like IntelliJ, try the Cursive IDE (paid).
The instructions in your link were fantastic and easy. Thanks a lot for this !!
Indeed the intention behind the .emacs and detailed documentation for it was to make it easy for beginners to set up a Common Lisp development environment with Emacs and SLIME quickly while understanding every step of the setup process. I am glad you like it!
I definitely find value in the project based approach, but I guess I'd say that I tend to want just a little bit more "here's the fundamentals" first, before transitioning into that mode. As a generalization. But Programming Common Lisp isn't bad for this reason, it's just a hair short of what I personally might consider "the perfect Lisp book" if I could imagine up such a thing.
With Lisp you can better think in terms of abstractions. In particular how do you do data abstraction, how do you do functional abstraction (that's the control flow: sequencing selection and iteration) and how do you do syntactic abstraction?
That last one is where Lisp (any Lisp) really comes into its own. It's where you go beyond the expressiveness of those other programming languages. Whether you go with defmacro or define-syntax, it opens up a whole other world.
And the expressiveness here isn't meant to suggest that you can write programs that you can't in other languages (they're all Turing complete) but that you can write new kinds of control flow and scoping constructs so you're not limited to the sequencing selection and iteration that the language provides.
That's all great... once you already know how to use the language. But, at least relative to the way I think and learn, I really want to quickly be able to do three or four things when learning a new language: sequence, selection, iteration, and console I/O. Once I can do that, I can write essentially any arbitrary program. And then I can start adding onto my knowledge and learning the more interesting ways of doing things.
Maybe I'd have a different perspective if I'd learned Lisp first, instead of having 20+ years of programming in Algol derived languages under my belt first. But I do feel uncomfortable spending days and weeks with a language and not even learning how do use (their version of) a for loop or whatever.
I found a very good complement was Edi Weitz' "Common Lisp Recipes" from same the publisher.
This is exactly the approach I took (~15 years ago) when I went all-in on Lisp for a few years. Don't know if it is still the best today, but it was a solid approach at the time.
With that, you're ready to go. Take just one book and work through it, you don't need the best book, but a book will be better structured and more complete than multiple blog posts from different people. Practical Common Lisp (http://www.gigamonkeys.com/book/) is good and freely available. I used ANSI Common Lisp (http://www.paulgraham.com/acl.html), from Paul Graham (https://news.ycombinator.com/user?id=pg), long time ago and it's also good.
If you are open to non-common-lisp lisps, I'd say pick up clojure instead of common lisp, it's more modern and thus you will find more community and up-to-date resources. Clojure for the Brave and True is a book that has been praised, but I did not read it. It has some jokes and humorous examples that might or might not suit you.
https://marketplace.visualstudio.com/items?itemName=rheller....
I meant any lisp. Common lisp, clojure, ccl. I am new to this so did not have a choice. But in this thread I get the feeling that common lisp is the most suggested.
Make sure your editor has parinfer available. Not parindent, parinfer. People swear by parindent, but you don't need it on day one. Just try it later on. Parinfer is your friend.
Are you new to functional programming and have heard that's the parent language? Do you know a statically typed functional language and want to learn a dynamically typed? Are you looking for something practical you can interop easily with other languages with? Are you looking for a good language to follow SICP with? Do you already know scheme but want to learn a true lisp?
Depending on the reason why there are lots of different recommendations. For example If you know Java, and want a more practical language with modern library support from the lisp family someone may actually say Clojure is the best choice for you. But if you know scheme and are wanting to learn an actual lisp, then that wouldn't match your needs.
Always be wary of people telling you what you should do without them knowing why you want to do it. Not because they don't mean well, but because the only way they can answer is by projecting their own reason "why" onto you - which in most cases isn't applicable.
If the author wants to use Lisp because he/she thinks metaprogramming is interesting, or has read about interact
If the author wants to use Lisp because he/she thinks metaprogramming is interesting, or has read about the benefits of interactive programming, Common Lisp is the choice here.
If the author wants to use Lisp as a way to get a deeper understanding of important computer science topics, I think Scheme is the best choice and with this, following the SICP book.
If the author is interested specifically in functional programming and wants to get easy employment doing it, he/she should take a look at Clojure, Ocaml, and F#.
Like there are many Lisps, there are many Vims. Spacemacs is a Vim for Emacs or inside Emacs: https://www.spacemacs.org/
It's quite powerful. And it can be argued that Emacs is highly extensible - because it's written in a Lisp. Looking under the hood and hacking on the editor is a lot of fun and very informative. And also horrible and bad. But in a good way!
And almost completely unrelated: I very much enjoy the Structure and Interpretation of Computer Programs book and online lectures: https://ocw.mit.edu/courses/electrical-engineering-and-compu...
The video lectures were recorded in 1986!: https://ocw.mit.edu/courses/electrical-engineering-and-compu...
And they're still amazing.
(But people all think very differently and what works for me may not be your cup of tea!)
If "functional programming for the enterprise" sounds good to you, read Clojure for the Brave and True.
If you're more interested in a truly mature language with a more academic community, read Land of Lisp.
If you're looking for a simple language that's easy to learn, or if metaprogramming is really your jam, read Realm of Racket.
As far as editors go, just start with whichever one you personally like best. They're all fine. I wouldn't bother spending much time worrying about that until after you've confirmed you want to stick with it.
So you should ask yourself what your use for Lisp is. If it's just for fun, I'd go with the simplest.
Emacs seems the best choice for Lisp, since it is scripted in Lisp and it's best adapted to it probably. However when I started, I was already so used to vim that I kept going with it. Maybe not the best option, but it's ok, maybe just a little bit more effort to automatize some stuff.
If you choose Common Lisp, this is probably the best book for start: http://www.gigamonkeys.com/book/ . Anyway be prepared, Lisp is not easy to grasp at first, but as soon you do, you will probably love it and appreciate way it is. :)
Note that getting started with Emacs, Lisp, SBCL, Quicklisp and Git is possible in 3 clics thanks to Portacle (http://portacle.github.io/)
just to point out i believe 'functional' here means 'has lots of functionality' not 'more suited to functional programming' - in that regard scheme (and racket) are more 'functional' than CL
https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/
That's the best article I know on the matter.
ClojureScript (cljs) (and Clojure) I would recommend as practical, but simple and approachable dialects.
Scheme is a good, simple dialect to learn if you’re just looking to grok lisp in “maxwell’s equations” elegance (but not work in it). Not nearly as many libraries written for it as Common Lisp has, or Clojure with JVM interop, or CLJS with javascript+node interop).
Whether you use Scheme or cljs (or another~), I recommend SICP[2] “Structure and Interpretation of Computer Programs”, free online from MIT press. There’s even an interactive, editable version online [3] (though it doesn’t support saving reader code)
[1]: http://www.paulgraham.com/lisp.html
[2]: https://mitpress.mit.edu/sites/default/files/sicp/index.html
https://mitpress.mit.edu/books/little-schemer-fourth-edition
https://mitpress.mit.edu/books/seasoned-schemer-second-editi...
https://mitpress.mit.edu/books/reasoned-schemer-second-editi...
They’re written in a Socratic way, as a series of questions and answers. A good way to learn is to follow along and answer them yourself using Racket (before turning the page and seeing the answer). Racket is quick and easy to setup and use:
Common Lisp is multi-paradigm language that is pretty bendy with regard to absorbing new ways of doing programming. It gets actual work done as well.
In Clojure, how do you usually approach problems that are shaped in an object-oriented way? In object-oriented languages, this usually includes either some sort of method calls (and therefore mutable state) or message passing (which usually involves actors, like Erlang processes). Passing all state around as function arguments is one way, but it becomes somewhat tedious as state grows large.
(let [temp (atom 0)]
(defn getter [] @temp)
(defn setter [val] (reset! temp val)))
(defn new-object [init-val]
(let [temp (atom init-val)]
{:getter (fn [] @temp)
:setter (fn [val] (reset! temp val))}))
(def obj (new-object 0))
((:setter obj) 12)
But obviously all this is not very idiomatic; in clojure you would keep those functions first-class through defn instead of tying them to the object / map, and would pass state as an argument. Something like:
(defn getter [obj] @obj)
(defn setter [obj val] (reset! obj val))
(def obj (atom 0)) ; This gives you the ability (and need)
; to explicitly track the list of
; existing objects in use lest they are garbage collected.
(setter obj 12)
As it was said in the previous post, it's equivalent. It's a matter of how to organize code.
Thanks, TIL! That's equivalent to the "mostly functional" style that's doable in Common Lisp.
(and also obviously functions that map that state to HTML/CSS/SVG/etc.).
Clojure does have constructs to manage state. You don't need to shove it all into your function arguments.
Then you would need to have ways to mutate variables, so you'd need to stop using Clojure's persistent collections and instead use the ones provided by the JVM.
Overall, you can do it if you want to, it is just somewhat painful to do so and the language will fight you. This is like my who tried to write functional Python which is possible but then it is just a much worse Clojure.
(nota bene: I understand these things are hard to solve and I don't mean to throw the stone without putting my own time on the line to fix it, but that's one reason I'm not using VS code for clojure. Doom emacs with cider is still better, even if not perfect). If people know of someone I could throw money at to solve the integration for VS code, I'd be happy to do that.
If you find a good/great experience for clojure with vim keybindings, I'm all ears.
[1] https://calva.io/ [2] https://github.com/borkdude/clj-kondo/blob/master/doc/editor...
Another issue has to do with startup time. The Clojure application bootstrap process is relatively slow, i.e. start-up might take 1 second, so it's great for server applications, but less great for Android apps or other CLI scripts that expect require instant startup. It has been approached in different ways, e.g. compiling Clojure with Graalvm native image or using ClojureScript instead of JVM Clojure. The latest solution is Babashka which provides a variant of Clojure specifically for writing CLI scripts.
Otherwise, Clojure is an excellent language which both modernises Lisp syntax significantly and implements a very well thought out standard library for doing functional programming. There are many great features, but the standout ones are probably the persistent data structures (which syntactically act both as data structures and functions) and parallelism/concurrency support. It's also very natural to do interop with the host platforms (Java, JS, .NET) and the data-oriented style of programming makes communication between backend (Clojure) and frontend (ClojureScript) extremely simple. So it's pretty much the perfect full-stack language for information systems. I would take a look at the rationale: https://clojure.org/about/rationale
Absolutely everything mentioned above in this quote is available in Common Lisp as well by just loading the needed libraries.
>Another issue has to do with startup time. The Clojure application bootstrap process is relatively slow, i.e. start-up might take 1 second,
>The main issue with Clojure is probably its tight integration with the various host platforms. When you get a stack trace in Clojure/ClojureScript, you basically get a Java or JavaScript stack trace, so there is some expectation of familiarity with the host platform.
Correct. And there are no such problems in Common Lisp. Except if you want to execute CL in a JVM, in which case the available implementation, ABCL, does take a slow time to start. Otherwise it's a great implementation.
https://insideclojure.org/2018/05/04/add-lib/
Some of Clojure's other runtimes perform a bit better, Babashka, CLJS, CLR, GraalVM for different trade offs if you need something like a scripting language or native images etc
I'm sure CL is still quicker but there are options
I use Common Lisp and my main argument will be that Clojure isn't an "interactive programming" language like Common Lisp, Smalltalk (and Pharo, Squeak, Scratch) are. And, for me, this is removing one of the main, core advantages of Lisp.
Dispensing with the interactive programming features is, IMO, a step backwards in the state-of-the-art. Common Lisp ADDED all the improvements in the state of the art: Interactive programming from Smalltalk, lexical scoping from Scheme, various high performance/low level features from StarLisp and ZetaLisp, a very powerful OOP system, etc. And then, thanks to it being highly extensive, almost any feature can be added to it.
Clojure features like threading macros, immutable seqences, software transactional memory, and others, are already available in Common Lisp by just importing (loading) the respective library.
One of Clojure's main advantage is to be able to call Java libraries. But, surprise, you can do this in Common Lisp too, easily, by using the Armed Bear Common Lisp (ABCL) implementation. Which runs on the JVM too and makes the process of calling Java libs really, really easy. I have made a working example here, calling all the Swing UI library (java) from lisp:
https://github.com/defunkydrummer/abcl-jazz
It's true that Clojure has more widespread adoption in the industry and more libraries. However the library ecosystem on Common Lisp is decent.
>and you can get actual work done in it which is an advantage over some of the other options
This implies you can't do "actual work" in, for example, Common lisp. Which is not true, since there are companies that, in this very moment, are doing well paid, critical commercial work using Common Lisp.
But Common Lisp features like the condition system are already available in Clojure by just requiring (loading) the respective library. :)
As an example, see https://github.com/clojureman/special . Nice thing about this repo is that it points to other options re. conditions with pros and cons of each one.
Now that I think of it, you might also be referring to the fact that Common Lisp can load libraries through the REPL. Clojure can also do this through an alpha feature, add-lib, that you can already require in any project.
- Able to easily modify (and recompile) a function while your code is running
- Able to redefine a class and then change existing instances so they use the new class definition
- Able to sabe the complete running state of the system (the "image" of the system, including state of all variables, data, loaded libraries, compiled functions, etc) into a file so it can be restarted later, just like Smalltalk does.
- Able to inspect any stack frame at will and to restart execution from any chosen stack frame
These are just a few of the feature that Common Lisp has and that are part of what an "interactive language" is. Common Lisp brings all these features, they work seamlessly, without any sweat, working reliably and efficiently.
I do this all the time with Clojure at work. I will have my application running (web app) with two repls in emacs. One is connected to the ClojureScript repl and one to the Clojure repl. I am able to make changes to both front end code and back end code on the fly by changing a function and then evaluating the function into the repl. I can start the application when I get in to work in the morning and have it going all day a while I'm doing my work.
> Able to sabe the complete running state of the system (the "image" of the system, including state of all variables, data, loaded libraries, compiled functions, etc) into a file so it can be restarted later, just like Smalltalk does.
> - Able to inspect any stack frame at will and to restart execution from any chosen stack frame
Those are really cool features, are they in the base language or are they libraries that you would need to include?
If I may ask, are you using Common Lisp professionally? If so, what kinds of applications do you use it for? I've had this notion, as many others seem to have in this thread, that you don't really do anything professional with CL but I realize it is just ignorance on my part.
But since you can't arbitrarily inspect and restart any start frame, you don't really get the interactive programming experience.
On CL, for example, when you hit a runtime bug that is uncaught, you get the debugger window which shows not just the "stack trace" but the complete stack FRAMES that you can inspect. So let's say deep down you find where the error originated and the states of the variables.
You can then jump to the definition of the offending function, edit the function, recompile it, (optionally) change any variable on that stackframe, and then continue the execution by restarting specifically at that stack frame.
In this way, the feature of "modify a function while the code is running" becomes way more meaningful. The program evolves as it runs, as if it were a lifeform.
Once you have the basics down then look into setting up slime and jumping down the emacs rabbit hole.
For Common Lisp, SBCL [1] is probably the best free option. If you want to learn Scheme instead, Chicken Scheme [2] and Racket [3] are popular and good choices.
[1]: http://www.sbcl.org/
[2]: https://call-cc.org/
Once you think you grok it, you can pick a Lisp that's closest to what other tools and frameworks you're used to. For me, I never actually did anything in Lisp for production use, but learned a lot from playing with various flavors of it.
I'm not sure about that. You need an editor that automatically matches parens and other paired delimiters and keeps them balanced, like paredit.
I suppose one suggestion I might make is to take a look at Janet after you have a chance to do some reading on lisp. It is practical and multi-paradigm like Common Lisp but adopts syntax similar to Clojure. Plus it comes in a small package and the docs for the core library are really nice.
-ANSI Common Lisp by Paul Graham -On Lisp by Paul Graham -Simply Scheme -The Little Schemer -Structure And Interpretation Of Computer Programs -Paradigms of Artificial Intelligence Programming
Implementations
Common Lisp - any should be fine, I’ve used sbcl and clisp
Scheme - I like gambit scheme. It has a macro system that can be used like described in “On Lisp”
He wrote two books on Common Lisp and has his own Lisp reading list: http://www.paulgraham.com/booklinks.html. There's also, one level higher, a set of lisp links: http://www.paulgraham.com/lisplinks.html
https://michaelnielsen.org/ddi/lisp-as-the-maxwells-equation...
Its on the more academic side and focuses on the Scheme dialect, but is well-written
That being said you might have no desire to leap at all - Clojure is a powerful language with a great ecosystem (especially if you rope in Java interop)
[1] https://mitpress.mit.edu/sites/default/files/sicp/index.html
[2] https://htdp.org
I only know Emacs well. Checked out VS code for Clojure a while ago and it wasn't even close. Clojure IDE "Cursive" is supposed to be good, but never tried and not sure if you want to invest time in an ad hoc IDE. It seems to me lispers don't want to discourage people by recommending Emacs, but at the end of the day, most people who stick with it tend to be Emacs users.
Cursive is just a Clojure plugin for IntelliJ , nothing ad-hoc about it. IntelliJ is the favourite IDE for lots of people - especially Java devs - so it's an obvious choice for Clojure developers.
I've programmed Clojure professionally for several years now and have seen maybe 50 different editor setups in person and I've yet to be significantly impressed by emacs. It does seem to offer most of the stuff that comes out of the box in IntelliJ (with the Cursive plugin), but only after many hours of setup and days to weeks of getting comfortable inside its somewhat antiquated UI paradigm. Nothing against emacs, but I just haven't seen the great case for using it over something like Cursive, other than if you need to develop commercial software and don't wanna buy a commercial licence for Cursive. A bunch of people at my old job actually switched from emacs to IntelliJ a couple of years into their Clojure journey.
I do see the obvious advantage of using emacs if you're already a heavy emacs user, however. And if some Clojure-specific kiler feature pops up in emacs, I'll probably switch to emacs too. Until then, I'll stick to Cursive which covers all of my various Clojure needs very well out of the box.
Well, I'm ignorant about the IntelliJ ecosystem. Can I take some of what Cursive is providing and use it with Racket or Common Lisp?
If you would like to learn on line (maybe using pdf book) you can try my Scheme REPL bookmarklet https://lips.js.org/#bookmark so you don't need to install anything on your computer, you can do that later.
https://ia800700.us.archive.org/33/items/sketchy-lisp/sketch...
Edit: I meant ANSI Common Lisp. Thanks everyone!
(I wouldn't even recommend On Lisp as a second text, too much macrology).
1. Emacs is a hurdle, but one that's worth it when you use SLIME.
2. I went through Barski's "Land of Lisp" and enjoyed it, but couldn't get the web server to work, so I tweaked it to use Hunchentoot[0]
https://web.archive.org/web/20180113072302/http://landoflisp...
The whole issue of "flavors" largely comes down to one concept: Do you like the idea of functions and variables being in the same namespace (that's called a Lisp 1 like Scheme) or different (a Lisp 2 like CL). If you don't care, it doesn't matter which you pick.
If you're going to extend your Lisp app into production, you might want some of the many libraries that are available for CL. These cover just about every known topic and algorithm in comp sci and they're old and proven and just work everywhere, so that can be a benefit as you move to a non-trial app.
If you're going to distribute something written in Lisp (like an executable), then the flavor and implementation you pick will need to work all the way down your distribution path, and that can be challenging to get setup. One proven path is SBCL + Node.js + Electron to wrap your app for all three platforms.
Hope you love Lisp and get great things out of it!
I've lately had some success using vanilla emacs, Geiser and Guile (or MIT) Scheme. If you want to work through sicp, the little schemer [1], or my current favorite "Essentials of Programming Languages"[2], then that's the perfect setup. Racket will work too, but if you're using emacs anyway then it's just as easy to get going with Guile or MIT.
I'd recommend getting familiar with largely vanilla emacs[0] rather than a curated kit, but it will require a little bit of additional investment. Additionally, you'll be getting acquainted with emacs-lisp (elisp), so you'll be swimming in lisp languages.
I'm not a fan of VS Code and only use it for work when I have to (and then only when I can't use vim). I'm sure it'd work, vim too, but there are an awful lot of emacs/lisp resources out there and it's helpful to take advantage of what's available.
[1] https://www.amazon.com/Little-Schemer-Daniel-P-Friedman/dp/0...
[2] https://www.amazon.com/Essentials-Programming-Languages-Dani...
If you want build it as a tool, I’d recommend Clojure.
I’ll be happy to teach if you’re interested
https://github.com/jpalardy/vim-slime
Here's a few previews for fun books I enjoyed, land of lisp and realm of racket by conrad barski
https://books.google.ca/books/about/Realm_of_Racket.html?id=...
https://books.google.ca/books?id=9apQfCRhvm0C&printsec=front...
Then you're using emacs. Play around with emacs lisp customizing it and writing utilities for yourself to do editing tasks and whatever else you can think of. The community of emacs lisp programmers has lots of common lisp programmers. It's a serious-enough lisp to get started with, with sophisticated macros and several features from common lisp.
Make sure you use paredit. It's basically essential when learning lisp to use an editor that automatically matches parens and keeps them balanced. Beginners who complain about the parens are making that mistake.
Some people will argue that Clojure isn't a real LISP, which is fine. They're probably right. But it's an elegant and well-designed language that has a lot of the same features and feeling of a LISP/Scheme.
I know I could be burned alive for saying it, but Common Lisp is pretty ugly, IMO. It's "pragmatic" and has a bunch of libraries and functionality and whatnot, but it's not as fun or elegant as a minimal, pure, Scheme.
The Lisp that I eventually got into is Clojure. If you're familiar with either Java or JavaScript then that's what I'd advise looking at. The language itself is well designed and elegant and if you understand the platform that it's running on (JVM or JavaScript depending on which variant of Clojure you're using) then that's very helpful. For me, being able to add a dependency on basically any Java library and use it without too much hassle is brilliant but I'd still love the language even if that wasn't the case.
I mean, Common Lisp is perfectly fine. And if you want to use it to write real apps, it's a good choice. Especially if you will have dependencies to manage (see quicklisp).
There's just a few little things that I don't like as much about it.
There's a holy war about "lisp-1 vs lisp-2 (or lisp-n, really)". Not much point in debating that, but scheme is a lisp-1 and CL is a lisp-2.
I like that schemes tend to use #f for false and #t for true, whereas CL just uses nil for false, and for empty-list, and anything else for true (which is usually the symbol t in practice).
I like the way things are named more in Schemes: map vs. mapcar, number? vs. numberp, etc.
I like that the Scheme standards guarantee tail-call-optimization. I believe all popular CL implementations do implement it, but it's not required by the standard.
CL has the ugly loop macro, and Schemes emphasize recursion more (also has `do`, though).
Schemes have "hygienic macros" which I like much more than unhygienic macros.
These things mostly don't matter, honestly. It's all bikeshedding. Lisps and Schemes are very very similar and also very different than most other languages. You can't go wrong with either.
Common Lisp grew by accretion over a fairly long span of time. Consequently, it has varying conventions, inconsistent ways of working, and a whole lot of TMTOWTDI going on.
That said, perhaps we should be careful what kind of house we're in before throwing stones. Exactly the same accusation could be leveled against Java, Python, C++, and Haskell.
I mean, if Common Lisp is ugly what are Perl and C++ then.
In general you can use any editor, but there are some features which your editor should have to make your life easier. I wrote a blog post about it some time ago: https://klibert.pl/posts/tools_for_lisp_syntax.html
Basically, syntax highlighting, automatic matching paren insertion, ability to jump to a matching paren are the baseline. If you can get those with a plugin to VSCode or Vim, you're good to go.
Does anyone know if there's a mirror somewhere? I'd gladly host this in a droplet and make it public if someone has the source.
[0] https://cons.io/
VSCode will be fine for editing Lisp, there's a good syntax highlighter extension too.
https://htdp.org/2020-8-1/Book/index.html
It's a good introduction to programming in general and uses a series of "student language" dialects of Racket, which is in the Scheme/Lisp family.
I am seriously thinking of learnijg common lisp. Thank you for all the suggestions.
Is it possible to build web apps in common lisp or any lisp? Any frameworks available?
Is it possible to build multithreaded apps that use multiple CPU cores for performance? What is used? POSIX threads?
The Cookbook on web development: https://lispcookbook.github.io/cl-cookbook/web.html
In this way, we use Lisp for what it's good at and use HTML/JS to make a modern front end.
That's the most extended option by far, but I'm sure that you will find other lisps that compile to javascript (not that I know them).
> Is it possible to build web apps in common lisp or any lisp? Any frameworks available?
Clojure would be good because it has lots of users. Many web apps in production. It might be good to start out with luminus for Clojure, but maybe even before that, try to get a simple Ring and Compojure thing going where you can send a request and get feedback.
> Is it possible to build multithreaded apps that use multiple CPU cores for performance? What is used? POSIX threads?
Clojure is awesome for multi-threading. That's one reason Clojure is functional/immutable by default.
Also, you get access to many libraries in the language hosts (Java, Javascript). That could be a big reason for its success.
Good luck in your pursuit!
Yes, many.
>Is it possible to build multithreaded apps that use multiple CPU cores for performance? What is used? POSIX threads?
Yes, threads, there's many libraries also for channels, software transactional memory, etc.
Better install Portacle, that's the only thing you need to install to edit, compile, and debug Common Lisp code.
Then you can learn by reading a good book like a "Gentle introduction to Symbolic Computation" or "Practical Common Lisp".
I found it super helpful understanding everything there is about Lisp, and you can move from there.
pgloader was rewritten from Python to Lisp: https://tapoueh.org/blog/2014/05/why-is-pgloader-so-much-fas... because of Python's poor performances and threading capacities.
A theorem prover used in the industry: https://github.com/acl2/acl2
A Lisp vendor selling semantic graph solutions: https://franz.com/ (see also its success stories for industry examples)
Here's a sadder story: a team switched from CL to Go for production, but still use CL for prototyping: https://lisp-journey.gitlab.io/blog/pro-mailing-list-on-comm...
Some use CL in bioinformatics (and claim it's the best tool for the job). For example, they create a new Lisp implementation: https://github.com/clasp-developers/clasp
More success stories: https://lisp-lang.org/success/
- Choose Common Lisp because it has been the most popular dialect of Lisp in the overall history of Lisp. It is more convenient than Scheme if one decides to develop serious software in Lisp. Clojure appears to be more popular in the technology industry than Common Lisp among organizations (my workplace included) that use Lisp. I still recommend Common Lisp because I believe that it is more likely that one would work on an independent open source or hobby Lisp project than one would encounter one of the rare organizations who use Clojure at work.
- Choose SBCL (Steel Bank Common Lisp) as the implementation.[1][2] It is the most popular[3] Common Lisp implementation and is recommended in many online discussions. CCL (Clozure CL, not to be confused with Clojure which is a separate dialect) is also another very good implementation.
- Work through this book: Practical Common Lisp: http://www.gigamonkeys.com/book/ (available in print too if you search online). Just use a modern alternative to Lisp in a box when you reach Chapter 2. In fact, I encourage using vanilla Emacs and setting it up with SLIME and Paredit yourself. See Emacs4CL for example.[4]
- A Vim user may consider installing Slimv or Vlime[5]. Slimv and Vlime offer an environment similar to Emacs/SLIME. They display the REPL in a Vim buffer. Slimv also comes with Paredit mode that makes typing and executing S-expressions quite convenient.
- In case you want to postpone setting up Emacs + SLIME or Vim + Slimv/Vlime until a time you have become more familiar with the language, you can also execute your Lisp source code files from the shell.[6]
- Optionally, keep another implementation of Common Lisp. Common Lisp is a standard that is implemented by various implementations. Each implementation may have its own extensions or implementation-specific behaviour regarding error handling, command line options, FASL format, unspecified behaviour, etc. Experimenting with concepts with another implementation of Lisp occasionally may offer some perspective about how some things could be different in different implementations. I keep CLISP around for this purpose.[7][8]
[1]: Install SBCL on macOS: brew install sbcl
[2]: Install SBCL on Debian-based distro: apt-get install sbcl
[3]: State of Common Lisp Survey 2020: https://docs.google.com/forms/d/e/1FAIpQLSfg7UJRKrkI3OjOHWL4...
[4]: Emacs4CL: https://github.com/susam/emacs4cl
[5]: Lisp in Vim with Slimv or Vlime: https://susam.in/blog/lisp-in-vim-with-slimv-or-vlime/
[6]: Load (execute) code in a file and exit: sbcl --script foo.lisp
[7]: Install CLISP on macOS: brew install clisp
[8]: Install CLISP on Debian-based distro: apt-get install clisp
Disclosure: I am the author of [4] and [5].
You're going to need an editor to write long-form programs. Vim and Visual Studio Code are fine, but the ne plus ultra of Lisp editors is Emacs ( https://www.gnu.org/software/emacs ). Emacs comes with an excellent Vim-emulation mode, so if you cannot leave behind your vi muscle memory, that's always available to you. Another feature of Emacs is, it contains, and much of it is written in, its own dialect of Lisp! The upshot of this is you can usefully extend and customize your editor by evaluating a few Lisp expressions. Playing with Emacs Lisp is a great way to learn how to use the language to do "real work" during your experimentation. Emacs has a package available called SLIME, which allows it to talk to a standalone Lisp environment such as SBCL, send it expressions to evaluate, and get results. SLIME also has LSP-like features to show documentation on the Lisp functions you've defined. Vim and Visual Studio Code can speak SLIME's protocol with the proper add-ons, but the integration is not as tight as with Emacs.
If Lisp seems overwhelming, it's because it's more of an idea than a specific language. There are three varieties of Lisp you should be aware of. Well, four if you count Emacs Lisp, but the standalone ones are:
* Common Lisp
* Scheme
* Clojure
Of these, the best place to start is probably Common Lisp. It is a comprehensive language which has been used in real-world software engineering projects since the 1980s, and it has a very strong community surrounding it. There are a few implementations, both open source and proprietary. The most favored one today is SBCL: https://www.sbcl.org
Scheme is much simpler. It is more of a language core used for teaching, and for providing a basis for a more feature-rich programming language. There are many implementations, most of which provide their own extensions to the core language; my favorite for getting work done in a Unix-like environment is GNU Guile: https://www.gnu.org/software/guile
Clojure is a language that is designed to interoperate well with the JVM, and to promote Rich Hickey's ideas on functional programming. It is a very opinionated language, more so than the other two, and you may find yourself struggling more if you don't do things the Clojure way. Personally, I like it less than the other two, but that's a matter of taste and you may find it more useful.
Over time I hope you will have the opportunity to try all three. Each has something different to offer and each can be learned from.
If you install `clojure` you can start the interpreter with `clj` and also type in similar expressions, like:
(* 3 7)
The fun thing about Lisp is that you can pass any number of parameters to functions, like "+", so that expressions like this also works fine:
(* 1 2 3 4 5 6 7)
A fundamental concept in Lisp is to get the first element of a list (the head) or the rest of the elements (the tail). For historical reasons the head is called CAR and the tail is called CDR in lisp. Everyone has just accepted that this is the way of Common Lisp by now. In Clojure, "first" and "rest" are used instead of CAR and CDR, as the heathens they are.
Since regular for loops are for wimps and snowflakes, iterating in traditional Lisp mainly centers around how to do the same thing using CAR, CDR and recursion.
Before we can do that, let's define a function that adds 2 to the given number:
(defun addtwo (x) (+ x 2))
If you type it into "lispi" you can use the function afterwards, and get the result 42:
(addtwo 40)
(cons 1 ())
(cons 1 '())
(cons 1 nil)
Creating a function that takes apart a list into a head and a tail and then combines them again can be done like this:
(defun combine (xs) (cons (car xs) (cdr xs)))
The combine function can be called like this:
(combine '(1 2 3))
(1 2 3)
(defun hello ()
(write-line "Hello, World!"))
lisp main.lsp hello
Now to create a for-loop replacement in Common Lisp, for people with hair under their arms, using CAR and CDR and recursion. This program will print each number in the given list, with an axe emoji after each number (HN removed it, please insert an appropriate unicode emoji instead of the x):
(defun lumberprint (n)
(write n)
(write-line "x"))
(defun f (xs)
(unless (null xs)
(lumberprint (car xs))
(f (cdr xs))))
(defun main ()
(f '(1 2 3)))
"unless" takes a condition and a list of statements. "null" checks if a list is empty. "write" outputs the given argument, but not a newline. "write-line" outputs the given argument and also a newline.
This should be enough to get you started. Then read SICP and draw the rest of the owl.
Best of luck!
lisp:
#!/bin/sh
#
# SBCL wrapper script
#
filename="$1"
mainfunction="${2:-main}"
if [ -z $filename ]; then
echo 'Please provide a filename as the first argument'
exit 1
fi
if [ ! -f $filename ]; then
echo "Could not find the file named \"$filename\""
exit 1
fi
sbcl_path=$(which sbcl)
if [ -z $sbcl_path ]; then
echo 'sbcl is not in the PATH environment variable'
exit 1
fi
if [ ! -x $sbcl_path ]; then
echo "$sbcl_path is not executable"
exit 1
fi
"$sbcl_path" \
--noinform \
--noprint \
--no-userinit \
--no-sysinit \
--disable-debugger \
--quit \
--load "$filename" \
--eval "($mainfunction)" \
--end-toplevel-options
#!/bin/sh
#
# SBCL wrapper script
#
filename="$1"
flag=""
if [ ! -z $filename ]; then
if [ ! -f $filename ]; then
echo "Could not find $filename"
exit 1
fi
flag="--load $filename"
fi
sbcl_path=$(which sbcl)
if [ -z $sbcl_path ]; then
echo 'sbcl is not in the PATH environment variable'
exit 1
fi
if [ ! -x $sbcl_path ]; then
echo "$sbcl_path is not executable"
exit 1
fi
"$sbcl_path" --noinform $flagAnd found them to be very hostile.
I decided I had better things to do with my time.
There were (probably still are) a few assholes and zealots on comp.lang.lisp, but they were easy enough to ignore (killfiles are your friends). I think some people also got a bit testy and short there because of the trolls. People like Jon Harrop liked to go on there and basically say, "You're all morons and lisp is useless garbage here's why..." as a way of promoting F#. It was incredibly obnoxious, and I recall during his time as a troll there people becoming overly sensitive to other posts that looked like trolling but were meant in earnest. This would have been off-putting if you got caught in the crossfire.
I tried learning CL back in 2006 and read a quickstart guide from the #lisp IRC channel. It had sentences in it like:
“ Using a plain text editor without any runtime connection to your Lisp implementation just because you think you prefer its keybindings is stupid and self-defeating.”
And
“Follow these directions or risk our wrath, or at least unsympathetic attitudes!”
The document, mercifully, doesn’t appear to exist any more. Maybe when I called them on it at the time they realized that maybe there’s a better way and changed it. But it definitely made a poor first impression.
The attitude of these communities has changed a lot since then. It has been 14 years since then! Right now, #lisp and #emacs and their Reddit counterparts r/lisp and r/emacs are a very pleasant, friendly, and supportive community. For those looking to becoming a part of the Lisp or Emacs community, I strongly recommend giving #lisp, #emacs, r/lisp, and r/emacs a chance.
I started 4 years ago. They are very helpful and friendly.
Just approach them with a genuine interest.
I made a series of videos how to do it in typescript. That was fun!
Here's the link if you're interested: https://youtube.com/playlist?list=PLP_fzAt_4T3QVlW_7Zr3CYLmV...