site banner

Culture War Roundup for the week of May 25, 2026

This weekly roundup thread is intended for all culture war posts. 'Culture war' is vaguely defined, but it basically means controversial issues that fall along set tribal lines. Arguments over culture war issues generate a lot of heat and little light, and few deeply entrenched people ever change their minds. This thread is for voicing opinions and analyzing the state of the discussion while trying to optimize for light over heat.

Optimistically, we think that engaging with people you disagree with is worth your time, and so is being nice! Pessimistically, there are many dynamics that can lead discussions on Culture War topics to become unproductive. There's a human tendency to divide along tribal lines, praising your ingroup and vilifying your outgroup - and if you think you find it easy to criticize your ingroup, then it may be that your outgroup is not who you think it is. Extremists with opposing positions can feed off each other, highlighting each other's worst points to justify their own angry rhetoric, which becomes in turn a new example of bad behavior for the other side to highlight.

We would like to avoid these negative dynamics. Accordingly, we ask that you do not use this thread for waging the Culture War. Examples of waging the Culture War:

  • Shaming.

  • Attempting to 'build consensus' or enforce ideological conformity.

  • Making sweeping generalizations to vilify a group you dislike.

  • Recruiting for a cause.

  • Posting links that could be summarized as 'Boo outgroup!' Basically, if your content is 'Can you believe what Those People did this week?' then you should either refrain from posting, or do some very patient work to contextualize and/or steel-man the relevant viewpoint.

In general, you should argue to understand, not to win. This thread is not territory to be claimed by one group or another; indeed, the aim is to have many different viewpoints represented here. Thus, we also ask that you follow some guidelines:

  • Speak plainly. Avoid sarcasm and mockery. When disagreeing with someone, state your objections explicitly.

  • Be as precise and charitable as you can. Don't paraphrase unflatteringly.

  • Don't imply that someone said something they did not say, even if you think it follows from what they said.

  • Write like everyone is reading and you want them to be included in the discussion.

On an ad hoc basis, the mods will try to compile a list of the best posts/comments from the previous week, posted in Quality Contribution threads and archived at /r/TheThread. You may nominate a comment for this list by clicking on 'report' at the bottom of the post and typing 'Actually a quality contribution' as the report reason.

4
Jump in the discussion.

No email address required.

I don't follow your technical aside. Isn't the point of an isomorphism that all the isomorphisms are the same in the sense in which you are isomorphic?

I can prove that True|False and Yes|No are isomorphic, but I can do so in multiple ways: I can map True to Yes and False to No, or I can map True to No and False to Yes (and then show that there are respective inverses which preserve identity, obviously)

I don't understand this example, because if you have A|B, A+A = A, B+B=B, but if A+B=A then A maps to true and if A+B=B then B maps to true.

The classical-style logic in the preceding paragraph does not apply to constructivist logic used for software formalisation!

But how? Like, what is the failure mode that you might get if you try to prove the correctness of a program for which this disquisition about isomorphisms is relevant?

I'm not sure I follow your confusion. In a strictly mathematical sense, you may have equivalence, but if you publish your paper in the world where electrons have positive charge and everyone else publishes their paper in the world where they have negative charge, well… you can see how this appeal to "Well they’re equivalent either way 🤷‍♂️" is both technically correct and also asinine.

But it's not just this sense: in the bool example, there's only one bit of information at play, but say you're talking about something more complicated like graph isomorphism or SAT solving. The representation of the problem matters a lot in practice! You can famously write a SAT solver in a single line of Haskell code, but you can also do it in 60,000+ lines of low-level systems code. I'm sure you can guess which is the useless party trick and which is the industrial-grade SAT solver. But even more relevant is that the technical curiosity is, in a strictly mathematical sense, more correct! The industrial-grade SAT solver has a maximum variable count just by the fact that it labels them with 32-bit ints, which is obviously ridiculous by theoretical standards: there’s no magical limit on the number of variables you can have in a SAT problem.

So, let’s say we’re interested in proving the correctness of a SAT solver. I bet there are a fair number of people who’ve played around with Lean and similar systems who would have a fair shot at proving the party trick correct.

There’s not a single person on the planet who stands a shot at proving the industrial SAT solver correct, nor is there likely to be within a thousand years.

And this is how it always is! There is this enormous disconnect between the truly formal representation of a system and "equivalent" (in any colloquial sense) real-world systems anyone cares about, even for systems that are themselves formal fields of study like SAT (much less anything an MBA would consider “real world”, like whether his website is secure).

The reason money has any interest in Lean 4 beyond "the government will give me a tax deduction for my charitable donation" is because we want systems to stop being so broken, and formal verification is supposed to help with that.

My point is just that there are… asterisks. A lot of asterisks.