When a clinician’s ideology about a medication overrides the observable evidence of your functioning, the tool has stopped serving the human. The human is now serving the tool.

The pattern across all of this is the same pattern I spent my software career fighting. The system is optimized for its own internals: diagnostic categories, billing codes, school-of-thought loyalties, liability management, practitioner comfort. The human is expected to adapt to the system. A patient must learn the system’s language, absorb its labels as identity, accept its theological disputes being fought across their body chemistry, and survive its gatekeeping, all while sick. That is exactly backwards, and it is backwards in the precise way urllib2 was backwards: the machinery’s convenience placed upstream of the human’s need.

via: https://slimemoldtimemold.com/2026/07/31/links-for-july-2026/

Structured cospans are a categorical method for turning closed systems into open ones. We show how structured cospans of Petri nets can be used to construct complex epidemiological models in a compositional way.

Very interesting, although it went over my head a bit.

This shit is gonna make me cry, man. I gotta fucking read this guy’s book.

see: https://www.youtube.com/watch?v=IF1-15J2DWY

What is a scientific model? This post considers how mathematical logic and category theory can help us understand scientific models, and how AlgebraicJulia aims to build modeling frameworks based on this understanding.

A little awkwardly written, but important nonetheless.

see: https://topos.institute/blog/2021-11-04-categorical-systems-theory/

Pretty much every organization finds it easy to reward “productivity” as expressed by lines of code emitted, but the benefits of doing thorough and thoughtful design, analysis, and code review very difficult to reward. In this world, an LLM is an invaluable tool for the sociopathic ladder-climber, particularly if your legacy organization is still structuring their workflows as if the person prompting the bot is “writing” the code, and then they get to foist off the act of “reviewing” the code onto someone else. / Here, the prompter effectively externalizes the cost of the LLM’s failures but internalizes any benefits.

When a student is asked to write an essay, the teachers see the effort as both intrinsically worthwhile for the student, as well as useful as a pedagogical tool to evaluate and react to the student’s progress. The student, by contrast, sees a stumbling block designed to knock them off the path to success and into a permanent underclass.

via: https://liamoc.net/forest/2026-W26/index.xml

With reference to SNAP as an illustration

Ballerina is an open-source programming language for the cloud that makes it easier to use, combine and create network services.

A very interesting idea for a programming language which, for better or worse, I never got around to using. Would likely be a lot more interesting if I actually had infra to maintain.

On this episode of Overthink, Ellie, and David discuss the history and philosophy of marriage. Why do married people in the U.S. receive over 1,000 legal benefits that single people do not? Ellie and David dive into Foucault’s analysis of ancient Roman marriage and Hegel’s idea that marriage unites the subjective and objective spheres. Then the two discuss the way it’s been used bio-politically, as well as queer critiques of marriage. They also discuss minimal marriage as a solution, how the average wedding in America costs thirty thousand dollars, their own experience with the idea of marriage, and much more!

Catagolue is an online database of objects in Conway’s Game of Life and similar cellular automata. It gathers data from a distributed search of random initial configurations and records the eventual decay products.

via: https://www.youtube.com/watch?v=QK_KZv-YyOc

An extremely pretty video on cellular automata.

Guest post by Sorbie Richner

For many years, on and off in my teens and twenties, I was treated by a psychodynamic psychologist. One of the greatest strengths of our work together was that she didn’t fear my suicidality. She believed that suicidality, like any “psychopathology” or “maladaptive” behavior, was a mechanism that served some kind of intrapsychic purpose. She was able to hear me say “I want to die” and instead of immediately carting me to the hospital, she would let it be what it was. She would move closer to it instead of running away from it or rejecting it. Instead of trying to squelch it or exorcise it, she would say, “I don’t want to take away something that you need.” Her primary concern was not the suicidality would do to me, but what it was doing there in the first place.

Bidirectional tools can often be used for unidirectional use cases, but they are also usually designed with those two specific languages in mind, which constrains the utility of the underlying bindings for work with other languages. You can’t use the bindings as a neutral “hub” that many languages radiate out from.

What lets the same algorithm work across all three domains is that they share two key properties:

1. Closure under negation and intersection — so the difference between two candidates is itself expressible.
2. Sampling from that difference — so the system can show the user concrete cases where the candidates disagree.

This is just Ought’s Factored Cognition paradigm again, just now contrasted with the currently popular agent paradigm. A bit disappointed that he didn’t cite prior art.

Apparently, he’s now doing AI systems research at a showy VC fund? :/

You probably recognise these things as good, but a surprising number of managers seem to think they can just chastise people until quality improves. They talk themselves into this because they believe line workers are fully responsible for their actions.

But even those managers will find it very hard to convince themselves quality improves when they scream at the code-generating robot. It’s a robot! It can’t be responsible for its actions. We have to adopt the lean philosophy for building systems around robots. When something goes wrong, we have to blame the process, not the robot.

We always had to do that, even with people, but with robots it’s painfully obvious.

A tiny, anecdotal bit of context for this story:

My dad was an assistant warden at a county prison when I was growing up. Over 30 years ago he sat me down in his office one day and showed me how he could look up anyone he wanted in their databases, which had demographic information, information about criminal records, last known location, all sorts of things in what today would look like a charming ASCII art interface resembling old school dbase (probably written in it). He said he always looked up men my female cousins were dating, and showed me one. Many of his pals were in law enforcement and I got the sense that this was a widespread practice, something they all knew they shouldn’t be doing but routinely did anyway. He tried to convince me that I should get into writing software like this prisonware. I never did that or anything like it. I still feel a little guilty about what I saw that day decades ago.

The part where work actually feels like it matters. If your revolution is all grim refusal and no joy, I feel for you, and I think you’re doing it wrong, or being forced into it, or you’ve been value-captured by a different set of metrics.

via: https://jimmyhmiller.com/legibility-is-ruining-you

Mirror of Daniel Colasciones great blog post about emacs’ inner workings

via: https://kevinlynagh.com/newsletter/2026_05_difftron/

In Rules: A Short History of What We Live By, Lorraine Daston distinguishes between thick and thin rules. Thin rules are the algorithmic, mechanistic rules we in software favor; they are rules that can be obeyed and enforced unambiguously. Thick rules, on the other hand, are rules of thumb; they are guiding principles. Daston shows how there has been a historical progression from thick to thin rules. That today, we almost always think of rules as this thin, algorithmic process.

Cites C. Thi Nguyen.

via: https://kevinlynagh.com/newsletter/2026_05_difftron/