Why Common Lisp

Why Common Lisp

Common Lisp lets you redefine programming. This alone is enough justification. Or is it?

·

4 min read

Programming as a tool

Before we talk about programming languages, we need to talk about programming. And when talking about programming – or any field for that matter – we need to attend to reasons. Why program? For an adequate answer, you'll need a larger picture in mind. No one grabs a hammer to just have it in hand unless you're in the apocalypse. We need to stare at our goal and ask what we need. For some goals, programming won't necessarily get you there. Making a todo app is a rather inefficient way to get to that calm life you wistfully dream about.

image.png

It is a critical error to think any type of work will yield desired results. That is, if we believe we just smash our keyboards enough, all of our problems will disappear. Many senior engineers will laugh in pain. Others are ardent, rewriting service XYZ in a hot new stack. Still, more often than not, we have the same problems. The hammer no longer works in a world that requires rocket ships. The same could be said for a lot of programming languages out there. They come embedded with The Right Way™ to frame issues until we end up with more todo apps.

The hammer no longer works in a world that requires rocket ships.

Programming meta

Within games, there's a concept of a 'meta' which is a collection of accepted 'in' strategies. Meta is necessary to chart out what to do in your unfolding match. Yet, paradoxically, the winners are the ones who break the meta as they play. They end up redefining it with their new strategy. After staring at the current meta, they reframe and find new win conditions. This is what makes spectator sports rather engaging. It evolves.

I contend that programming also has a meta. There are a set of 'in' strategies. Object oriented programming is just one of many major 'in' strategies. The issue is that, unlike games, the programming meta has no consensus. Partly due to no common overarching goal, but let's assume all programmers want to create quick, elegant, small software. The main reason there's no consensus is because there's no defining moment. In games, meta evolves by direct test: did you win? While in programming, although you may vaguely feel out how slick a language is and how closer you are to your larger picture, there's no "YOU LOST" plastered on your screen. The closest "YOU LOST" I can imagine may be legacy system build errors.

Finding your win condition

So, how does one learn to create elegant, quick, simple software? One thing is for certain: you need to be able to change how you write programs. For example, Assembly languages used to be the standard. And you could have been the most brilliant Assembly programmer, and fulfilled those conditions under the limits of Assembly. I mean, geez, Super Mario 64 was made in assembly! Still, with the demands of modern games, it's hard to say Assembly would work in your favor. Standing on Assembly looking out toward modern day games, one can only be in awe. How did they get there? Well, they changed how they programmed. Yet most of this change is driven by a select few.

Within most languages of today, how you program is decided by the language designers. They'll tell you how to package, build, structure, design your system. There's idiomatic code you'll want to learn. They may give you an escape hatch with their own macro system, but it's not all that popular to touch. So you get in the habit of doing things the idiomatic way, but now we're not really... moving outward. The question worth asking is, is this it? Is this all we can do? If we didn't ask that with Assembly, we wouldn't have a lot of technology we do today. Only by dismantling the rigid systems of today may you create the mythical software of tomorrow.

Common Lisp waits patiently

Common Lisp hands you the tools to break and recreate. It is often touted to be the programmer's programming language, for you build the language up toward your objectives. You have the flexibility to change how you write programs. By change, I mean any new developments, sugary-syntax, paradigms, ways of thinking. And it has a long history. Lisp isn't going away anytime soon. If anything, with history as my witness, the current systems we have today are.