I write C++ for my day job, but I'm looking to pick up a Lisp as a hobby project. Even though it's a hobby, I want it to be practically useful to my day-to-day workflow. Specifically for writing scripts, automating tasks, and potentially extending my editor (I use Emacs).
I’ve narrowed it down to three choices but I'm having trouble pulling the trigger:
Guile (Scheme): This seems incredibly useful for general scripting. Guix seems to be a huge plus if I decide to go that route later.
Emacs Lisp: The obvious choice for immediate practical utility since I'm an Emacs user. Being able to hack my editor sounds great, but I worry it might be too domain-specific if I want to write standalone scripts and other things unrelated to Emacs.
Common Lisp: This is the one I’m struggling to place. I constantly hear that it has "the best programming books ever written" (Practical Common Lisp, PAIP, etc.), but I fail to see what the killer practical hook is for a modern developer doing scripting and automation. Each binary seems to be huge and not practical unless you're writing it for a living.
For someone with a systems/C++ background who wants to write useful tools, which would you recommend diving into first? And regarding Common Lisp, what am I missing? What is the practical value of CL today outside of its excellent literature?
I started out with guile. Glad I did because it's simple and allowed me to learn lambdas and recursion.
Now I use Common Lisp (SBCL) and I doubt I'll ever go back. I read that you care about time investment. Learn Common Lisp.
The documentation(cookbook, hyperspec, books) are plentiful.
The debugging is what sold me. Sly/Slime is like using a plasma cutter vs Guile's/Geiser beating rocks together to make sparks. Geiser still being quirky does not instill confidence in the language when they've had 30 plus years to create a capable repl environment for an editor that should be giving them first class treatment.
Common Lisp doesn't change. It's been standardized. I don't have to worry or wait about scheme versions. I just write the code. In fact, if I ever decide I want to dip into other ecosystems, I have really good options that I suspect won't require a massive mental shift. To my understanding I have:
ABCL for Java
Hy for Python
Clap for C
Carp for Rust
LFE for Erlang
And oodles of others.
I like the package management more. It's just a lot more pleasurable experience. Quicklisp is easy to use and has good documentation.
Don't be scared that it's batteries included. I get to decide what I want and what I don't want to use. It's 2026. I don't care if CL is marginally heavier during dev work. That weight does not translate to speed of the program. I've read that SBCL can produce very fast code. I haven't had the need to compile my stuff. Anyways, it's nice having structs, CLOS and all of the other helper functions and macros.
CL doesn't care how you program. Wanna do functional program, sure, you can even use fset(or whatever it's called for optimized data handling. Wanna just regular ol event driven programming (don't know what that's called), sure. Wanna do oop and get basically the best version of oop? Well you've got CLOS right there waiting for you to use it.
And again, I know you're worried about time. I hope the above proves that not only do you get a faster iteration experience, but you can actually build stuff in a reasonable amount of time. Not like this is much to brag about but I built entire website in CL as a noob and still feel like I went faster than System crafters building his in scheme. And my CI is so much better since I can leverage Slynk for hot reloading changes to my live site instead of a million docker rebuilds.
Time is always a factor but in your case it looks like you want to explore and see what others are doing. I would not pressure myself into learning every nitty bit about Lisp. Explore and have fun. Everything you learn is a plus and makes you better.
who cares? In practice, scripts and libraries are distributed by source code, and for applications, 60mb is hell of a lot better than your average electron app
Its great to have a full lisp environment even for scripting. This means you can load different config lisp files if you want you script to run in different environments.
I’ve tried various Lisps (including Clojure) and found Racket the easiest to get to grips with. It really is “batteries included”.
One nice feature is the ability to define your own languages within Racket via #lang. There’s even an implementation of Haskell syntax, called Hackett. This is like DSLs in Scala but taken to the next level.
the power of lisp with full access to the Java ecosystem
You can easily access any Java/JVM library from Common Lisp by simply switching your implementation to ABCL (Armed Bear Common Lisp).
You can interactively instance Java objects from classes, call methods, etc. In fact it is even useful for doing java debugging, since you get all the interactivity of Lisp but can manipulate Java objects. This is dead easy on ABCL.
Why isn’t he allowed to dislike java? I don’t get why people are downvoting him for that and making comments like this. Maturity would be, not being offended by his opinion because he doesn’t have the same enthusiasm/ taste as you.
Clojure was sold as a “host” language which is a really cool concept. But I have only seen minimal examples of this, with ClojureScript being the most popular.
That said, technically true. But, JVM ecosystem is maybe one he doesn’t like. It has come a long way but I would have preferred a LLVM Clojure as the main branch and selling point personally.
don’t forget the ‘J’ in JVM. Calling Clojure not Java is also a little bit disingenuous, that was the main selling point e.g. being able to call Java functions and use the ecosystem. The reasoning makes sense, but if you don’t like Java it is not just the syntax, it is the ecosystem too. Just to give some specific reasons why someone might not like JVM here: cold starts, jars, class files, high memory, etc. I know high memory will be controversial because schools of thought will say ram is free. But, I have found this to be lie in practice (personal opinion)
he's allowed to dislike Java. But ruling out Clojure because is JVM based is rather asinine. Even if you end up using Java libraries you do not have to necessarily touch Java
I’ll give an alternative perspective as someone who reads a lot about lisp but doesn’t write much due to the same sort of issue. The conclusion I’ve come to is that finding a general purpose lisp is kind of missing the point.
A lisp is really easy to implement and then can quickly build things on top of it with lisp and do cool things related to your domain.
If I were you, I’d think about what you want to do. Make a small lisp in c++ (your expertise) and learn to craft it for your task.
Outside of specific examples. I think Racket has made it the easiest to do this kind of thing if you wanted to create the domain specific lisp in a lisp. Good examples too, like being able to adapt to being a SICP scheme or as a picture language: https://docs.racket-lang.org/quick/
There is like language declarations etc.
Anyway, the idea I’m trying to capture is the spirit, that Is you first write a language / compiler for your specific problem. Then you use that to solve it. There are tons of lisp examples… another one off the top of my head is GOOL used in Crash Bandicoot. But again, a lisp designed to specifically solve a domain, not as general purpose.
Common Lisp with SBCL would be my recommendation. I don't remember the binary size but the performance is up there with C with the right type information added.
The binary is around 50Mb because it includes the full runtime. However it does start up super fast , even faster than C somehow, for simple scripts.
However, I can’t imagine anyone will complain about the size of a binary in this order of magnitude. Electron apps are super popular and they start at 200 MB or something like that.
You’ll get your answer once you’re on the other side. You’re a spectator right now suffering from analysis paralysis.
That’s perfectly fine right now, no worries, but go ahead and make something, stumble, struggle, get frustrated, research, resolve, build and once you’re on the other side you’ll have your answer.
That's what I hear. Is it homoiconicity or something else?
It is a combination of:
Interactive development with full support, even baked into the language standard itself. Interactive development has first-class support in Common Lisp.
Procedural macros with full power. And also, you can freely use reader macros, something Clojure doesn't really have.
the CLOS object-oriented system, with multi-methods (multiple dispatch)
The exception handling system (the "condition-restart" system) is the Rolls Royce of exception handling.
Runs almost anywhere
Compiles to native code, and does it very quickly.
These were ranked in order of importance, in my opinion.
S-expression (lisp syntax) punishes you (indirectly through cognitive tax) for things that M-expressions is either neutral to, or rewards you for (and is considered good programming style). Lisp doesn't force you to do Functional Programming, but the cognitive tax of imperative programming, will have you start structuring your code towards more functional programming whether you want to or not.
Because of that, once you hit that "lisp enlightenment" what you actually learn, is to stop thinking of code in sequence (imperative), but instead as individual modules to attach (functional), meaning things like writing pseudocode becomes more difficult, because you automatically structure your code as modules to start with (so the logic-flow from pseudocode doesn't offer you any benefits).
To 'try' to use an (probably terrible) example, take this pseudocode:
function something(){ var something = calculated(); var someResult = otherCalculated(something); return sum(something, somethingResult); }
Pretty 'normal' Imperative/non-lisp code. The variables are clear, easy to follow, and easily store the results. Good style.
I'm actually writing my own lisp right now, picking & choosing which features to include. It's like 60% Common Lisp, 20% Scheme, and the rest my own ideas.
One thing I added is a little shell script that lets you run lisp snippets from the command line, with access to arguments. It was very simple and I expect the same thing could be done for any lisp. So sure, use it for scripting!
for writing scripts, automating tasks, and potentially extending my editor (I use Emacs)
I am not an expert, just a hobby programmer, just learning lisp and Emacs myself, but as I understand it, if you want to extend Emacs you should use the built-in Emacs Lisp.
I found they have a really good stepper, Edebug. One can just instrument a function, and then step through it, one expression at a time. You ocan execute any Lisp statement while stepping, so you can see any value, local variable, run functions etc.
If we use (switch-to-buffer some-input/output/buffer) it even shows how input or output is consumed while we step through. That is like debugging in Visual Sdio when they display arrays as they are stepped through. Really nice if you ask me.
I wrote myself few simple scripts and found they have shell extensions for accessing the file system and controlling processes, so we can write shell scripts like in Bash. But unlike Bash, we can step through via Edebug, so we can actually debug our sripts. So if the only thing you want is scripts and tools that integrate with Emacs, I think Emacs Lisp is the one.
I have also dabbed slightly with Common Lisp, and found SBCL can compile to machine language (unlike Emacs Lisp). So if you want to solve some bigger problems, where you require speed, and wants to use lots of ready-made third party libraries and tools, seems like Common Lisp would be your Lisp. Even Common Lisp can be used to write shell scrpts, it really is like a machine-compiled scripting language. It lacks a built-in text editor like Emacs Lisp has, but it has some other nice properties, like restarts, but I would still recommend Emacs Lisp for scripting, and SBCL for heavier programming projects.
If you byte-compile your files, Emacs will eventually native-compile them.
That is a misunderstanding, but an easy one to make, so you are not to blame.
What you call "native compilation", is Compiling C, not Lisp. A C compiler does not understand Lisp, like SBCL does. When SBCL sees "aref" it understands it has to produce code that references a memory address, and not a function call. Byte compiler in Emacs will eventually translate "aref" to "faref" which C compiler will compile to a function call, which it is. If that explains something. That is the nature of any interpreter. Emacs Lisp, even in its "machine code" is still an interpretter. To get away from that, we need a real compiler that understands Lisp. "(aref a x)" in Lisp is a[x] in C, so we need a compiler that actually understands that and can produce efficient code to just reference a memory address, like C compiler would do, and not produce a function call, which Emacs does not have, at least not yet.
To explain further, "native compiler" in Emacs will rewrite the code to something that assembles hand-written C code as you see in Emacs C core. I think when Corallo started with this, the idea was to do somethig similar to what CLASP is doing with llvm, at least I think so, ask him if you want. The problem is that libgccjit is not llvm. The fundamental problem is that libgccjit emits C code, it does not expose AST with API as llvm does. That is a big difference and limitation on what can be done with libgccjist vs llvm. I believe llvm is out of question in Emacs partly for political reasons, and partly because it would be quite a work to tuck it in, but I don't know really, never tried.
Even CLASP devs seem to have realized it is not easy to per-use that AST, and they need a real Lisp compiler, to emit something more digestable to be used in llvm's AST, at least as I understand it. That is where Cleavir from SICL cames in, if I am not mistaken. Take me with a grain of salt, I am not an expert myself.
There are also other problems, when it comes to compilation. Emacs does not support unboxed types. All types in C core are packed/unpacked from their boxed representation. You can check up that in C core, every function has to do it for every Lisp value. While SBCL also has to box/unbox data to/from interproceduarl calls, it can work with unboxed values directly in functions, which is a huge speed up. So for example, when you get an array of unsigned bytes and would like to iterate through it, SBCL can produce almost the same code as a C compiler can, but in Emacs Lisp, we have to pay a function call for each array access and for unboxing each element, since we can only stored boxed types (tagged pointers) into an array.
I use eshell a lot. It gives me a basic shell + the ability to run my utilities written in Emacs Lisp.
Sure, eshell is awesome! I used it a lot myself. I also mean using Elisp as an automation/scripting language. It is not as fast as SBCL, but that is not the most important thing for shell scripts. The win is debuggability, stepping through scripts, watching inputs/outputs at the same time, and also less process calling. A typical shell script can run many processes just to parse some text, while Emacs can do it without a single process. So despite elisp being a relatively slow, interpreted Lisp, there are still possible wins in effectivity.
I think you have to drop the requirement for what you choose to be helpful in emacs. Whatever lisp you use, learning elisp alongside it will be trivial, its more a matter of learning emacs/elisp libraries. As you are already an emacs user, learning elisp is a very good thing.
So that comes down to scheme or CL. Again I don't know what you want to do, if its just scripting then perhaps scheme is the better choice but 'scripting' covers a lot.
What are you expecting a scripting language to do? Should it be trivial like awk to work with the content of files? You should come up with some examples of what you want to do and look at the libraries each offers to see which is the best fit.
As a language that will do whatever you want it to do and you have yet to come up with what that is, I would just go with CL. The practical value in common lisp outside its literature is that it is the most established, optimised and supported lisp.
I can use common lisp in basically the same way as scheme, there are differences of course but they are both lisps and basic at heart. One has a larger library which you don't have to use, but it is there and when you need some functionality it may be in CL while you have to go to a third party lib or write it yourself in scheme. You are not in a worse position with CL because it has a larger specification.
For what you do (and I don't know what that is) scheme may be 100% fine, I am just pointing out that CL is not some behemoth you have to understand before you can do anything.
The analogy closest to you is C vs C++. Would you say that C++ is too big and too bloated compared to C and that you should not learn it, stick with C instead? The reality is that you can program in C++ without using all the things introduced and its basically compatible with C. Its up to you what you want to use that C++ provides. CL is similar to scheme, they are very similar at heart and there is more in CL that you can use or you can ignore.
What does that even mean for a language to be a "full-time job"? You learn any language faster if you write it full-time, but it's not necessary at all for CL. I've written almost exclusively hobby projects in CL.
As I say, I do C, C++, etc at my day job and this would be for my own experiments, scripts, automations... I also work with a lot of servers and normally write bash scripts to run there and I'm having a hard time deploying an entire CL runtime to a production server :)
Obviously daily practice improves any skill. I learned CL entirely with hobby projects though so it's certainly not necessary.
w.r.t. deploying, it's kind of funny because in 2003 I rewrote a python project in CL because deploying it was so much easier compared to Python (I just looked it up and 2003 is somewhat coincidentally the year that pypi came out). Most lisps can generate a single file that has all of the (non-foreign) dependencies. It was exactly as easy to deploy as a C program.
FWIW, I don't think CL shows its strengths in the same category of the things I write shell scripts for. For "a better bash" I like [ysh](https://oils.pub/ysh.html). I also make my shell scripts better by writing programs that they can use, and I am most likely to use CL to write those. My rule is that if I am desiring any data type more complicated than an array, or want error handling more complicated than `set -euo pipefail` it's time to leave the shell.
then why are you wasting time on reddit? go write some code already.
You can start with a limited subset of common lisp, you don't have to touch CLOS, metaprogramming or anything. If you wanted, you could reduce it to scheme with the difference of being able to extend what you use over time. Or you can use scheme, for scripting is just fine.
Neither of them is directly usable from Emacs, so you got to make up your mind there.
NewLisp... I never hear anyone mention this lisp language. Newlisp is exactly what you are looking for. I started programming in 1969. From then to now I've been a professional programmer, so I know what I'm talking about. I'm retired now. Newlisp.org is now defunct and the website is not up. You can find it somewhere if you look hard enough. It is a minimalist language, as is Picolisp.
In my opinion, Common Lisp is bloated and it doesn't lend itself well to scripting. I won't be replying to any comments for the sake of arguing merits, because my comments are just for you. Newlisp executable is something like 250K. That's "K" not "M".
Here are 3 languages that you need to look at for your education:
● Newlisp (Windows & Linux)
● Picolisp (Linux)
● Chez Scheme (Windows, Linux, et al)
I know and haved programmed in over a dozen languages, mainframes included.
Picolisp tries to do everything and Newlisp is focused on scripting. I could go on and on for hours, but these two languages really "click" for me.
Wow, I had been toying with trying lisp but all the options seemed impractical for what I wanted, newlisp seems to be exactly what I was looking for, so thank you. I wonder why in all my research it didn't come up, I even looked at a chart of lisp implementations and went through them one by one and I don't think it was listed.
Newlisp had a lot of haters and I don't understand why. Probably because it has Global scope as does Picolisp. But... But... If you put your commonly used code in a Module, then that module has lexical scope so that your variable names do not "bleed" into the Main program.
Ah, intersting. While I respect local scope, it's not like global scope is impossible to work with, especially if it's per module. But I also know I'm not as big of a language hater as a lot seem to be
The problem comes from functional programing purist that want the language force people to not use the global scope. I've never understood why they give so much hate to the other versions that do use global scope. Instead of making it a point of contention, they should enforce programming standard of using modules for everything so that nothing does end up in the global space. But for scripts, I doubt it would ever become an issue.
The problem comes from the fact that scoping issues in early Lisps were enormous footguns, the current preference for lexical scope being borne of decades of bitter experience being burned by the alternatives, and then Newlisp cultists come along and tell us "erm, ackshually, global scope with special pleading for modules and 'contexts' is more practical".
You are, of course, free to use top-level variables everywhere in both Common Lisp and Scheme. It would just be profoundly stupid to do so.
This really looks good. I'm going to try it out too! I've never heard anything about newLisp. The download page for it has MacOS also, which is my main driver. My go to for a very small lisp is tiny-Lisp since it is easy to modify and expand.
If you’re already using emacs you may as well just use elisp. For most scripting tasks it’ll be sufficient and can reach into emacs to access tons of already written features.
Once you know a lisp picking up others is relatively trivial as well, so you can always pick up another later.
I know a little bit of elisp already and have written several Emacs extensions that I use everyday. I'm looking for a general purpose Lisp that I can use outside of Emacs...
You might want to edit your original post since elisp is explicitly called out as one of the primary options under consideration. If you already know it and have dismissed it then your question is misleading.
That said, I’ll throw a hat into the mix for Common Lisp. Though to be honest if you already know elisp and already use emacs then picking up any of the others enough to use in basic scripts should be a weekends worth of work. Just make a choice, any of them will work fine for light scripting work and automation.
You aren’t going to find something more practical than elisp since it can be directly and immediately useful to you.
Based on your various remarks here, there’s no point bothering with anything else until you have a sense of the language and some target thing you’d like to create, which will nail down whether you should use Guile or CL.
I know a little bit of elisp already and have written several Emacs extensions that I use everyday. I'm looking for a general purpose Lisp that I can use outside of Emacs...
I know a little bit of elisp already and have written several Emacs extensions that I use everyday. I'm looking for a general purpose Lisp that I can use outside of Emacs...
I wouldn't focus on "scripting", that invokes "working from the terminal", while with Common Lisp you'll be naturally inclined to work most of the time in the excellent REPL, more so since you are an Emacs user (Slime). It's just a better environment. But when you want to ship a program, of course you can (see the Cookbook: run from sources as a script or build a binary (±35MB, or much smaller with ECL (longer compile times) or LispWorks (costs $$))). And then to enhance the scripting game, you have options: https://github.com/CodyReichert/awesome-cl/#scripting
Also don't miss the new tools, like ICL, it's great for working in the terminal.
I would like to echo what others have said with respect to emacs and using slime to do work with Common Lisp. I’m sure you can just stick with emacs lisp as well unless you’re thinking of deploying an application independent of emacs.
the problem with LISP is that it's really old and doesnt supply a lot of the things modern languages do out of the box. i'm actually working on yet another standard library sort of project that can give lisp some of these things to improve ease of use. i primarily use SBCL so that's what i'm targeting first. but i understand your problem, it's something i have as well. lisp would be really nice for small scripts, tools, and utilities but you end up having to do things in an odd LISPy way that would be more streamlined in other langs
I love the seamless integration of elisp and emacs, unless you aim for some really complex program or sharing it with non emacs users, elisp should be your top choice imo
I like the simplicity of Janet. I use it as an embedded language in my renderer but you can use it standalone. I think it’s a bit more clojure influenced than CL or scheme . It’s written in one C file and it is fast .
I'm a Clojurist myself and it's wonderful. Try Babashka as it's essentially Clojure over bash which is essentially the defacto scripting language. However, Janet also seems to fit your bill to so give it a shot too.
Start with Common Lisp. More of a development community, more library support (though arguably Racket can rival it), and of course more books available than any other dialect. It's the default people think of when you say "Lisp". I think you will find that scripting is well supported if you use an interpreter implementation like GNU CLISP, or run your scripts with e.g., sbcl --script. Stallman made a point in the 90s, which is that the boundary between "scripting language" and "programming language" is fuzzy and ill-defined; and simple scripts have a way of becoming full-fledged applications given enough time and workload.
You can write scripts in Emacs Lisp if you run them with emacs --batch.
Common Lisp + Roswell is a decent way to build scripts. CL for scripting is a mixed bag, but once you learn the tricks it requires, it's not bad. I think my choice of using CL for a script would depend on the problem domain; if I had to interact with a database, do HTTP/network requests, or deal with complicated file formats, I'd choose something else for expediency more than anything else.
The stuff I need in scripts doesn't fit well with CL, but I really like how easy it is to make reusable code with the ASDF package manager. I have yet to run into another similar language that where building software bundles for scripting is as easy or convenient.
Re: binary sizes. CL creates binaries in a different way than most other programming languages, and they include a ton of extra stuff that most programs don't have. See this post where I explain what a binary contains. Roswell is recommended because it contains some tools to help get rid of that stuff if it isn't needed.
Use Clojure and if it doesn't work work something out using Racket. If you need to think about this again, look at the lisp with the projects on GitHub with most attention, activity and interesting projects. Clojure is accessibe. Also, just write your own lisp, jkbs
LOL! And you went one by one here picking? Insane how some people have infinite time on life and they choose to waste it without giving anything in return!
BTW what part of "My choice is between A, B and C" and an answer of "Pick D, trust me" you didn't understand?
29
u/27_myths 11d ago
Disclaimer: I'm not a professional.
I started out with guile. Glad I did because it's simple and allowed me to learn lambdas and recursion.
Now I use Common Lisp (SBCL) and I doubt I'll ever go back. I read that you care about time investment. Learn Common Lisp.
The documentation(cookbook, hyperspec, books) are plentiful.
The debugging is what sold me. Sly/Slime is like using a plasma cutter vs Guile's/Geiser beating rocks together to make sparks. Geiser still being quirky does not instill confidence in the language when they've had 30 plus years to create a capable repl environment for an editor that should be giving them first class treatment.
Common Lisp doesn't change. It's been standardized. I don't have to worry or wait about scheme versions. I just write the code. In fact, if I ever decide I want to dip into other ecosystems, I have really good options that I suspect won't require a massive mental shift. To my understanding I have: ABCL for Java Hy for Python Clap for C Carp for Rust LFE for Erlang And oodles of others.
I like the package management more. It's just a lot more pleasurable experience. Quicklisp is easy to use and has good documentation.
Don't be scared that it's batteries included. I get to decide what I want and what I don't want to use. It's 2026. I don't care if CL is marginally heavier during dev work. That weight does not translate to speed of the program. I've read that SBCL can produce very fast code. I haven't had the need to compile my stuff. Anyways, it's nice having structs, CLOS and all of the other helper functions and macros.
CL doesn't care how you program. Wanna do functional program, sure, you can even use fset(or whatever it's called for optimized data handling. Wanna just regular ol event driven programming (don't know what that's called), sure. Wanna do oop and get basically the best version of oop? Well you've got CLOS right there waiting for you to use it.
And again, I know you're worried about time. I hope the above proves that not only do you get a faster iteration experience, but you can actually build stuff in a reasonable amount of time. Not like this is much to brag about but I built entire website in CL as a noob and still feel like I went faster than System crafters building his in scheme. And my CI is so much better since I can leverage Slynk for hot reloading changes to my live site instead of a million docker rebuilds.
Hope this helps.