[flagged]
The programmers who live in Flatland
91–100 of 153 posts
Re: The programmers who live in Flatland
#92In 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.
Re: The programmers who live in Flatland
#93I 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.
Re: The programmers who live in Flatland
#94I 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 hand…
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.
Re: The programmers who live in Flatland
#95In 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…
> 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.
Re: The programmers who live in Flatland
#96I 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 hand…
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.
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).
Re: The programmers who live in Flatland
#97Macros 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.
Re: The programmers who live in Flatland
#98I really enjoyed the preemptive comments at the end of one of his other blog posts:
https://blog.redplanetlabs.com/2025/06/17/make-worse-softwar...
Re: The programmers who live in Flatland
#99Or 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…
C for systems programming, javascript for everything else!
Re: The programmers who live in Flatland
#100Earlier quoted context omitted.
Clojure is built on dynamic typing. This is pain. I wrote enough Python (pre-mypy), Javascript, and elisp to say this. Past certain size a dynamically typed codebase becomes needlessly hard to wrangle because of that. Hence the success of Python type annotations and Typescript. Instead, the world should have seen the light of Hindley-Milner type systems, ML-inspired languages, immutability, or at least not sharing mu…
Plenty of ways to define complex data shapes in Clojure 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…
This indeed is one of the superpowers. I hope Elixir will eventually acquire it.