This is an exhausting and dispiriting article to try to read because of its short, choppy, clearly AI-generated sentences. The topic is interesting, but whoever caused it to be penned didn’t seem to care enough to make it appealing to read.
Curious which parts specifically felt that way for you? I spent over a week on this, and yes ofc, I used LLMs to help reformulate some sections, but "didn't seem to care enough to make it appealing to read" isn't it. Happy to look at the spots that felt choppy if you can point them out.
> and yes ofc, I used LLMs to help reformulate some sections
???
Why in the world would that be an "ofc"?
If you're trying to establish yourself as a writer and communicator, LLM's are the last thing you want to color your personal voice with. They may have a role in cleaning up interpersonal communication or in helping non-professional communicators shape up their prose for formal occasions, but they are not some kind of magic neutral way to improve a writer's writing.
As you're seeing here, all that work would have been better received without the compromises and tells of LLM-ese because it would have been your writing, in your voice, as an intelligent analyst and communicator. The idiosyncrasies of that prose voice (your prose voice), are a durable signature that people come to associate with you individually and help them interpret tone, inflection, emphasis, insight in ways that the genericism and accent of an LLM scrubs out.
Give yourself more credit and don't do this; or at least don't treat it as an "of course"!
I also don't understand this. After having written something I never felt a need to have it reformulated by anything. What would even be the prompt for that?
Maybe "You are an expert editor. Polish this article for X demographic. Make no mistales."?
But jokes aside, I too prefer genuine human writing. Writing is complex enough that you can see a distinct style even if it's rough. LLMs tend to polish the roughness so much that everything reads like magazine ads.
I think it's easy for native speakers to say. But as English is not my mother tongue, I find it safer to run it through a checker and nowadays, LLMs. So maybe no need to be so harsh about it
I understand that motive. On the other hand, LLM smell makes the text untrustworthy. I have detected it as well, and I immediately started to wonder about whether I am reading a reasonable expert analysis or just an AI hallucination. I still don't know.
I recommend prompting the LLM to mostly fix glaring grammatical and stylistic mistakes, not to rewrite the entire thing into a LinkedIn post style text.
Have you ever had someone else edit your work, comment on it and provide alternative phrasings or organization? LLMs are pretty good at that, available any time and give instant results, as long as you understand that they work differently from a human reviewer - you can't expect it to be of the quality you'd get from a subject-matter expert or highly skilled writer, you have to lean into the LLM slot-machine model where you just get some alternative options. But it's incredibly useful when you're stuck in a rut with how to conceptualize or explain something, or even when you're not, and just want to visualize some alternatives that come from somewhere outside of your own head.
I think of it like a power thesaurus. Thesauruses get a bad rap for people just using them to look for ten-dollar words, but they're super useful for finding ways to articulate things differently, which can sometimes lead to bigger insights or ideas about restructuring the content.
It's on the author to look at what's suggested by the LLM and decide whether or not to use it, and there's an inherent danger in having one's voice overridden by simply accepting too many of the recommendations as-is. But that's between the author and the tool. I won't make any comment here on the article author's prose or how they maybe did or didn't use LLMs.
It starts in the very first paragraph. “The headlines say yes. […] The headline is wrong.”
And there are numerous such examples. “That was half true. The kill chain ran. The interceptor did not.”
LLMs produce staccato, ugly chains of sentence stumps like this all the time. They’re easy to spot, and your essay is littered with them.
If anything, spending a week on a project like this seems liable to blind you to the shortcomings of the prose, because after putting in a lot of effort you can’t read it with fresh eyes. That’s what editors are for, but an LLM is by nature very weak at editing LLM-generated text.
I want to be able to offer constructive feedback on the structure of the overall essay, for example that the interspersed animated/interactive models often don’t seem strongly connected to the text, but simply reading the words makes this a grind.
> That was half true. The kill chain ran. The interceptor did not.
That was one of the ones that particularly stood out to me. As I read the article, I often found myself wishing for semicolons and colons instead of full stops; or in some cases a comma and some conjunction:
> That was half true: the kill chain ran, but the interceptor did not.
The staccato style is often effective for emphasis, but the paragraphing is wrong on this article. It should've been:
> The headlines say yes.
> Patriot crews shot down a Kinzhal over Kyiv on the night of May 4, 2023. Arrow-3 batteries killed Iranian ballistic missiles over Tel Aviv in April and October 2024. A pair of THAAD batteries in Israel emptied something close to a quarter of the US national inventory across twelve days of war in June 2025. The headline word in every one of those engagements was hypersonic.
> The headline is wrong.
> No maneuvering boost-glide hypersonic vehicle has ever been fired in combat against a defended target. Every “hypersonic intercept” the press has reported in the last three years was a different class of weapon: an air-launched aeroballistic missile, a quasi-ballistic short-range ballistic missile with a maneuvering reentry vehicle, or in one case a MIRV bus on an intermediate-range ballistic missile that the press could not stop calling hypersonic. The Avangard, the only Russian vehicle that meets the strict definition, has sat in silos in Orenburg since 2019 without being touched. The Chinese DF-17 has never been used. The American Dark Eagle has not yet been ordered to fire.
> So when we ask “can you stop a hypersonic,” we are partly asking “what would happen if anyone fired one.”
There are assorted other issues with the article as well, like excessive use of passive voice, lack of parallelism, and too much meta-talk.
> the interspersed animated/interactive models often don't seem strongly connected to the text
It's indeed the part I struggled with most. The intent was to make the constraint more "visceral", so that the "the interceptor can't catch up" point becomes something you feel by dragging a slider and wtaching the gap grow. But you're right that I didn't do enough to stitch each properly into the prose around it. It reads a bit too adjacent to the text.
For what it's worth, an earlier draft was nearly twice the length and even included a small missile-interception game as the introduction. I think cutting it was the right call though.
Thanks for the notes! I'll keep this in mind for the next post.
> The intent was to make the constraint more "visceral", so that the "the interceptor can't catch up" point becomes something you feel by dragging a slider and wtaching the gap grow.
I don't know who the target audience is but if you talk about hitting supersonic missiles and kill chains, I don't think you need an interactive example to show that you can't hit a target that's faster than you if it has a head start.
"So can you stop a hypersonic? Sometimes, the wrong ones. Probably not the right ones, yet. The one defense working against the right ones today is a politician’s restraint, not a kill chain.
The worst one is still in its silo. And we are running out of interceptors against the second-worst ones."
It sounds like ChatGPT talking to me.
It's weird reading articles written by AI or helped by AI because it's a lot of words but no overarching narrative. It's almost like an expanded and fluffed up outline. It's very exhausting to read and I lose interest partway through. AI written text has a low "ROI".
AI code is similar. The individual parts are OK but even after reading the entire codebase it's hard to understand how it all fits together or what the over arching structure is.
(BTW, I don't mind what you're doing at all -- as long as you're honest and upfront about it. I love how you're exploring this way of working. I also love the widgets you embedded. It's cute but doesn't add a ton to understanding of the ideas in the article but it's the type of thing AI can really enable for writers.)
"Below it you are doing high-school physics. Above it you are running a small particle accelerator with a missile attached." is where I clocked out.
(Also "honest" assessments; the word "honest" has gone the way of "delve".)
Use LLMs to proofread and critique structure. Don't take a single word they generate and put it in your copy, not even simple vocabulary suggestions. The more work you put into a piece, the more important this rule is.
> ofc, I used LLMs to help reformulate some sections
This is not really meant to single you out, since there's a lot of this going around, but I really don't think this should be a matter of "of course". Why should it be the default to let a tool that doesn't have your context, or your voice, override your own usage of language?
He met the goal of conveying a lot of information. If he's only judged on what he said, and not how he said it, he did great. If I want to hear someone's voice, I'll watch YouTube.
> If I want to hear someone's voice, I'll watch YouTube.
I'm sure that in your head this is a witty rejoinder, but it really is quite a wild thing to say: that you place no value on the individual variations in how different human writers express themselves. It follows that you really don't care about voice on YouTube either, except in the most basic mechanical sense: you would be happy watching videos written by AI and narrated by the same monotone text-to-speech narrator, video after video, efficiently delivering that densely packed information you crave.
This is actually a thing, isn't it? Like those "shorts"
with the AI narration and matching subtitles flashing by in the middle of the screen. I guess you must love those---somebody does, probably a lot of people, or they wouldn't exist.
I'm tempted to frame this as a new kind of illiteracy. People whose brains are so addled by the modern media landscape that to get them to pay attention to anything at all you have to resort to tricks like this; god forbid they ever encounter a writer or narrator who speaks differently, sounds differently, thinks differently, frames differently. Nobody should be surprised, I suppose, that the ability to parse different levels of meaning in Content that falls outside the AI cognitive monoculture is a dying skill.
> The wallet was supposed to be the constraint. It turns out, as we will see, that the wallet is the constraint after all.
I can't tell if you made a mistake and meant the wallet isn't the constraint. These short burst sentences are really hard to read. Write "As we'll see, the constraint is x.". There's no need to split that, a single sentence conveys the whole point.
The article is full of similar wording, and that's why it feels choppy to read.
> The rest of this essay is about why that is harder than the press understands. And about a second problem hiding underneath it
I'd describe this as chain of thought writing. It's fine in casual conversation, with the words just tumbling out of our mouths, but it doesn't work in writing or speeches. There are so many ways the two concepts expressed there could be worded, combined or separated. "The press has an unfortunate tendency to use hyperbole and simple descriptions, but even with those stripped away there are deeper misconceptions..."
It's interesting that folks have honed in on AI as the problem. I'm my view the issue is that you haven't decided on your writing style, and as a non native speaker, you're unable to write a simple phrase and get AI to embellish it. Writing simple phrases is surprisingly difficult. Try making everything concise, with no repitition, and then adding style and flowery language afterwards.
Edit: sorry I may have read another person's comment about being a non native speaker. Writing concisely is something we can all work on.
"A 100 to 300 kW beam has perhaps one to three seconds of dwell on a hardened, ablating, plasma-shrouded glide body. That is orders of magnitude short of the joules per square centimetre needed for a thermal kill."
- wondering if you can elaborate more on whether a laser energy-based device would ever be able to have enough power to stop one of these?
> The honest answer to that question, in June 2026, is that we do not know
> The honest reading of those numbers is not that defense is winning on economics
> The honest 2026 answer is in three parts.
> The honest answer is that we do not know, because no one has tried
Firstly, I appreciated the article and especially the visuals. But I had the same reaction as the GP commenter. It was hard to read. I'm sick of this punchy, repetitive, LLM-generated prose.
Agreed, that's a huge turn off for me, and I thought this would genuinely be fascinating. I'm not a physics expert but I love reading about interesting things like this, but I can't stand this surface-level "well I in theory could be an expert on this topic but nobody knows because the machine removed all of the nuance and now it's shallow AI writing" style of writing.
Liberty Utilities has nothing to do with libertarian separatists. It's a brand name of Algonquin Power & Utilities Corp, a boring Canadian infrastructure conglomerate that buys regulated water, gas, and electric systems across North America. They bought this chunk of rural California grid from NV Energy in 2009. That's it.
This is sort of a revival and elaboration of some of Bram’s ideas from Codeville, an earlier effort that dates back to the early 2000s Cambrian explosion of DVCS.
Codeville also used a weave for storage and merge, a concept that originated with SCCS (and thence into Teamware and BitKeeper).
Codeville predates the introduction of CRDTs by almost a decade, and at least on the face of it the two concepts seem like a natural fit.
It was always kind of difficult to argue that weaves produced unambiguously better merge results (and more limited conflicts) than the more heuristically driven approaches of git, Mercurial, et al, because the edit histories required to produce test cases were difficult (at least for me) to reason about.
I like that Bram hasn’t let go of the problem, and is still trying out new ideas in the space.
In 2007 Bram said to me that my Causal Tree algorithm is a variant of weave. Which is broadly correct. In these 20 years, the family of weave-class algos grew quite big. In my 2020 article, I devoted the intro to making their family portrait https://arxiv.org/abs/2002.09511 Could have been a separate article.
The whole point of using a proper CRDT is that it's easy to reason about what it does. It took me a while to figure out the details of how to build one.
Note that CRDT isn't "a thing". The CRDT paper provides a way to think about and analyze eventually consistent replication mechanisms. So CRDTs weren't "introduced", only the "CRDT way of discussing replication". Every concrete mechanism described in the CRDT paper is very old, widely used for decades beforehand.
This means that everything that implements eventual consistency (including Git) is using "a CRDT".
While this is technically correct, folks discussing CRDTs in the context of text editing are typically thinking of a fairly specific family of algorithms, in which each character (or line) is assigned an immutable ID drawn from some abstract total order. That is the sense in which the original post uses the term (without mentioning a specific total order).
Really nice to see a solidly valuable project develop a sustainable foundation instead of turning into yet another VC-backed devtools startup that will inevitably die in a few years.
Rather thank IBM for paying Mitchell an outrageous amount of money for Hashicorp, so he can devote all of his time on awesome projects like Ghostty without ever thinking about sustainable income ever again.
While you're not wrong, I think this undersells a little how much Mitchell has given of his time to OSS. Yes, he's fortunate that he doesn't have to worry about money, but even when he did, he still contributed openly and freely.
That's part of what drew lots of us to HashiCorp in the first place - giving back.
It's a little tongue-in-cheek, but as you can see elsewhere in this discussion thread he mentions this himself on his own X account:
"get asked the same about terminals all the time. “How will you turn this into a business? What’s the monetization strategy?” The monetization strategy is that my bank account has 3 commas mate."
The obnoxious one here is the person obsessed with monetization, not the person who throws their ignorance back in their face. Every hobby these days has to be monetized; it's fucking gross.
Eh; it's maybe dumb to suggest the only way for a project to be sustainable is to monetize it, but responding with "I'm rich, you peasant, I'm above such concerns" is infinitely worse.
Free work is the most rewarding work on every metric but monetization in my experience, and when you hit road bumps you can pay your way out of it to keep going. Sounds like the literal dream
Without turning this into a brag session, this is my experience. I don't have to worry about money anymore, so I get to work on cool projects at my own pace, do things that probably sound pointless to most, and it doesn't matter if it's successful. The important thing is that I'm interested.
Money begets the freedom to work on causes. Monetization was always a core part of Hashicorp, rather than being a bolt-on after years of OSS. Which is a good thing. (I was a customer of the first commercial offering from Hashicorp, their VMWare add-on for Vagrant)
I always feel weird thanking IBM. On one hand, they've funded numerous FOSS projects, and made the thinkpad, an amazing CPU architecture (PPC), and seem to be the only ones actually innovating in the tech space sometimes. On the other hand, they bought Redhat and seem actively hostile to any FOSS projects that don't make them money
There are hundreds of thousands of software engineers who, given FU amounts of money, would absolutely keep writing software and do it only for the love of it. The companies that hire us usually make us sign promises that we won't work on side projects. Even if there are legal workarounds to that, it's not quite so simple.
Even still, whatever high salaries they do give us just flow right back into the neighborhoods through insane property values and other cost-of-living expenses that negate any gains. So, it’s always just the few of us who can win that lottery and truly break out of the cycle.
> whatever high salaries they do give us just flow right back into the neighborhoods through insane property values and other cost-of-living expenses that negate any gains. So, it’s always just the few of us who can win that lottery and truly break out of the cycle.
You break out of the cycle by selling your HCOL home and moving to LCOL after a few years. That HCOL home will have appreciated fast enough given the original purchase price that the growth alone would easily pay for a comparable home in a LCOL area. This is the story of my village in Texas, where Cali people have been buying literal mansions after moving out of their shitboxes in LA and the Bay Area.
moonlighting is permitted by law in California (companies legally can't prevent you from doing it, iiuc), as long as there's no conflict of interest with your main job...
"no conflict of interest" is basically meaningless if your day job is writing software. These clauses you sign are quite broad in what that scope of conflict could be.
Every company I've worked for has had very explicit rules that say, you must get written permission from someone at some director or VP level sign off on your "side project," open source or not.
You might want to check your company guidelines around this just to make sure you're safe.
I'm hoping they'll get around to supporting command-number for switching between windows[0]. command-` is fine but clunky as hell when you have more than three or four windows. Without command-number, I'm still stuck using iTerm2 as my daily driver.
(It'd be nice if it supported other standard macOS UI conventions[1] too)
A little unfair that this is downvoted. No search is like a dealbreaker for me. I'm happy with iTerm and for 99% of my use cases I don't need a "very fast" terminal. Thanks for pointing this out.
Seems I will wait a little longer before search is in the regular build (and not nightly ones)
You can't build a house without the foundation (pun intended).
I said in the linked post that I remain the largest donor, but this helps lay bricks such that we can build a sustainable community that doesn't rely on me financially or technically. There simply wasn't a vehicle before that others could even join in financially. Now there is.
All of the above was mentioned in the post. If you want more details, please read it. I assume you didn't.
I'll begin some donor reach out and donor relationship work eventually. The past few months has been enough work simply coordinating this process, meeting with accountants and lawyers to figure out the right path forward, meeting with other software foundations to determine proper processes etc. I'm going to take a breather, then hop back in. :)
How do you expect that to change? What is the next step in your mind? Maybe asking for donations? If only he would set up some way that the general public could contribute money to the project! That’d be the smart thing to do. Then he could write a blog post about it, and maybe someone would post a link to HN. That’d really be something.
To be fair, that one guy happens to be the OG Mitchell Hashimoto, who's worth a giant pile of money from selling terraform to IBM, and he's the guy actually writing it in the first place, so I don't think that's, like, a terrible horrible no good issue.
This is a bizarre essay by someone who understands neither functional programming nor the history of computers.
> To be kind, we’ve spent several decades twisting hardware to make the FP spherical cow work “faster”, at the expense of exponential growth in memory usage, and, some would argue, at the expense of increased fragility of software.
There is not one iota of support for functional programming in any modern CPU.
Totally agree. In addition, one of his examples (Mars Pathfinder) has absolutely nothing to do with functional programming or simplifying assumptions of any kind. The mars pathfinder problem was caused by a priority inversion on a mutex - exactly the sort of thing that all programmers rightly consider hard and that things like software transactional memory in FP would prevent. Here’s the famous email “What Really Happened on Mars?” which was written by the a pathfinder software engineer and explains the issue
The definition of spherical cow is also butchered beyond recognition.
Spherical cows are about simplifying assumptions that lead to absurd conclusions, not simplified models or simplified notation in general.
Calling functional programming a spherical cow when you mean that automatic memory management is a simplifying assumption, is such a gross sign of incompetence that nobody should keep reading the rest of the blog.
> Spherical cows are about simplifying assumptions that lead to absurd conclusions
There aren’t any commonly-accepted conclusions from spherical cows because the bit is the punch line. It’s a joke a physics 101 student makes when toughing through problems that assume away any real-world complexity and thus applicability.
Spherical cows, in the real world, are pedagogical tools first, approximations second, and mis-applied models by inexperienced practitioners third.
“Hello World” is a spherical cow. Simplifying assumptions about data are spherical cows. (And real dairy farmers implicitly assume flat cows when using square feet to determine how much room and grazing area they need per head.)
The joke as I recall it, was a physics student who brags that he can predict the winner of any horserace, so long as all of the horses were perfectly spherical perfectly elastic horses.
I'm actually not sure where cows came in, but maybe there's a different version of the joke out there.
The spherical cow joke generally goes that a farmer has some problems with his cows (maybe it’s how much milk they’re producing I don’t remember) and so his daughter says “you should ask my boyfriend to help - he’s a physicist and really clever”. So the farmer asks the boyfriend and he says “Well, assume the cows are spherical…”
The joke being because when you do mechanics you generally start modelling any problem with a lot of simplifying assumptions. In particular, that certain things are particles- spherical and uniform.
Trying to be as kind as possible in my interpretation of the article, my take was that the author got stock on the "spherical cow" analogy early on and couldn't let it go. I think there are nuggets of good ideas here which generally tries to talk to leaky abstractions and impedance mis-matches in general between hardware and software, but the author was stuck in spherical cow mode and the words all warped toward that flawed analogy.
This is a great example of why rewrites are often important, in both English essays and blogs as well as in software development. Don't get wedded to an idea too early, and if evidence starts piling up that you're going down a bad path, be fearless and don't be afraid of a partial or even total rewrite from the ground up.
yes. and the two nuggets I took were looking a Unix pipe as a concurrent processing notation and pointing out that the Unix R&D for great notations (or the communication thereof?) stopped right before splitting, cloning and merging concurrent streams. I've rarely seen scripts nicely setting up a DAG of named pipes. I'm not aware of a Unix standard tool that would organize a larger such DAG and make it maintainable and easily to debug.
To the best of my understanding, the author describes the structured imperative programming style used since the 70s as "functional" because most languages used since the 70s offer functions. If so, it makes sense to describe hardware is optimized for what the author calls "functional programming", since hardware has long been optimized for C compilers. It also makes sense to describe callbacks, async, then, thread-safety as extensions of this definition if "functional programming", because yes, they're extensions of structured imperative programming.
There are a few other models of programming, including what people actually call functional programming, or logical programming, or synchronous programming, or odder beasts such as term rewriting, digraphs, etc. And of course, each of them has its own tradeoffs.
But all in all, I don't feel that this article has anything to offer to readers.
The most credit I could give is that the post itself is a spherical approximation of the subject and the point being made is that they discovered async dataflow programming and think it's underrepresented. I've only seen it compared it to command-line pipes for explanation of the concept, not understanding implementation characteristics.
I agree that code tends to be overrepresented--we don't 'data golf'. Even non-async dataflow oriented programs are much easier to follow, which happens to play exceptionally well with FP.
If you squint so hard that SSA is functional programming[1] and register renaming is SSA, modern CPUs are kind of functional, but that of course has nothing to do with functional programming done by the user, it’s just the best way we know to exploit the state of the art in semiconductors to build CPUs that execute (ostensibly) serial programs.
What does that mean in the context of the comment you reply to - which includes the literal quote about "twisting hardware to make the FP spherical cow work faster”? The article may not be exclusively about FP but nobody said it was.
It's a theoretician's trope. "Identical and spherical" is the baseline state of the objects in a system one wishes to model. There's are several jokes with this as the punchline.
An executive is retiring. He's been very fond of horse races, but has been very responsible throughout the years. Now with some free time on his hands, he spends more time than ever at the tracks and collects large amounts of data. He takes his data, along with his conviction that he's certainly onto something, to a friend in research at a nearby university. He convinces his friend to take a look at his data and find a model they can use to win at betting. After many delays, and the researcher becoming more disheveled over months of work, he returns to the retired executive to explain his model. He begins "if we assume all the horses are identical and spherical..."
That author uses it to mean “model”, as he calls a variety of programming models “spherical cows”.
Well, for sure, a core tenet of computer science is that all models of computing are equally powerful in what inputs they can map to what outputs, if you set aside any other details
I too am generally skeptical of Facebook posts, but this wasn't just some random Facebook user, it was an official post from the Placer County Sheriff's Office. In fact the CBS13 article is simply repeating what the Sherriff's Office had already reported in their Facebook and Twitter posts.
Services like the Internet Archive have a hard time, if they're able to at all, archiving Twitter and Facebook social posts, so having alternate sources is helpful in that regard.
Let me put Mike's comment into what I think is its proper context. "Poor support for numerical computing" really means "relative to Mike's dream, which is not actually realisable by any programming language today" :-)
Most readers seem to be misinterpreting Mike as anchoring off other popular programming languages of today, whereas he's looking for language features for which there's (a) no consensus that they'll actually be good when they exist, and (b) don't yet exist. (I'm highly skeptical of dependently typed programming.)
I think that there's a case to be made that numeric programming in Haskell, relative to the state of the art of today rather than the year 2100, really isn't so great – but my concerns are very different than Mike's, and revolve around libraries rather than type system features.
I do think that matlab/python are a bit better numerical programming languages than Haskell as-is, but only marginally. This is not just due to the library ecosystem, but also because I think that dynamic languages really are better than the best Haskell2010/GHC8.2 library theoretically possible. There are just some things that the existing type system makes a bit more awkward.
reply