vessenes
3 hours ago
These modern readmes written by claude have this unusual combination of density and lack of information at the same time that I think is pretty interesting. I’ve generated many of them myself, and they largely read the same to me, without many of the distinctive “load-bearing” vocabulary tics that we see in so many places.
They seem to contain a mix of subject matter expert jargon and often some words that are created during the course of coding and end up encapsulating concepts, but it makes reading the documentation liminal — it’s like reading a tech spec from an alien. And I suppose it is, after all, a tech spec from an alien.
I think what I find both interesting and difficult and annoying (and, and, and) about them is that they fail to have a theory of mind for the reader — they are essentially the slightly manic notes one leaves for oneself after a 4 day coding binge, tarted up in markdown and published.
I’ve been experimenting with asking for documentation that specifies a reader and requests a theory of mind about that reader being applied to documentation, and it’s very helpful, but I don’t think I quite have it nailed yet. And I don’t think I understand why it is that these models, which have ingested an immense amount of technical documentation, still write like this.
whazor
2 hours ago
The goal is in the first paragraph: "aim was to let consumer gear that can't bitstream TrueHD Atmos render real object-based Atmos with height."
Summary is also clear: ffmpeg doesnt have channel coupling and proprietary cryptographic blocks it.
I was once wondering what would be the problem of doing such a project. Now it's clear to me what problems I would run into and I don't have to burn my tokens.
What answers are actually unclear for you?