INTRODUCTION

When you are given the job of choosing the tech stack for a job, how do you choose? If the task is data science, what language would you choose? Would your choice be different if your task was web development? Would it be different if it was embedded development? Or accounting? Or mobile apps?

Programming is fraught with choices. Probably the most important choice is which language to use for any particular task. If you're doing data analytics, you "need" to use Python. If you're developing a web application, you conventional wisdom says to use JavaScript, PHP, or Ruby. If you're writing accounting software, the "obvious" choice would be Java. If you're writing real-time software with performance and size limitations, "of course" you reach for C or Rust.

We take it for granted that such choices are necessary, that we need to choose a language based on a task. No language is adapted to every task; when you need to drill, you don't use a hammer.

But what if we had a special, universal tool? What if the tool could be adapted to the task, rather than chosen for it?

Common Lisp is just such a language. It's the highest level language out there thanks to macros and the parentheses, but a surprisingly low level language thanks to the ability to inspect generated assembly output and the ability to specify types (although in a somewhat sloppy way) to optimize for speed and memory efficiency. As a result, Lisp is both highly expressive while sacrificing little performance. The result is a highly adaptable language–perhaps the most adaptable.

Lisp does sacrifice something, though. Well-optimized C is going to yield smaller executables, lower memory use, and faster performance. Well written Ruby is probably aesthetically more pleasing than well written Lisp–and I believe that aesthetics are important. The Lisp ecosystem can usually get you started, but it's not going to do most of the heavy lifting like in Java.

With Lisp, you sacrifice choosing the absolute optimal tool for the job in exchange for absolute flexibility. Lisp may not initially be the best tool for any single job, but you can mould it into a very good tool for many jobs. It's not the fastest, but it's competitive with the fastest. It's not the prettiest, but you can make it prettier if that's important to you. There may not be a free library available to do exactly what you want, but you usually don't have to start from scratch, either.

Lisp is not a language specialized to a domain of work; it's a language specialized to being generally adaptable. It's not a master of any domain, but it can be adapted to a wide variety of domains.

In English, a man who isn't a specialist in any field, but who commands both knowledge and competency in many domains, is called a generalist.

In Japanese, such a man is called オールマイティ–almighty.

That's what Lisp is. Lisp is almighty, and it summons programmers to become almighty.

AI is a divisive topic among programmers. Some Lispers hate it, others love it.

But given that it exists, we have to decide our relationship with it. If you use AI, doesn't that at least theoretically boost your ability to be Almighty? I think so. I make use of it to do all kinds of tasks I otherwise would never attempt, such as writing the Emacs Lisp code I use to export this book's ORG file to multiple HTML files for the online version of this book (https://almightylisp.com), or the Typst code I use to generate the PDF version. On the other hand, most of this book was written by me, not by an LLM. It generated quick reference tables for me, and it wrote the chapter on loop because I didn't feel confident I could go into the detail that loop deserves. I used it to check for errors after I wrote this book (of which there were many).

I am also experimenting with using LLMs to build more complex systems with mixed results and feelings. None of those show up in this book. I'm still trying to form a solid opinion about it myself, like some of my handsome readers.

In some ways, I and many others feel pressured into using LLMs for fear of "being left behind". In other ways, it relieves the pressure to go on side-quests to learn how to set up servers for deploying, debug proxy server errors, etc.

On the other hand, if you overuse LLMs, you risk losing your ability to problem-solve or do any kind of valuable programming. This is especially the case if you haven't learned to the fundamental principles of programming (which necessarily requires practicing programming by hand). There are signs that some thought leaders are beginning to acknowledge the potential long-term risks of "tokenmaxxing".

My opinion as of now is that LLMs are a powerful tool that needs to be respected and used wisely. Wise use of LLMs necessarily requires that you have and maintain a knowledge of coding. LLMs are most valuable when skilled users are writing the prompts and checking the work.

In the context of Common Lisp programming, LLMs have one flaw: they won't spontaneously come up with sophisticated abstractions for expressing problems and solutions in novel ways. Coalton would never be spontaneously invented by an LLM to help solve hard math problems. My LLM was happy to use plain format strings to produce the HTML output for this book; I had to ask it to write and then use an HTML-generating domain specific language–it didn't come up with the idea on its own.

So being Almighty entails neither Tokenmaxxing nor shunning LLM use entirely. Almighty programmers respect LLMs' utility while acknowledging its weaknesses.