# A rant on Lisp
I've been fascinated by Lisp ever since I first heard about it. It's such an intriguing language, so different from everything else we use nowadays. Not just in syntax, but in almost every other way possible. The best C developer in history would be humbled by a Lisp codebase; learning Lisp feels like relearning programming from scratch.

The more I learn about its history, the more I'm fascinated by it. And it's weird, because I usually vehemently dislike super-high-level languages with dynamic typing and such "features" (basically anything with too much magic and voodoo). But Lisp, for some reason, is one of the very few exceptions to that discrimination of mine. It's completely opposite in fact, I enjoy Lisp a lot more than many other languages that fit my definition of being "good" much better than it. After learning more about it, I think I might know why: Lisp is so fundamental, that even if it seems to me like a very high-level language, it's actually a fairly low-level one. Lisp is even more fundamental and primitive than assembly itself: it's nothing but atoms and lists. The entire structure is simple to a fault, which is why many people (me included) believe Lisp was discovered rather than invented.

However, despite all of Lisp's differences and quirks and uniquenesses, it's unfortunately pretty redundant. I can't see any real-world situation where using a Lisp dialect would have any real advantage over just using.. Python? or even Lua? No matter how different the paradigm of your code is and how cool and smart your meta-programming is, the assembly being generated and evaluated at the end is the same, or even worse than what other languages would output. Programming in Lisp in a regular environment (say, Windows or Mac, or even a mainstream Linux distro) remains a purely recreational practice, as it ends up just being a toy scripting language. Lisp's image-based execution model is quite contradictory to the Unix-like file-oriented paradigm. It's very disappointing, really.

## An utopia made of lambdas
I've often thought of writing my own Operating System, completely based on Lisp, in an Emacs-like architecture; where every internal function of the OS is integrated with the userspace. Not only as an opaque callable FFI but as a modifiable, open and transparent interface, as if it was a function or datatype in your own header file in C. You could open something like a [scratch buffer], write a few lines of Lisp, evaluate it, and immediately change the way your window manager behaves, or activate a kernel module, or even create a whole new one and attach it to the running OS. Every running application would also be modifiable, customizable, scriptable by default. With hot-reload enabled by default, too. Source code always available and open by default.
However, even though this still sounds to me like a developer's heaven, I end up being turned off when I remember the contents of the previous paragraph: that a good chunk of the kernel and OS would still be written in plain old C and ASM. No matter the architecture, the Lisp layer remains an interpreted glue slapped on top, not actually something integral to the OS itself. There's no way to evade C and assembly, right..?

### Lisp down to the silicon
The notion of Lisp being discovered rather than created becomes even more convincing and intriguing when you learn about Lisp machines, or more specifically, Symbolic Processors: computers built with Lisp in mind down to the silicon. It's a fairly different paradigm of computing, to the point where it's not the register-based architecture we're so used to anymore. That, to me, is Lisp's (and my utopian OS idea's) saving grace. The idea of everything in the computer being Lisp, down to the very first line being evaluated by the CPU on boot, is extremely exciting to me. And the fact that that's not just some crazy pipe dream but something that has already been achieved over 40 years ago, gives me hope that I might actually be able to create such an environment one day. In the paper [LAMBDA: The Ultimate Opcode], Guy Lewis Steele Jr. and Gerald Jay Sussman describe their design for a completely Lisp-based computer, where the machine code itself is some dialect of Lisp. Where programs aren't made of an ordered array of opcodes but of a non-linear tree or graph, in the same way that Lisp is (syntactically) structured. This, as I interpret (and project) it, would allow for a system where the language used by the OS is a superset of the machine-code itself, and DSL's made with that superset are used to program more specific applications (say, graphics, audio, math, and other could each have their own DSLs based on the elemental dialect spoken by the kernel). Every application, and every part of the OS itself, would be immediately scriptable and modifiable and readable by the user. This also seems to me like it would heavily simplify the task of writing the OS itself, and even things like device and peripheral drivers.

This would be a completely different digital world. It makes me think of classic MacOS with AppleScript, TempleOS, and Emacs, all merged into one. To me, this is an utopian ideal, but simultaneously an achievable one. This architecture would resolve many fundamental problems of the current software stack, such as the Tower of Babel of abstractions we have, that only gets higher and higher, forcing elementary tasks to take exponentially more resources than they did in the past (and simultaneously forcing regular users to get new hardware and throw away the old, just to keep doing the same tasks they did 10 years ago with a nicer UI). The inevitable fracture and dissociation in the way different developers build the same thing, requiring arbitrary and redundant knowledge of libraries and frameworks that probably won't be around anymore in a few years, while also being forced to support all the dinosaur, long-obsolete technologies from yore. I'm not crazy though, I know that even if I actually build such a machine and OS, it would remain a hobbyist, recreational and educational project sitting in a remote git repo. But a man can dream.



Further reading:
- [SCHEME 79]
- ["The architecture of symbolic computers" by Peter M. Kooge]
- ["LAMBDA: The Ultimate Opcode" by Guy Lewis Steele Jr. and Gerald Jay Sussman]