There are some good ideas here, and this is a historical document for CS like the Gettysburg Address is for the USA, but your average freshman English instructo

There are some good ideas here, and this is a historical document for CS like the Gettysburg Address is for the USA, but your average freshman English instructor could offer a lot of suggestions for improvement if this were a class assignment. It could be said in about half the length (something Lincoln was good at!), and you don't need to invoke Galileo every time you're critcizing "the way things are done around here". On some substantial points, the author is clearly correct: mathematics has proof checkers and proof assistants, and may soon have AI support as well. Computers are a thing. (Yes, I know who the author is. But I'm critiquing the text, not the person.) I'll give the author what I think is their central argument: programming is a mathematical-intellectual discipline, not some form of glorified HVAC maintenance where you simply have data instead of water flowing through your pipes. I've never yet had to clean rust off a shell pipeline. More formalised methods for programming (even if they are called 'Rust') and other structures such as type systems absolutely need to be taught and used, where appropriate. Full-on formal methods have their place, but that place is a small minority of all code. I don't fully agree with the criticism of reasoning by analogy. Surely what matters is whether there really is an analogy or not, or as a categorist would say, you have a morphism not just a mapping. Reasoning about cars from horses doesn't work because there is not much analogy here. Reasoning about the property of the as yet undiscovered Element 31 from the properties of the known element 13 (Aluminium), and the fact that elements N = 14, 15 etc. seemed to be similar to elements N + 28, worked out well. At the time, of course, the analogy was phrased in terms of atomic weights rather than element numbers - the fact that these analogies worked out more often than not led to the hypothesis that there was something deeper going on here, which led to the invention of the periodic table (and element numbers). This is all proper Science (TM), not mediaeval scholasticism. "Programming tools" - look, I like VS code with old-fashioned intellisense, even if you have to turn off the AI crap nowadays. I also like git, for that matter. And syntax highlighting, and visual diff, and compiler errors being red underlined in the source code, and Control+Click on a function name taking me to its definition (usually). I can program in nano when I need to, but not when I have the choice. Maybe for some of the younger generation, they won't be able to imagine programming without an AI copilot. The author here is falling into their own trap, first explaining why mathematics can be revolutionized by tools (such as computers) but then asserting that of course programming cannot. Oops. I'll give them that perhaps 80% of proposed programming (teaching) tools are rubbish, and maybe that was closer to 100% back in the day, and every few months some new low-code/no-code "solution" appears, but that doesn't mean there aren't good ones out there. I usually yawn at any mention of the "testing can only reveal the presence of bugs". Yes, and then you can fix all the bugs that were revealed! Well-tested code (that requires some thinking about what to test - see "A QA engineer walks into a bar") has far, far fewer bugs than non-tested code. Some coding interviews expect you to test your code without being told explicitly to do so. It turns out, you can get something like 80% of the benefit of "formal methods" with 20% of the effort, and without having to switch your programming language.