The programmers who live in Flatland
blog.redplanetlabs.com
blog.redplanetlabs.com
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.
The technical merits of languages just aren't relevant to choosing them for most developers, unless they're helping solve a people problem.
"Artisanal" languages like Lisp, and Forth can be fantastic at solving problems elegantly, but that's not the most important thing to optimize for in big organizations where a large portion of your time is spent reading code written by people you've never met who may not have known what they were doing.
Many of the tools that come from big tech are designed to ease the challenges of organizational scale. Golang enforces uniform styles so that you don't have idiosyncratic teams doing their own things. Bazel is a largely language agnostic build system, with amazing build farm support. Apple and Google have both contributed heavily to sanitizers and standard library hardening in order to detect/eliminate issues without reading the code. Facebook has poured vast resources into automatic static analysis. AWS built an entire organization around treating all their internal interfaces the same as external ones.
I think the field of programming languages has grown enough that we have to start acknowledging the future of programming largely won't be in the context of what it means for devs working at large corporations. One of my favorite talks is from Amy J. Ko called A Human View of Programming [1], which argues there are many other ways to look at programming than "tool for generating business activity" and "mathematical construct", which heretofore have been the dominant views of programming languages.
Because there are so many other forms and purposes programming languages can and will take (she goes through them in the talk), so evaluating them and creating them solely on how well they are able to fit into a corporate R&D pipeline is a very narrow and short-term view of the field.
Indeed, it's been the case for a long time now that most people who write programs are not in fact professional software developers. The most used language in the world is Excel, by several orders of magnitude, and it's the opposite of everything devs say a "proper" language must be. There's something we as a field still need to learn from that.
Is the most used bridge-building technique a plank over a small culvert, or the properly engineered bridge that carries constant, multi-lane highway traffic for a century? How do we weigh the usage of resulting products into the usage of a design and production method? Should we consider the number of program users? The users X hours of usage?
Fundamentally, the software field is still just so young and we haven't teased apart the "obvious" different domains and domain rules that we have for production of different material goods. In some sense, the domains and domain rules for material goods emerge out of the connection to culture, economic roles, health, and safety aspects. Whether it falls into civil engineering, building codes, transporation rules, consumer product safety, food and drug, ...
The self-similar way that software can be composed into systems also makes it confusing to categorize. Imagine if we talked about other crafts the same way, and conflated textile manufacturing, clothing design, tailoring, costume making, wardrobe management, scripting, choreography, acting, and dancing as a single field that coordinates the visual movement of fabric on a stage.
Define it as # of people who possess the knowledge and resources to effectively use said language to solve a problem they have in their actual lives.
> Fundamentally, the software field is still just so young and we haven't teased apart the "obvious" different domains and domain rules that we have for production of different material goods.
I think we're saying the same thing here from different angles. I said it's developed enough that we can see there are very different ways of doing things. You said it's young enough that we don't know all the different things there are.
Instead, the world should have seen the light of Hindley-Milner type systems, ML-inspired languages, immutability, or at least not sharing mutable state. Did Haskell fail? Hmm, let's look at Typescript and Rust.
Don't get me wrong, a Lisp is always a great and fun language, and you can write whatever DSL you might like on top of it. But the old joke that "a Lisp programmer knows the value of everything, and the cost of nothing" still has quite a bit of truth to it.
But the real strength of Lisp is in the macros, the metaprogramming system. And I suspect that typing most macros properly would be a bit less trivial than even typing of complex generic types, like lenses. Not typing a macro, and only typechecking the macroexpansion would formally work, but, usability-wise, could be on par with C++ template error reporting.
Of course you can do all of this, but you need to build it yourself: see rewrite-clj. If you want to build a clojure debugger that is able to display or refer to code with the same indentation the programmer is dealing with in his text editor, you need to bridge the gap between clojure expressiosn and their string representation.
Anyway I concur that reversible macros would be great. Tag the output, have those tags propagate to the input by playing the macro backwards. Complex stuff really. That's a job for category theory I guess.
https://cybercat.institute/2024/09/12/bidirectional-programm...
I think we (the Clojure community) quickly figured out we don't really want static typing, which is a bit evident by the low uptake of Typed Clojure.
Personally I found it to A) make it a hassle for downstream consumers since your design is suddenly impacting others, because you can "lock things down" and B) have that very same effect on your own codebase, where it becomes a lot less flexible where it needs to be flexible.
Nowadays, I just use another language if I want static types, which happens sometimes but not nearly as often to say that dynamically typed languages are "dead" or whatever.
Spec is definitely underrated here considering it's built into the language and has a wider scope but for most people they want the intellisense experience which you can get with clj-kondo + mailli but is not built in so most teams don't use it, fair enough
I'd like to move the goal posts though and say I want flowstorm in every (any other?!) language
I can just run the program and scrub backwards and forwards through the execution and look at all the immutable values frame by frame with a high level UI with plenty of search/autocomplete options
For program understanding there's nothing better
The fact I can program against the timeline of values of my program and create custom UI on top is crazy
One of the most mind blowing demos to me was Bret Victor's inventing on principle and having a programmable reverse debugger for your language makes those demos viable
I built an emulator recently for work that replays what happens on live locally, combined with flowstorm I can go line by line and tell you exactly what happened and why, no print statements no reruns with my own custom UI customised to our apps interesting parts
This is my appeal to anyone outside of Clojure please build flowstorm for JavaScript and or Python
The design of flowstorm is definitely helped by the fact that 95% of Clojure programs are immutable but I don't think it's impossible to replicate just very difficult
To this day, I know of no study that was able to demonstrate superiority of statically-typed languages - [1].
What studies clearly show, is that both in terms of productivity [2] and bug reduction [3], expressivity reigns supreme.
And Clojure is the most expressive [4] out of languages that can leverage huge ecosystems (Java and JS, soon C++ through Jank dialect).
[1] https://danluu.com/empirical-pl/ [2] PBX study from Economics of Software Quality by Caper Jones [3] https://arxiv.org/pdf/1901.10220 [4] https://redmonk.com/dberkholz/2013/03/25/programming-languag...
Being able to do something like:
(deftype Digit ()
'(Integer 0 9)
(deftype Digit-Vector (&optional (length '*))
`(Vector Digit ,length))
(defun integer->digit-vector (integer)
(declare (type Integer integer))
(coerce (loop :for character :across (format nil "~D" integer)
:for digit := (char-digit-p character)
:when digit
:collect digit)
'Digit-Vector))
Probably not an absolute truth, but definitely a personal truth for you. For me, it's pretty much the opposite, static/fixed types is such a pain when you just wanna solve a problem and you know how to achieve it, all the invariants/constraints but the language tells you "No, you know what, this other person said you cannot use X for Y, so I'm gonna say no" instead of just letting me do that thing.
With that said, I still reach for Rust for about ~30% of new projects, despite the types, because some languages fit other problems better, simple as that. And still a lot more contracting gigs available for various Rust codebases who've fallen into disrepair, so one does what one can.
I feel like big codebases regardless of their size are hard to wrangle not because of the languages used, but because of the programmers having to rush through building proper abstractions, or even considering not adding so much abstractions. I've seen awful heavily typed codebases as much as I've seen awful dynamically types codebases or awful codebases not using explicit types anywhere, to me there seems to be no correlation between "awful" and "number of explicit types used".
Personally, I prefer a big codebase with lots of (good) unit tests in a dynamic program, than a that same big codebase with no unit tests and explicit static typing everywhere, especially when refactoring and needing to ensure everything (from a business logic perspective) works correctly. But again, this is my personal truth, and I'm not trying to claim it's universal.
The talk I posted from Alan Kay is the steel man. I think you've missed the essence of TFA because it's not really about Clojure or lisp.
If you only think about programming languages as a way to make money, the analogy of being stuck in Flatland is perfect.
But TFA was riffing on Paul Graham's old essay Beating the Averages, which argued precisely that the expressiveness of Lisp gave his startup a business edge. That was the context of my comment. I'd add that most of what most of us do in our day jobs is to use programming languages to make money, and there's no shame in that at all. And if you want to talk about why certain languages get widespread adoption and others not, you have to talk about the corporate context: there is no way around it.
But I'll rephrase my question, just for you: "what abstract problems can you solve or thoughts can you express in Clojure that you can’t express in Python or Rust?"
I think the money question is a red herring here. I’d phrase it more like: what problem in a user’s problem space is expressible only like this? And if the only user is the programmer, that’s alright, but feels more aligned with pure academia. That’s important, too! But has a much smaller audience than engineering at large.
I’m not just talking about people who program for a living. The majority of academic CS chooses its research directions because of what limits people are running into for business; even privacy-focused software has been commoditized by many business; a large amount of OSS development is by (and often paid for by the employers of) people working for money; heck, after Linus’s initial “just a hobby OS” period even Linux’s contribution base was primarily driven by business needs (even if those needs influenced it via “contributor had a problem at work and committed a solution for it upstream in spare time” as often as “paid contributor upstreamed a change on behalf of their employer”).
But look at historical languages and why they were created:
Algol - to explore writing algorithms
Fortran - to help scientists write programs using typical math formulas
Matlab - to help write programs in linear algebra
Haskell - to explore lazy program evaluation
ML - to explore how to reason about proof automatically
C - to build an OS
Python - to interface with an OS
LISP - to formalize symbol processing
APL - to explore programs defined over arrays
LOGO - to help young kids to program computers
Prolog - to create a language around the idea of formal logic.
Smalltalk - to create an entire programming system, not just a language
(I've left out C++, Java, and JavaScript because I feel like those languages are mostly about serving business interests)
Pretty much the entire computing landscape over the past 50-70 years has been defined by people writing languages for reasons other than "this is for a business to use to make more money". So if we let business-driven interest dictate the future direction, we will have missed out on all the things that could have been. Would Haskell ever have been invented if businesses interests were the only concern for researchers?
The interesting bit here isn't related to Clojure or Lisp, that's what people are chewing on because it's the surface level topic of the essay. The thing that interests me about this post is how it touches on the psychedelic nature of learning programming languages and what that does to one's perspective as a programmer.
So when you ask "what business thoughts can you express in the language", my response is it's not about what you can express, but more about "what new thoughts / ways of thinking has the experience of learning the language caused you to become aware of?".
Few people can go their whole lives writing Python and think all the possible thoughts there are to think about the shapes and forms programming can take. It's hard to develop a good sense for your own practice of programming if you never step outside and see it from other perspectives. It often takes exposure to completely new languages with different design points and abstractions to really give one perspective about their own practice.
The easiest one related to lisp is just the form of the syntax, which is surprising to many students. Most programmers don't even consider you can write (+ 1 1) and that's the same thing as (1 + 1). They don't think about the pros, or the cons, or why one might be better than the other, because every language they've used and ever will use writes it as (1 + 1). But as soon as they see Lisp, they immediately see something that changes their perspective about everything they have previous learned, and therefore will reshape how they approach programming in the future. It doesn't have to mean they will use Lisp going forward, but it does mean they will program in their language of choice with greater purpose. That's how we each hone our craft.
Add on homoiconicity, read/eval, programming as manipulating an AST, and meta programming, and you've got yourself a righteous trip.
Now, can people learn about those things from other sources, without encountering Lisp? Of course. Can you express those ideas in mainstream languages? Yes. But the point is many devs don't think those thoughts until they've had a psychedelic experience, it's very common, that we need to consider that it's part of one's growth journey as a programmer to have these experiences, so we should encourage it. The author of TFA doesn't have experience enough to make that point, as they are on the journey, which is why I brought Alan Kay's talk into context, since his perspective is from the other end of the journey.
Programming language ergonomics matter and there is a reason why Lisp has so little adoption even after a half a century.
I could probably include Forth as a scripting language in a bigger app, but that app is probably going to want more complex variables than machine word size ints, and fixed-length strings. So, oh dear, Forth's not a great fit for that, and everyone just uses Lua anyway, so Lua it is.
Which is a pity, because I like Forth, and I used to to create possibly the nerdiest project on Github. I like Forth a lot, and I'd encourage anyone curious about how you get from "chunk of thinking sand and copper" to "thing I can type commands in" to have a crack at it - it's easy enough to implement your own, just to see how it's done.
But I don't expect anyone else to jump up and like it too, just because I said it's cool.
Well, maybe one or two of you will?
It boots off a floppy disk, so it was really just a case of working out where in the ROM and OS disassembly the entry points were, and making it all fit around the assumptions the ROM makes.
This allowed me to make up a diagnostics disk to check the RAM (a whopping 128kB of sample RAM) and IO are working.
https://gordonjcp.github.io/miragetools/
Now I wouldn't place a bet on it being the nerdiest project on Github, but I suspect it's well up there.
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."
This is me to a T — even when I'm building hobby projects. The point of writing any code, for me, is most of all to see a certain idea to fruition, so I choose what will make me most productive getting where I want to go. And while I still worship at the altar of Common Lisp as an incredibly good language, the language matters much less than the libraries, ecosystem, and documentation for productivity (or even effective DSL style abstraction level!), so eventually I have had to make my peace with Python, TypeScript, and Rust.
An incredible epiphany that you can't transmit may not be as useful as a a moderately clever idea you can.
i think lisp's magic is a lot more cultural than most people think. i.e. how lispnicks implement lisps and the ecosystem around it. how easy it is to walk the entire ladder of abstractions from machine code to project specific DSL's. how pluggable its parsing pipeline is -- something that is not even exposed in most languages, let alone customizable.
the language, the foundation, of course matters. but i think to a lesser extent than what people think. (hence the trend of trying to hire lispnicks to hard, but non-lisp positions?)
and it's not even an obviously good culture... (just how abrasive common lispers are? need to have a thick skin if you ask a stupid question... or that grumpy, pervasive spirit of the lone wolf...?)
maybe it's just a peculiar filter that gets together peculiar people who think and write code in peculiar ways.
maybe it's not the macros, but the patterns in personality traits of the people who end up at lisp?
Using a bad language for 8 hours a day makes me irritable and it's impossible to prevent that irritability from overflowing into my interactions with other people. I'd rather that my conversations with the computer be joyful ones.
I'm going through this now, having to deal with code nobody wants to touch because it is overly complex, has no documentation, and is in a language no one else knows. Now, whenever i see an effort like this, to bring an exoteric language for absolutely no good reason, i try to kill it as fast as possible.
I don't want to be the victim of this code in the future or have my team bear the cost of maintaining stuff they don't understand.
Best typo ever! Portmanteau of esoteric and exotic :-)
Languages like Lisp, Clojure, Rust, Haskell, Erlang give strong engineers room to build powerful abstractions, but they also increase cognitive load and ramp up cost. In most orgs with churn and constant hiring, you do not get to enjoy "we built great abstractions and now we are fast". You live in "someone new is trying to understand what the last person did".
That is why hand holding and guard rails win. Not because Python or similar are technically superior, but because they support a commoditised, fungible workforce. Even if a wizard in a high dimension language is 2x more productive, that does not necessarily beat a slightly larger team in a mainstream language once you factor in turnover and ramp up. Companies mostly optimise for business impact, predictable delivery, and ease of staffing, not for maximising the ceiling of the top few programmers.
That said, at the individual level, as a programmer, you definitely can benefit from learning and mastering those added dimensions, even if you are to never use them again professionally, they expand your mindset.
In a language like C++, Rust or even Haskell, those "powerful abstractions" are mostly about building libraries, not application code. You still benefit from powerful libraries that were built as part of the ecosystem, even while keeping your own application code simple and intuitive to ease onboarding of new coders. Part of the "powerful abstractions" is to enable a "hand-holding and guard rails" approach for application code that's going to interface with that full-featured library.
You mean another slick text editor :/
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 ML family or Haskell fit that bill. Both OCaml and Haskell also have an equivalent of macro systems. So does e.g. Rust, for that matter.
I agree with your main point. The attitude you’re referring to is largely a relic of a previous era, at this point.
If you really want static typing, Lisp macros are powerful enough to implement a full ML type system in userspace as a library.
Sure, but we’d hardly expect equivalence in such different languages.
I’ve written macros in all the languages I’ve mentioned, as well as Scheme’s syntax-rules and syntax-case, and in practice I don’t see some big advantage of any of them.
What actual useful macros do you write in Lisp, that would also be useful in one of those other languages, but can’t be expressed by their macro systems? Not saying it’s not possible to come up with theoretical examples, but what’s going to actually impact a programmer in those languages?
> If you really want static typing, Lisp macros are powerful enough to implement a full ML type system in userspace as a library.
On the other side of the fence, using Camlp5 you can implement Lisp or Scheme syntax and have OCaml run it directly. I did a toy implementation of that for Scheme years ago using Camlp4. You could easily implement syntax-rules macros in that environment. I enjoy games like that, but I don’t see much impact for real-world programming.
I think Coalton is cool, but I think you start to run into the limitations of Lisp syntax. I’d rather use Haskell to write that kind of code, it’s more concise. And to quote Paul Graham, succinctness is power. (PG does not endorse this message!)
Show me. Specifically, material outcomes that I will care about.
There are quite a few programmers who say lisp led to early retirement. That was a pretty interesting idea to me. I like going to the beach a lot.
I am not so sure about people who don’t want to get done: if you like doing what the ticket says instead of the other way around lisp probably isn’t going to be something you’re interested in.
Show me!
You can use a better tool than someone who is using a worse tool, and take their customers, because it will be easier to solve the problems better and faster than that someone-else. Lisp is a great tool, but it doesn't help you if you're the tool: You still need someone with a problem who can pay for a solution, and they need to like you enough to pay you for that solution. If you need to hire 30 people to figure that out, Lisp isn't going to help with that problem.
And it's not fast: Lisp is not a get-rich-quick scheme, it's a tool that you can learn how to use to make other tools, it's a tool that is difficult enough to use that you will need perhaps years of experiences in order to use effectively, it's a tool so advanced it might seem like actual wizarding magic just watching someone screencast if you don't know what you're looking at, but it's still just a tool.
Who retired early? What did they make with Lisp? Do you have a link to that thing they made? Was it actually something special about Lisp or did they just happen to use Lisp while making something that could have just been as easily - or more easily - done with something else? Is that real-world, specific, material outcome replicable by other people and they should know about it?
Do you see these things -> ? <- Those are question marks.
Now go look back at your last comment and tell me how many of them you see.
> Was it actually something special about Lisp or did they just happen to use Lisp while making something that could have just been as easily - or more easily - done with something else?
I don't know. Why are you asking me this?
Please read my comments carefully, because I put time into trying to tell you something, but I am not trying to tell you what I think you think I am trying to tell you, and I am not going to justify my opinions to you any more than I would ask you to justify yours.
> and they should know about it?
I have mixed feelings about this: Who are the other people you are talking about?
There are a lot of people I won't work with; I won't trade with them; sell them my products; buy theirs; No contact if I can help it. That's why the first question I asked you is what is important to you? Did you even see my question?
Thing is, other languages do this with metaprogramming or explicit codegen. Everyone needs metaprogramming sometimes—that's why everything supports it, actually.
That is a big assumption about the way popularity contests work.
The big assumption here is to think that a language can be so much superior and yet mostly ignored after half of century of existence.
I'm sure Lisp has its technical merits but language adoption criterion is multi-dimensional.
Thinking Lisp should be more popular disregarding many factors of language popularity is the true "Programmer who live in Flatland".
That said, like in anything else, this kind of craftsmanship doesn't translate to monetization and scale the markets demands. What markets want is to lower barrier for entry, templatize, cheapen things, and so on.
It's normal then that languages optimized for the lowest common denominator, with less expressive power and more hand holding have won in popularity in enterprise and such, where making money is the goal, but that Lisp remains a strong and popular language for the enthousiasts looking to level up their craft or just geek out.
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?
Lisps are a continuum, and I still think there's room for new ones that are even better.
True lisp adherents view lack of differentiating syntax as an unalloyed good, but that cuts against the grain of how humans have communicated with each other for millennia.
You'd think the current crop of people who grew up texting each other without syntax might be a better fit for it, but then you run smack dab into the fact that the minimal required syntax is, in fact, actually required, and very important, to boot.
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.
Why is println! a macro when it's a function in almost all other languages?
Rust doesn’t need that, it’s mostly Rust code in the standard library, with only a small bit of compiler magic triggered by the macro. (Println! isn’t the best example because it does have that small bit of magic; most macros are just plain Rust code.)
Here’s a very impressive set of macros that I use daily. [0] This lets you do “printf logging” on an embedded device, with the human readable strings automatically pulled out into a separate section of the ELF file so the actual log stream data is tiny.
I did a similar thing for C a while ago, as a pre- and post- build step. It worked, but much less well, and was a maintenance nightmare.
Edit: and yeah, I think you do need to know you’re calling a macro, because macros aren’t limited to “normal” syntax or semantics. The ! is a signal that you’re escaping the usual bounds of the language. Like this. [1]
[0] https://defmt.ferrous-systems.com/macros
[1] https://docs.embassy.dev/embassy-stm32/git/stm32f301k6/macro...
Incidentally it also means that formatters like `rustfmt` won't apply the usual rules. For the macros that don't really deviate from ordinary Rust syntax, that can be a bit annoying.
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.
Why is that? Never understood the complaint about slow Clojure startup time. Usually the context is either your local development environment, where you start the process once until you're done for the day, or you're deploying on a server and 5 seconds vs 10 seconds doesn't make that big of an impact. Short-lived CLIs aren't really suitable for Clojure in the first place, you'd use something like Babashka for that.
So why is the "slow startup" actually a problem? I don't seem to hit that issue ever myself, wondering what kind of situation people find themselves at where this hurts.
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.
You’re even sort of making the same point. Specialized problems need specialized tools. How do you write those specialized tools? Start from scratch, or just make a Lisp package?
Instead, it's just an ad-hominem attack based on the idea that non-Lisp programmers are too limited in their thinking to appreciate Lisp.
Show me a convincing example of something that's simple/clear/elegant/superior in Lisp, and how difficult/complicated/ugly/impossible it would be to do the same thing in Java/C++/Ruby/Python.
In the absence of that, the entire article can be refuted by quoting The Big Lebowski: "Yeah, well, you know, that's just, like, your opinion, man."
You can also read anybody ranting about how great Zig comptime is if you want more contemporary examples.
If someone writes code based on an algorithm out of a 1985 textbook, and I tell them that they could make it go 20X faster if they learned more about processor architecture (out-of-order execution, cache coherency, NUMA, etc.) — a new dimension of programming to them — am I making an ad hominem attack?
Once I made somebody’s SQL query 100X faster by explaining what an index was. Fortunately they didn’t think I was attacking their intelligence.
Next time try calling them a "2D programmer who lives in flatland" for not knowing about indexes and tell me how it goes.
The book was originally written as a metaphor for understanding a fourth spatial dimension, and as far as I know the metaphor is generally taken as helpful, not demeaning. The flatlanders are never described in an unflattering way.
Serialize and deserialize data. You're currently using something like XML or JSON for a human readable data serialization format in those languages. JSON and XML are not first class components of those languages. S-expressions are a better version of JSON and are first class components of Lisp.
(but you often get something much better when config files are plain lisp code; i.e. they are eval'ed, assuming that the threat model allows it)
I think it's just trying to say there's another dimension, the meta-level enabled by macros and Lisp's syntax that opens up the possibility of new solutions, which may or may not be better, as that's so context dependent.
But what I feel it's saying is you can't even begin to imagine solutions that leverage this new dimension without learning about it and getting to grip with it mentally.
In that sense, it's saying when you don't know, you can't even explore the space of solutions at that higher dimension, not necessarily that they're better for all problems.
It’s hard to explain without explaining a bunch of what a specific library does. But many clojure libraries expose macros that let you interact with them in much more readable/terse ways.
I’m on my phone but a good one to google is core.logic. It exposes a macro to define a “logic function”, which lets you define logical expressions using pattern matching. You can come up with rules that would be many more LOC and less readable as a normal function. You can of course define them as a normal function too, which is useful when the pattern matching doesn’t express the problem well!
1) Electric Clojure 2) Rama
100% this. I think you can replace "languages" in that sentence with many things (employee levels is another big one that is relevant to this forum - employee value comes in many, many shapes). Reducing complicated things to one dimension can be a useful shortcut in a pinch, but it's rarely the best way to make complicated choices among things.
"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.
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.
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.
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.
Cross-pollination between programming languages is a good thing.
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?
> 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.
There are plenty of reasons it might be better not to use Lisp, but very few people actually get as far as considering them.
> The programmers who live in Flatland
> Likewise, you cannot comprehend a new programming dimension because you don’t know how to think in that dimension
> the sphere is unable to get the square to comprehend what “up” and “down” mean.
All of this is patronizing. It implies that I am incapable of understanding the benefits of Lisp. If only I were able to lift myself out of the dull swamp I find myself in! But I am capable, and I do understand them, and I still don't like it! And I think most Lisp detractors do as well! I would argue that it is the Lisp proponents that live in Flatland - they need to understand that there's another dimension to criticisms of Lisp that aren't just "I don't like parentheses" and that there is substantive feedback to be gleaned.
I'm also somewhat reminded of the decline of Perl and how some people who love and still frequently use Perl don't really seem to even acknowledge the complaints people have about it, which seems to prove the claim about the decline being cultural. According to that kind of attitude, the lack of popularity is inexplicable, and we might actually be lucky that they're not resorting to conspiracy theories to "explain" the mismatch between their preferences and observable reality.
The Haskell motto of "avoid success at all costs" seems a lot healthier, as in, they know they might need to choose between going mainstream and getting to keep a language that suits them personally.
Lots of the Lisp advocacy also comes off as either entirely too vague, like this blog post, or stuck in the age of the `worse-is-better` talk (1989, so predates WWW and nearly all the programming languages in widespread general use). I don't care about comparisons to C, because the only places C is seriously considered for new projects these days are in places where a GC is unacceptable (and purposes Rust isn't certified for or whatever).
The irony is Clojure(script) has all those things. By virtue of being hosted on the JVM and Javacript and having first class interop with both. ClojureCLR even gives you access to all of C# etc.
Being hosted was a great play in terms of ecosystem.
What it doesn't have is ALGOL style syntax.
Consider e.g. the "with" statement in Python[1]. Someone came up with the idea, found a way to integrate it into python and a year later, people could use it. In Lisp, you write a macro.
Now Python is a rather agile language as these things go. In other languages it would be a lot more than a year. When I was in college, my professor wanted us to use generics, but the school mandated language, Java, lacked generics at the time. So we were told to use a fork of javac that had generics added. Pretty much none of the development tools would play nicely with this, and javac was at least two orders of magnitude slower at compiling than my preferred java compiler at the time (jikes).
None of this is world-ending, but it really is annoying. The argument for macros is just "what is the next generics/with/whatever feature that your language is missing." Most of the features that lisp programmers use macros for have made it into modern languages that continue to evolve, so the leverage narrows. In the late '90s it was probably a much bigger multiplier than today.
I wasn't pointing to the Clojure community at large, the Clojure community is very welcoming to beginners and newbies, like I was once.
It's true that the focus on the language is improving it for everyone, not just beginners, and that can appear like a bad idea if you're a beginner, but I personally agree with this goal.
The problem mentioned by parent is something I haven't personally experienced, but seems exclusive to their job/position/experience, and I don't understand calling that specific person/developer brilliant.
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
I had heard before that Lisp had something called "macros", but I didn't know exactly what they were or how they differed from C macros. This blog post kind of explains that, but not in a way that couldn't also apply to C macros if you tried hard enough.
I want to know more, but I didn't have any examples here to look at. I may look them up now that I have an idea.
https://blog.redplanetlabs.com/2025/04/22/how-gd-netcetera-u...
"You can get in touch with us at consult@redplanetlabs.com to schedule a free consultation to talk about your application and/or pair program on it. Rama is free for production clusters for up to two nodes and can be downloaded at this page."
I remember playing with call with cc, or creating a flow programming language, thinking in higher order, etc..
I clearly do not want to work with lisp, and many of those concepts can be used in other languages without too much effort now (lambdas, map, filter, reduce,... Among the most common and useful).
I think learning lisp is nice as it helps explore interesting areas of programming on a mental level. I can't stress enough how it can wrap your mind sometimes.
Will it help you program faster and bug free? Probably not, will it improve your mental model of programming languages, probably. Will you enjoy learning abstract things, if you like solving math puzzles, probably, otherwise probably not.
It's hard to express the 'powers' it gives you, it's like spending much time thinking about simple things that usually you just use without thinking about.
As a crude example, the scope of a variable shared between two lambda function that is not shared with the global space.
Sorry that I don't have a specific example in mind, I feel like the 'power' is just spending enough time thinking on complex things.
https://blog.redplanetlabs.com/2025/06/17/make-worse-softwar...
Just like today's UX designers who need a 3D surface to draw a lousy rectangle.
Nobody thinks natively in nested prefix notation.
I do, but I have ASS, so I basically am a space alien of the type to appreciate alien technology.