11 ms·

The programmers who live in Flatland

108 points by winkywooster 10mo ago

parpfish 10mo ago
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
- 1313ed01 10mo ago
  I agree. Especially as someone that likes LISP-like languages and uses Janet and Fennel quite a bit (and some elisp, in the past also Clojure) but never used a macro for anything. Would love to hear more about that third dimension I am missing out on.
  - joeevans1000 10mo ago
    Ditto.
  - nathan_compton 10mo ago
    Marcos are only very appealing to tyros. Most old salt Lispers avoid them. I would argue that a macro is only appropriate if you are adding a genuine syntactic feature to a language (one hint that this is the case is if your macro involves binding variables).
- Sophira 10mo ago
  This, exactly. 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.
- joeevans1000 10mo ago
  This is too high level, but I found this: https://blog.redplanetlabs.com/2025/04/22/how-gd-netcetera-used-rama-to-100x-the-performance-of-a-product-used-by-millions-of-people https://blog.redplanetlabs.com/2025/04/22/how-gd-netcetera-u...
  - joeevans1000 10mo ago
    Hmmm... this might be a way: "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."
- somethingsome 10mo ago
  Let say.. I remember quite well when I learned Lisp, and differently to any other language I learned, it gave me profound insights and even more profound frustration trying to understand some concepts. 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.
deleted 10mo ago
[deleted]
ModernMech 10mo ago
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. https://tinlizzie.org/IA/index.php/Alan_Kay_at_OOPSLA_1997:_The_Computer_Revolution_has_not_Happened_Yet https://tinlizzie.org/IA/index.php/Alan_Kay_at_OOPSLA_1997:_...
- hu3 10mo ago
  I always understood that part as: Cross-pollination between programming languages is a good thing.
  - ModernMech 10mo ago
    That's the upshot of what he's saying. But how the cross pollination happens -- crossing over to another plane of thought -- is I think the real point. That is: Cross-pollination between programming languages is a good thing, and therefore we must often force ourself to think outside of our narrow way of thinking in order to find new ways, or else we will dig ourselves into a trench (or find ourselves at a local maxima in the design space of languages).
libraryofbabel 10mo ago
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.
- wrs 10mo ago
  While what you say is true (I’ve used Lisps for 40 years and here I am writing Rust), the people who consciously make that choice are a tiny niche. There are vastly more people who don’t and can’t make that choice because they don’t have 1-3. So the empirical evidence for what’s actually critical is pretty slim.
- AlotOfReading 10mo ago
  The reality of modern software development is that most people focus on languages they use for work, and developers are statistically likely to be employed at companies with large numbers of other developers. 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.
willrshansen 10mo ago
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 https://conwaylife.com/book/conway_life_book.pdf
- NooneAtAll3 10mo ago
  and I thought it would be about influence of spherical geometry for maps and stuff, and how that differs from standard arr[x][y]
hashmap 10mo ago
> 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.
- geocar 10mo ago
  What do you 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.
  - hashmap 10mo ago
    "Lisp makes people rich, and I love being rich. Using Lisp actually can't help but make you rich. But I can't actually provide any examples of that happening or how they might translate to anyone else. Get so rich with Lisp. Lisp." Show me!
    - geocar 10mo ago
      I think you probably misunderstood 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.
johnfn 10mo ago
> 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.
- wrs 10mo ago
  In reality, most people, intelligent though they may be, don’t consider and reject Lisp, so that argument doesn’t really work. I know it irritates people who actually do consider and reject Lisp, but those people don’t realize that they’re a tiny elite who are not the target of these essays. There are plenty of reasons it might be better not to use Lisp, but very few people actually get as far as considering them.
chromaton 10mo ago
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.
- tikhonj 10mo ago
  > If it was as great as its advocates say, surely it would have taken over the world by now. That is a big assumption about the way popularity contests work.
  - scragz 10mo ago
    free market brain.
  - samdoesnothing 10mo ago
    If something is marginally better, it's not guaranteed to win out because markets aren't perfectly rational. However if something is 10x better than its competitors it will almost always win.
  - hu3 10mo ago
    Invert the logic. 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".
- ruricolist 10mo ago
  The sketch here would be that Lisps used to be exceptionally resource-intensive, allowing closer-to-metal languages to proliferate and become the default. But nowadays even Common Lisp is a simple and lightweight language next to say Python or C++. Still it's hard to overcome the inertia of the past's massive investments in education in less abstraction-friendly languages.
RodgerTheGreat 10mo ago
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.
- wrs 10mo ago
  “Common, even”? Citation needed. I’ve worked closely with hundreds of developers over the years and maybe two of them made a conscious, knowledgeable choice whether to use Lisp for something. 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?
- chihuahua 10mo ago
  It would also be a lot more persuasive if the article provided even a single example of how Lisp enables superior solutions. 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."
  - wrs 10mo ago
tra3 10mo ago
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?
- didibus 10mo ago
  I don't think you should use eLisp as your point of reference. It's the worst Lisp by far. Lisps are a continuum, and I still think there's room for new ones that are even better.
  - tra3 10mo ago
    Can you tell me more about this, or point me in the right direction?
GMoromisato 10mo ago
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.
- wrs 10mo ago
  I’m writing a lot of Rust lately, which is rapidly becoming regarded as a conventional language, and I sure do appreciate all those things I use every day that end in exclamation points.
  - GMoromisato 10mo ago
    I'm curious here, because I don't know Rust. What's the difference between a macro and a function call from the caller's perspective? Do I (as the caller) need to know I'm calling a macro? Why? Why is println! a macro when it's a function in almost all other languages?
    - wrs 10mo ago
      GCC can type-check printf (matching format string to arguments) because the compiler doesn’t just treat it like a function. But that requires special-case code in the C compiler itself that is basically opaque magic. 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 https://defmt.ferrous-systems.com/macros [1] https://docs.embassy.dev/embassy-stm32/git/stm32f301k6/macro.bind_interrupts.html https://docs.embassy.dev/embassy-stm32/git/stm32f301k6/macro...
nathan_compton 10mo ago
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.
- antonvs 10mo ago
  > If I had one thing I want fixed about Scheme it would be the dynamic typing 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.
  - wild_egg 10mo ago
    None of the macro systems in those languages are really equivalent to lisp macros. If you really want static typing, Lisp macros are powerful enough to implement a full ML type system in userspace as a library. See https://coalton-lang.github.io https://coalton-lang.github.io
    - antonvs 10mo ago
      > None of the macro systems in those languages are really equivalent to lisp macros. 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!)
drivebyhooting 10mo ago
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.
- zephen 10mo ago
  IMO, Python was an acceptable lisp even before it grew generators and decorators. 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.
teaearlgraycold 10mo ago
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.
shrubble 10mo ago
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.
moffkalast 10mo ago
> 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?
philipwhiuk 10mo ago
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.
- tmtvl 10mo ago
  > 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.
djaowjxj 10mo ago
[flagged]
christophilus 10mo ago
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.
- embedding-shape 10mo ago
  > Also, Clojure’s start up time was off-putting, and would probably be even more so today, coming from Bun and Go. 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.
  - chamomeal 10mo ago
    I also understand this is an issue for a lot of people but it’s never been an issue for me! I wouldn’t want it for serverless stuff I guess. But I would never think to do that lol
joeevans1000 10mo ago
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.
- embedding-shape 10mo ago
  I'm not sure I'd call a programmer "brilliant" if they cannot A) make a codebase simple enough for people to contribute to and B) handle the social parts of training someone to get good enough to contribute to the codebase.
  - joeevans1000 10mo ago
    Agreed. And this is the real miss of much of the Clojure community. There is a handful of amazing people in there pulling 90% of the weight of bringing noobs in to the language. And the rest don't even seem to notice their efforts. Little awards and grants here and there, yes. But the majority don't even care if the language has wider adoption or not. It works for them and that's enough. But many of the successful projects are toy or side project ones. A large number have comically minimal UIs... sub useful in today's world. Quite a few Clojure programmers use 2D languages in their day jobs, only bringing Clojure in for small parts if at all. All of this is a top down vibe. The core team has never meaningfully addressed the terrible error messages the language spits out because they are able to decode the problem themselves. Empathy or concern for noobs or wanting to grow the language seems a far priority for them. The same for the cryptic documentation, seemingly written for themselves at best. Very talented people, mind you... just not concerned with the things that would have caused adoption of their entirely unadopted language (percentagewise).
layer8 10mo ago
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.
nateburke 10mo ago
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-software-slower/ https://blog.redplanetlabs.com/2025/06/17/make-worse-softwar...
tliltocatl 10mo ago
Tons of nested parenthesis suck. They are objectively hard to parse for a human.
hulitu 10mo ago
> Learning new dimensions > You can’t persuade someone in 2D with 3D arguments. This is exactly like how in Flatland the sphere is unable to get the square to comprehend what “up” and “down” mean. Just like today's UX designers who need a 3D surface to draw a lousy rectangle.
hkon 10mo ago
I liked this post. But I was a bit disappointed when it ended so soon.
aidenn0 10mo ago
The power of macros is somewhat overblown and not at all hard to explain. 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. 1: https://peps.python.org/pep-0343/ https://peps.python.org/pep-0343/

108 points by winkywooster 10mo ago

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

1313ed01 10mo ago
I agree. Especially as someone that likes LISP-like languages and uses Janet and Fennel quite a bit (and some elisp, in the past also Clojure) but never used a macro for anything. Would love to hear more about that third dimension I am missing out on.
- joeevans1000 10mo ago
  Ditto.
- nathan_compton 10mo ago
  Marcos are only very appealing to tyros. Most old salt Lispers avoid them. I would argue that a macro is only appropriate if you are adding a genuine syntactic feature to a language (one hint that this is the case is if your macro involves binding variables).
Sophira 10mo ago
This, exactly. 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.
joeevans1000 10mo ago
This is too high level, but I found this: https://blog.redplanetlabs.com/2025/04/22/how-gd-netcetera-used-rama-to-100x-the-performance-of-a-product-used-by-millions-of-people https://blog.redplanetlabs.com/2025/04/22/how-gd-netcetera-u...
- joeevans1000 10mo ago
  Hmmm... this might be a way: "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."
somethingsome 10mo ago
Let say.. I remember quite well when I learned Lisp, and differently to any other language I learned, it gave me profound insights and even more profound frustration trying to understand some concepts. 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.

deleted 10mo ago

[deleted]

ModernMech 10mo ago

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. https://tinlizzie.org/IA/index.php/Alan_Kay_at_OOPSLA_1997:_The_Computer_Revolution_has_not_Happened_Yet https://tinlizzie.org/IA/index.php/Alan_Kay_at_OOPSLA_1997:_...

hu3 10mo ago
I always understood that part as: Cross-pollination between programming languages is a good thing.
- ModernMech 10mo ago
  That's the upshot of what he's saying. But how the cross pollination happens -- crossing over to another plane of thought -- is I think the real point. That is: Cross-pollination between programming languages is a good thing, and therefore we must often force ourself to think outside of our narrow way of thinking in order to find new ways, or else we will dig ourselves into a trench (or find ourselves at a local maxima in the design space of languages).

libraryofbabel 10mo ago

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.

wrs 10mo ago
While what you say is true (I’ve used Lisps for 40 years and here I am writing Rust), the people who consciously make that choice are a tiny niche. There are vastly more people who don’t and can’t make that choice because they don’t have 1-3. So the empirical evidence for what’s actually critical is pretty slim.
AlotOfReading 10mo ago
The reality of modern software development is that most people focus on languages they use for work, and developers are statistically likely to be employed at companies with large numbers of other developers. 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.

willrshansen 10mo ago

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 https://conwaylife.com/book/conway_life_book.pdf

NooneAtAll3 10mo ago
and I thought it would be about influence of spherical geometry for maps and stuff, and how that differs from standard arr[x][y]

hashmap 10mo ago

> 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.

geocar 10mo ago
What do you 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.
- hashmap 10mo ago
  "Lisp makes people rich, and I love being rich. Using Lisp actually can't help but make you rich. But I can't actually provide any examples of that happening or how they might translate to anyone else. Get so rich with Lisp. Lisp." Show me!
  - geocar 10mo ago
    I think you probably misunderstood 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.

johnfn 10mo ago

> 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.

wrs 10mo ago
In reality, most people, intelligent though they may be, don’t consider and reject Lisp, so that argument doesn’t really work. I know it irritates people who actually do consider and reject Lisp, but those people don’t realize that they’re a tiny elite who are not the target of these essays. There are plenty of reasons it might be better not to use Lisp, but very few people actually get as far as considering them.

chromaton 10mo ago

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.

tikhonj 10mo ago
> If it was as great as its advocates say, surely it would have taken over the world by now. That is a big assumption about the way popularity contests work.
- scragz 10mo ago
  free market brain.
- samdoesnothing 10mo ago
  If something is marginally better, it's not guaranteed to win out because markets aren't perfectly rational. However if something is 10x better than its competitors it will almost always win.
- hu3 10mo ago
  Invert the logic. 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".
ruricolist 10mo ago
The sketch here would be that Lisps used to be exceptionally resource-intensive, allowing closer-to-metal languages to proliferate and become the default. But nowadays even Common Lisp is a simple and lightweight language next to say Python or C++. Still it's hard to overcome the inertia of the past's massive investments in education in less abstraction-friendly languages.

RodgerTheGreat 10mo ago

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.

wrs 10mo ago
“Common, even”? Citation needed. I’ve worked closely with hundreds of developers over the years and maybe two of them made a conscious, knowledgeable choice whether to use Lisp for something. 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?
chihuahua 10mo ago
It would also be a lot more persuasive if the article provided even a single example of how Lisp enables superior solutions. 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."
- wrs 10mo ago

tra3 10mo ago

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?

didibus 10mo ago
I don't think you should use eLisp as your point of reference. It's the worst Lisp by far. Lisps are a continuum, and I still think there's room for new ones that are even better.
- tra3 10mo ago
  Can you tell me more about this, or point me in the right direction?

GMoromisato 10mo ago

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.

wrs 10mo ago
I’m writing a lot of Rust lately, which is rapidly becoming regarded as a conventional language, and I sure do appreciate all those things I use every day that end in exclamation points.
- GMoromisato 10mo ago
  I'm curious here, because I don't know Rust. What's the difference between a macro and a function call from the caller's perspective? Do I (as the caller) need to know I'm calling a macro? Why? Why is println! a macro when it's a function in almost all other languages?
  - wrs 10mo ago
    GCC can type-check printf (matching format string to arguments) because the compiler doesn’t just treat it like a function. But that requires special-case code in the C compiler itself that is basically opaque magic. 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 https://defmt.ferrous-systems.com/macros [1] https://docs.embassy.dev/embassy-stm32/git/stm32f301k6/macro.bind_interrupts.html https://docs.embassy.dev/embassy-stm32/git/stm32f301k6/macro...

nathan_compton 10mo ago

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.

antonvs 10mo ago
> If I had one thing I want fixed about Scheme it would be the dynamic typing 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.
- wild_egg 10mo ago
  None of the macro systems in those languages are really equivalent to lisp macros. If you really want static typing, Lisp macros are powerful enough to implement a full ML type system in userspace as a library. See https://coalton-lang.github.io https://coalton-lang.github.io
  - antonvs 10mo ago
    > None of the macro systems in those languages are really equivalent to lisp macros. 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!)

drivebyhooting 10mo ago

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.

zephen 10mo ago
IMO, Python was an acceptable lisp even before it grew generators and decorators. 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.

teaearlgraycold 10mo ago

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.

shrubble 10mo ago

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.

moffkalast 10mo ago

> 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?

philipwhiuk 10mo ago

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.

tmtvl 10mo ago
> 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.

djaowjxj 10mo ago

[flagged]

christophilus 10mo ago

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.

embedding-shape 10mo ago
> Also, Clojure’s start up time was off-putting, and would probably be even more so today, coming from Bun and Go. 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.
- chamomeal 10mo ago
  I also understand this is an issue for a lot of people but it’s never been an issue for me! I wouldn’t want it for serverless stuff I guess. But I would never think to do that lol

joeevans1000 10mo ago

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.

embedding-shape 10mo ago
I'm not sure I'd call a programmer "brilliant" if they cannot A) make a codebase simple enough for people to contribute to and B) handle the social parts of training someone to get good enough to contribute to the codebase.
- joeevans1000 10mo ago
  Agreed. And this is the real miss of much of the Clojure community. There is a handful of amazing people in there pulling 90% of the weight of bringing noobs in to the language. And the rest don't even seem to notice their efforts. Little awards and grants here and there, yes. But the majority don't even care if the language has wider adoption or not. It works for them and that's enough. But many of the successful projects are toy or side project ones. A large number have comically minimal UIs... sub useful in today's world. Quite a few Clojure programmers use 2D languages in their day jobs, only bringing Clojure in for small parts if at all. All of this is a top down vibe. The core team has never meaningfully addressed the terrible error messages the language spits out because they are able to decode the problem themselves. Empathy or concern for noobs or wanting to grow the language seems a far priority for them. The same for the cryptic documentation, seemingly written for themselves at best. Very talented people, mind you... just not concerned with the things that would have caused adoption of their entirely unadopted language (percentagewise).

layer8 10mo ago

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.

nateburke 10mo ago

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-software-slower/ https://blog.redplanetlabs.com/2025/06/17/make-worse-softwar...

tliltocatl 10mo ago

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

hulitu 10mo ago

> Learning new dimensions > You can’t persuade someone in 2D with 3D arguments. This is exactly like how in Flatland the sphere is unable to get the square to comprehend what “up” and “down” mean. Just like today's UX designers who need a 3D surface to draw a lousy rectangle.

hkon 10mo ago

I liked this post. But I was a bit disappointed when it ended so soon.

aidenn0 10mo ago

The power of macros is somewhat overblown and not at all hard to explain. 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. 1: https://peps.python.org/pep-0343/ https://peps.python.org/pep-0343/