The programmers who live in Flatland

Or perhaps, just perhaps, the true higher-dimensional move is realizing that choice of programming language isn’t usually the critical factor in whether a project, system, or business succeeds or fails, and that obsessing over the One True Way is a trap.

It might surprise the author to learn that there are many people who:

1) Have tried lisp and clojure

2) Liked their elegance and expressiveness

3) Have read through SICP and done most of the exercises

4) Would still choose plain old boring easy-to-read always-second-best Python for 90% of use-cases (and probably Rust for the last 10%) when building a real business in the real world.

The article could really benefit from some steel-manning. Remove the cute Flatland metaphor and it is effectively arguing that lisp/clojure haven’t been universally adopted because most programmers haven’t Seen The Light in some sort of epiphany of parentheses and macros. The truth is more nuanced.

Big lisp guy here. Have written tens of thousands of lines of scheme, at least, and common lisp.

But I don't get this "Lisp is so much better than everything else," thing. It feels very jejune to me.

Most lisp programmers barely use macros and most programming languages these days have most of the features of Lisp that originally made it useful (automatic memory management, repls, dynamic typing*, and even meta-programming if you really want it).

I do think that most common languages are mediocre but mediocrity is just how humans are.

--

If I had one thing I want fixed about Scheme it would be the dynamic typing, especially since many Schemes compile aggressively. Finding bugs is much harder when your apparently dynamic language has compiled out everything useful for understanding an error condition. Most of those mistakes could be caught at compile time.

> The ability to manipulate compile-time so effortlessly is a new dimension of programming. This new dimension enables you to write fundamentally better code that you’ll never be able to achieve in a lower dimension.

Show me. Specifically, material outcomes that I will care about.

Lisp has been around for 65 years (not 50 as in the author believes), and is one of the very first high-level programming languages. If it was as great as its advocates say, surely it would have taken over the world by now. But it hasn't, and advocates like PG and this article author don't understand why or take any lessons from that.

Macros can be very powerful. But! They are like DSLs, in that they create their own mini language that you have to learn. Arguably worse than DSLs, macros modify the context of the host language in which they are invoked. That is their power, but it's also what distinguishes them from regular library functions, whose interface semantics are generally simpler to reason about.

Macros are preferable to runtime reflection and monkey patching, but the compile-time reflection and monkey-patching represented by macros still incurs a complexity tax that needs to be weighed against the alternative of non-macro code.

I've been using emacs and have written a a few thousand lines of elisp. I like elisp. I generally like any language that I become proficient in. But lisp isn't some sort of magical hammer that turns everyone into 10x programmers.

Maybe I still haven't had my epiphany, but I'm not a huge fan of macros in lisps and DSLs (like what ruby is known for). It makes code harder to understand.

> Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?

Homoiconicity is overrated. Python is an acceptable lisp: higher order functions, dynamic types, generators, decorators. If you really need syntactic transformation you can use the ast module.

In the pro-macro camp, if languages like JS had macros, the language could be kept much simpler, leaving things like pipeline operators, async / await, etc to developers.

In the anti-macro camp, they’re hard to write, reason about, and debug stack traces. They are also tempting to use when you shouldn’t, and I think a lot of software shops would run into trouble with them.

Regarding Clojure, I wouldn’t call Clojure a write-only language, but I did find that my Clojure code was more inscrutable than my code in other languages— roughly as inscrutable as my Haskell code. Something about it makes me want to code-golf my way into tiny little clever solutions.

Also, I’ve been burnt by various pitfalls of dynamically typed languages— upgrading dependencies in large dynamically typed projects, etc. I’ll take static types over macros any time.

Also, Clojure’s start up time was off-putting, and would probably be even more so today, coming from Bun and Go.

These days, most of my work is in TypeScript, and it’s just fine. Not perfect, but fine. I haven’t missed macros much.

All that said, I do like Clojure. I miss the baked in immutability, the ability to omit commas in arrays / lists / maps / etc, keywords, and the threading macros.

In summary, some of us have given it a shot, and ended up choosing a different path, and that’s ok.

From the article:

"Lisp/Clojure macros derive from the uniformity of the language to enable composing the language back on itself. Logic can be run at compile-time no differently than at runtime using all the same functions and techniques. The syntax tree of the language can be manipulated and transformed at will, enabling control over the semantics of code itself. "

If you are a smaller consultancy solving hard problems, then you might need this.

The problem sometimes is: "I don't want this level of complication, especially when I am going to hand it off to other people to maintain it."

In the business world, you are not gated by your intelligence, but by the average IQ of the people who are going to maintain it over the years.

Robust macros allow you to create domain-specific abstractions. That's cool, but there are plenty of other ways. Even functions are a way to create abstractions. And with anonymous functions, you can easily create higher-order abstractions.

The only thing AST-level macros help with is creating custom syntax to cut down on boilerplate. That's very cool, but it comes with a cost: now you have to learn new syntax.

I love Lisp. I've written tiny Lisp interpreters for most of my games (Chron X, Transcendence) and even GridWhale started out with a Lisp-like language.

In my experience, Lisp is great when you have a single programmer who understands and controls the whole source tree. Once a program exceeds the capacity of a single programmer, more conventional languages work better.

A sadly typical flavor of essay: a lisp enthusiast who believes that learning lisp has made them into a uniquely Very Smart Boy who can think thoughts denied from programmers who use other languages. The "blub" paper asserts that there exists a linear hierarchy of goodness and expressiveness in languages, where lisp, by virtue of its shapelessness, exemplifies the pinnacle of expressiveness.

This is a profound misapprehension of the nature of language design. Languages exist within contexts, and embody tradeoffs. It is possible- common, even- to fully grasp the capabilities of a language like lisp and still find it inappropriate or undesirable for a given task. Pick any given context- safety-critical medical applications, constrained programming for microcontrollers or GPUs, livecoding environments where saving keystrokes is king- and you can find specialized languages with novel tools, execution models, and affordances. Perhaps it never crossed Paul Graham's mind that lisp itself might be a "blub" to others, in other situations.

The idea of a linear hierarchy in languages is the true flatlander mindset.

Thought this was going to be about the new discovery of a 1d spaceship in conway's game of life. Stuff is nuts. https://conwaylife.com/book/conway_life_book.pdf

I use both approaches. One thing is that Clojure code bases are comically hard for anyone to mentally parse if they didn't write it. At least the bulk of programmers... like you'll find on an actual team. Great to write, sure, but not useful in terms of onboarding new team members. Clojure programmers are typically great thinkers. And veterans. But if you are actually trying to build a company, then beware. Your handful of expensive brilliant programmers will build something that you can't bring people in to expand or maintain. Also watch out for the fact that the companies making the awesome tools that COULD be used by noobs often keep them closed source (Datomic and, I think here, Rama). They intend for you to hire them as consultants and pay licenses. Which is all fine... except the 2D languages have real open source libraries with huge adoption and ecosystems.

Tons of nested parenthesis suck. They are objectively hard to parse for a human.

> Many point to “ecosystems” as the barrier, an argument that’s valid for Common Lisp but not for Clojure, which interops easily with one of the largest ecosystems in existence. So many misperceptions dominate, especially the reflexive reaction that the parentheses are “weird”. Most importantly, you almost never see these perceived costs weighed against Clojure’s huge benefits. Macros are the focus of this post, but Clojure’s approach to state and identity is also transformative. The scale of the advantages of Clojure dwarfs the scale of adoption.

> In that essay Paul Graham introduced the “blub paradox” as an explanation for this disconnect. It’s a great metaphor I’ve referenced many times over the years. This post is my take on explaining this disconnect from another angle that complements the blub paradox.

The blub paradox, and the author's "flatland" methaphors, function as thought-terminating cliches. They provide the author (and Lisp proponents) with a simple explanation ("Everyone else is stupid") that doesn't force them to reconcile with more difficult questions ("Is it possible that other intelligent people have considered Lisp and rejected it for good reasons?")

And, honestly, it's just an annoying line of reasoning to hear that the only reason <you> don't use <favorite technology> is because you're just not perceptive enough.

For instance, the suggestion that "ecosystem" problems are "misconceptions" that critics fail to reconcile seems inaccurate to me. Does Clojure have a package manager as simple and straightforward as npm/cargo? Does it have a type system as well-maintained as TypeScript? Does it have a UI library as good as (choose your favorite web UI library)? These are all ecosystem problems. Do you think these problems meant nothing to everyone who decided against Clojure? Or do they all live in Flatland?

> The ability to manipulate compile-time so effortlessly is a new dimension of programming. This new dimension enables you to write fundamentally better code that you’ll never be able to achieve in a lower dimension.

There are many such "new dimensions of programming". Macros are cool, don't get me wrong. But given the choice between a proper macro system or a proper type system, I know which one I'm choosing every time.

I really enjoyed the preemptive comments at the end of one of his other blog posts:

https://blog.redplanetlabs.com/2025/06/17/make-worse-softwar...

it'd be nice if there was an attempt to give an example of what kind of powers moving into 3d-lispland allows instead of just saying that it's beyond the comprehension of the 2d-planar programmers.

because, i guarantee that it's not beyond our comprehension. at some point the author was a 2d-er that read/did something and had their understanding expanded. so... do that for us

Honestly, if you read the idiomatic factorial function and can't understand why no-one writes LISP I think you need a reality check.

Nobody thinks natively in nested prefix notation.

> A big chunk of our code was doing things that are very hard to do in other languages. The resulting software did things our competitors’ software couldn’t do.

I've never seen a general purpose programming language that couldn't do everything the underlying hardware is capable of. It could only be unperformant enough that you could call it unfeasible at worst. What's so hard to do in languages other than Lisp? Spam parentheses?

As others have said, the lack of any examples makes this post fall flat.

Also, consider that good work - particularly in art but also in engineering - requires constraints. Knowing what you cannot do adds guard rails and a base set of axioms around which you can build. Perhaps the power of LISP macros and AST manipulation is not “powerful and thus good”, but rather “too powerful and thus complicated”. Needing to write out a boring old function/class/module instead might leave you with code that is simpler to read and design around.

Alan Kay said something similar back in the 90s, framing it as ants living on the "pink plane" and the "blue plane". What he said at the time was an ant crawling on the pink plane can do a lot of pink plane things, but he won't think about the kinds of things he can do on the orthogonal blue plane, because he's never been there so he doesn't have those thoughts. Innovation in PLs comes when someone from the pink plane travels to the blue plane and brings back all they have seen, which causes people in the pink plane to start thinking new (bluer) thoughts.

  I'm going to use a metaphor for this talk which is drawn from a wonderful book called The Act of Creation by Arthur Koestler. Koestler was a novelist who became a cognitive scientist in his later years. One of the great books he wrote was about what might creativity be.—Learning.—He realized that learning, of course, is an act of creation itself, because something happens in you that wasn't there before. He used a metaphor of thoughts as ants crawling on a plane. In this case it's a pink plane, and there's a lot of things you can do on a pink plane. You can have goals. You can choose directions. You can move along. But you're basically in the pink context. It means that progress, in a fixed context, is almost always a form of optimization, because if you're actually coming up with something new, it wouldn't have been part of the rules or the context for what the pink plane is all about. Creative acts, generally, are ones that don't stay in the same context that they're in. He says, every once in a while, even though you have been taught carefully by parents and by school for many years, you have a blue idea. Maybe when you're taking a shower. Maybe when you're out jogging. Maybe when you're resting in an unguarded moment, suddenly, that thing that you were puzzling about, wondering about, looking at, appears to you in a completely different light, as though it were something else.

[flagged]