3 Reasons Why Leaning And Using Common Lisp Made Me A Better Programmer
Publish Date - 1st October 2022
Last Updated - 30st October 2022
I have spent the last 18 months learning and using Common Lisp.
I replaced the backend of
In that time, I read a lot of conversations about why learning Common Lisp makes you a better programmer (probably because of Paul Graham?).
Closer to Programming Concepts
I find it facinating when people ask why Common Lisp is not popular (as if popularity were a metric for being good).
The most common argument is that "they do not have many libraries". This is true if you compare the number of libraries to npm or Python. But I see this is a good thing. Libraries are amazing for moving fast. I use them all the time.
But if your goal is to become a better programmer, then at some point you need to know how libraries work. Or how to implemented them.
With Common Lisp, I found myself writing functions for things I could find an
npm package for.
Let's go through an example...
I deployed my company website as a common lisp app. I used a library for the server. But to deploy it, I needed to understand about
Threads and the difference between
I am not suggesting that you need to learn Common Lisp to discover what a socket or a thread is. I am saying that Common Lisp allowed me to dig under the hood of how things worked. Because I had no choice.
Building my "Figure It Out"
In Common Lisp, there are almost no answers to your questions online. (Relative to the amount of questions you will have).
What that means is, you have to figure it out.
You need to put the pieces together yourself and find a solution. Will you quit or will you try to figure it out in?
Here is the important part: Learning to figuring things out for yourself is a priceless programming skill
Today, when I am writing Next.js applications, things break all the (damn) time. But guess what... I can figure it out ☺️
Finally, this more of a habit than a skill.
Sometimes, there are no answers (ever had a hydration error with Next.js?). Usually, more experienced programmers have solved more problems than less experience programmers. But if you compare someone with 2 years experience who figured out lot's of things versus someone with 4 years experience that copy-pasted from StackOverflow...
One learned. The other didn't.
Exploratory Programming In The Lisp Repl
I don't believe I can live without a
Slime repl to explore my ideas.
Exploratory programming is when you have a problem to solve with code but you don't know how to implement the solution. Or you want to translate a domain problem into code and you do not know how yet. In this phase, things change rapidly in a short period of time while you test ideas.
Why would I do that? Isn't it slower?
Good question. Let's explore.
The starting point of our example is "I want to do X, but I'm not sure how to implement it"
I first need to create a new file. In that file I will write all my business logic.
To see the effect of a change I would need to run the whole script with
This approach runs the whole script. But what if you are only exploring one function?
You could split all functions into many files. But that isn't efficient if it's you are trying to solve a complex issue which might need many functions.
When I am exploring, I want an easy way to the value of a variable or the outcome of a single function.
Exploring In Common Lisp
Create a new file, add all your business logic to the file.
Open a new repl with
Now, you can run functions individually or see the values of variables inside the repl.
This means that you can run each unit of code as an individual. If you have never used the Common Lisp repl, it's hard to describe how valuable this is.
That's it. Bye for now.