One thing that I need to remind people off when I am talking about programming languages in a public space is to not let me talk (or even dare think about talking) about lisp. The reason being that once I start talking, the only thing that can stop me is complete silence.
I do not have this luxury when it comes to write in a blog, so I am now making it a problem of everyone who reads these. Sorry in advance.
What do I mean by "ahead of it's time"
ANSI Common Lisp, and thereby extension the dialects it built itself upon, got a lot of things right.
For instance, it's macro system is in my opinion one of the most flexible macro systems to be available on a programming language.
However, plenty of people have talked about macros in common lisp, and I am not willing to rehash what other more knowledgeable people have written about them. So I'll leave finding articles about their history as an exercise to the reader.
But I want to specifically touch on Lisp Images.
You see, lisp compiles your code to this thing called bytecode, which is a way of allowing your program to have all the features of common lisp while still allowing it to run on your system. But even though Common lisp implementations allow you build an executable with bytecode, in reality what they are doing is dumping the current "image" into a file to be loaded by the interpreter.
"Dump" here means that everything that is available to your current REPL or execution context—packages, functions, which package you are currently on, bound variables, and so on—also becomes available to that image.
It's kind of like taking a snapshot of that specific point in time and freezing it until that image is loaded again, warming it up.
This basically means that by distributing a lisp program built for, let's say x86_64-linux, you will have exactly the same state as you had before making the image. This can very loosely be called reproducible since the state is the same in both instances, so in theory, any bugs you find on the application can also be found in yours without it depending on external software state, such as the current system's libraries.
It's kind of like Docker but for individual programs.
But wait, don't we do this already but with entire systems?
Apples and pears
Docker allows us to put applications into boxes dubbed "containers", which are basically small, lightweight virtual machines that run inside your machine while using as little resources as possible.
In a sense, we could draw some comparisons between these and common lisp images.
A distribution's packages and libraries could be roughly mapped to common lisp packages.
The entry point can be mapped to a function inside a package.
State can be mapped to a variable.
And so on.
If you think about it, images are kind of like containers for your code, without the overhead of having to spin up a whole virtual machine to run.
Of course, there are security implications
However, unlike containers, images are not sandboxed.
Any image can access other image's memory, and vice versa.
Images can also access files external to themselves, which is very useful when dealing with things like databases and a user's files.
You should not expect a common lisp image to be safe by default because it can do basically everything that a normal program can; They more closely resemble a packaging format rather than a container, which is more secure.
Technically, there is nothing stopping you from running an image inside a distroless container, which skips the need of spinning up any unnecessary packages that your program may not need, and you would have the benefits of both. But you still need to take measures to secure your software, regardless of how foolproof you think your dependencies are.
I'll stop myself before spouting nonesense
It's like almost midnight right now. I should sleep.
But I decided to talk about lisp.
Ha, ha.
Maybe I'll do something tomorrow of more value, like finishing Audit Logs for Stoat, or maintaining Crescent, or writing a renderer for facets on bunny log. Who knows!
Only time, will tell. 🐇