Date: - 1st October 2020
I spent the last 18 months learning and using Common Lisp in production.
I replaced the backend of Frosty App
with Common Lisp. The frontend remained as JavaScript/Next.JS.
In that time, I read a lot of conversations about why learning Common Lisp makes you a better programmer (probably because of Paul Graham?).
I cannot comment on that. But I can share my experience as a TypeScript Web Developer.
I find it fascinating when people ask why Common Lisp is not popular (as if popularity were a metric for being good).
The most common argument is that "Common Lisp doesn't have many libraries". This is true if you compare the number of libraries available on npm or pip. 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 they are implemented.
While using Common Lisp, I found myself writing functions for things I could easy find an npm
package for. And, by doing so, started to uncover mysteries about deeper technologies I didn't understand.
Let's go through an example...
I deployed my a website as a Common Lisp app. I used a library for the server. But to deploy the app, I needed to understand how sockets
and threads
worked. And the difference between Concurrency
and Parallelism
.
I would have never explored these topics with JavaScript. I could write an app with Express and be done.
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.
In Common Lisp, there are almost no answers to your questions online. (Relative to the amount of answers you will find for JavaScript).
The community is smaller than JavaScript. The language is larger and deeper. There are only few good resources. Many of the good libraries have sub par documentation. And, if you have a question on StackOverflow, you might have to wait 24-48 hours.
In the moment you need 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?
Here is the important part: Learning to figure 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 is not really a skill.
It is more of a habit. If this is not your nature, then Common Lisp will not help you develop it. However, if it is your nature, you may have noticed that when writing JavaScript, you didn't use this muscle.
A more experienced programmer has solved more problems than a less experience programmer. But if you compare someone with 2 years experience who figured out a lot of things versus someone with 6 years experience that copy-pasted from StackOverflow...
One learned. The other didn't.
I don't believe I can live without a Slime
REPL open on my computer to explore my ideas.
Slime is a Common Lisp REPL. It's special because it allows you to interact with your lisp program while it is running.
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 but you do not know how. In this phase, things change rapidly within a short period of time.
When I am writing business logic with JavaScript, I have a Slime REPL open as my playground. I use it to explore and test my ideas. Once I have explored it and it works, I can write the JavaScript equivalent.
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"
In JavaScript
First I 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 node fileName.js
This approach runs the whole script. But what if you are only exploring one feature?
You could split all functions into many files. But that isn't efficient if you are trying to solve a complex issue which might need many functions.
When I am exploring, I want an easy way to see 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 M-x Slime
CL-USER>
With the REPL, I can run functions individually or see the values of variables inside the REPL. Instantly.
I can run each unit of code individually. If you have never used the Common Lisp REPL, it's hard to describe how valuable this is with words.
Try it.
That's it. Bye for now.