Edit: And if so, was it for help with English? Or another reason?
One constructive point for you: don't even write the first draft of a document you want humans to read with AI. It's much harder to get the AI voice out than it seems. Stuart Halloway talked about this at the last Clojure Conj, and I couldn't agree more. It also makes it harder to follow the sage writing advice to minimize what you write.
"How code keeps its family resemblance" - AI would say this, a person would not. It's just noise on the page.
"Measure only their shape and you can still tell who copied whom" - this is a sentence structure Claude loves, but no human would talk about "measuring" shapes. The verbs and the nouns don't feel right.
Then you start a paragraph: "DOOM is the perfect place to test it." But you don't actually say what "it" is specifically. It doesn't seem like AI would write that though... Maybe you did in a later draft? It's hard to switch voices, like switching authors.
If you want people to read something, write it yourself.
At this point I am not sure I wouldn't get a very similar output if I just prompt Claude for the genealogy of Doom ports as an interactive dashboard. Maybe try to deviate from that, even if that would rank lower on a model benchmark: you don't have to provide an interactive data visualization for everything. You can narrate a story from your own opinionated pov.
I concur with the other comment that it's an interesting idea, but you should just write the article yourself. You can even link to the technical details so that those who are interested in exploring that data can do so. But as-is it's really a good example of AI slop.
And, I like the article, once I got through the 'jolt'. (Not gonna call it slop, I can tell it a good amount of effort on your part to make it present the data well.)
I love Doom, and I love the genealogy of it; dealing with doom modding and dehacked was probably my first foray into any sort of concept of 'programming' (after all, you could do some curious things with dehacked, as far as 'next frame' and how that sometimes could change things in curious ways)
I think, to give some constructive feedback;
1. Consider taking a markdown/output from analysis and writing your own starting scaffold.
2. Make sure to review the output and tweak it.
3. Hand refine what the end result is.
I'm not saying you shouldn't use AI to help with some of this, I'm just saying, that will help so much more. Cause this is really cool, but yeah it would be nice to have more polish around it.
I fondly remember getting the DOOM hackers guide from barnes and noble in HS. Those were the days.
Slop.
First of all, I can only take so many "the hard case", "the fun part" and "the real test" before you've exhausted my attention to what these phrasings suggest are exceptionally interesting things.
Second,
> Scramble the Go program's wiring, keeping how many calls each function makes, and it drops to 39%: the wiring itself carries much of the signal.
What wiring? What signal? The rest of the article refers frequently to these completely useless analogies without ever clarifying what they mean. After scratching my head over it for a while I'm only guessing that the "wiring" refers to function names and "signal" to their bodies? Why not refer to these very basic, simple concepts as they are? I could understand coming up with analogies (good ones though, not awful ones like these) if you were writing for a non-technical audience, but you're not.
> Across languages only the wiring carries a signal, and only for the closer translations.
WTF does this even mean?
> he Scheme and Go translations keep the original's wiring as far above chance as Chocolate Doom does. The Dart translation keeps some. The Fortran, Java, Kotlin and C# translations keep none, and programs written from scratch, or not related to DOOM at all, sit at chance, as they should. Don't take our word for it: draw the maps yourself.
Sit at chance? Why shouldn't I trust your word for it if I can trust your diagrams?
Please, if you want me to think something is interesting, the least convincing thing you can do is to offload writing about it to whatever trite generator shat this out.
.claude/skills/popsci-interactive-article/SKILL.md isn't always enough to get you there.
Whatever it's architecture is, porting in is trivial because it's not a hard problem.
It's a great game and its geneious is undeniable. But porting a 1993 game is not really going to tell you anything interesting about "How code structure survives across 44 ports".