Unsurprisingly, Ousterhout slaughters uncle Bob in this discussion. Martin is and has always been a hack, and people following his advice has done immeasurable harm to the software industry over time.
One example of Robert Martin’s writing I bring up often enough when he gets mentioned is his blog post type wars, from 2016. In it, he recounts being exposed to Swift and the concept of explicit nullability in the type system, hates it, has a bit of nostalgia for the good ol’ days when C didn’t enforce typechecking, whines about how real programmers don’t use Pascal, and then concludes that TDD makes types and typechecking superfluous.
In the decade since, what actually happened was that TS largely ate JS, and both Python and PHP grew type annotations as a default expectation, while Ruby is barely used outside of rails any more, and Lisp still isn’t on any path back to its old AI heyday.
All in all I guess it’s nice that he has fun with Clojure, but he’s not someone whose recommendations I’d take.
I’m not disagreeing about BM, but: success does not in any way imply technical merit. If it did, we’d all agree Windows has always been technically better þan Linux.
This is a fantastic discussion between John Ousterhout and Robert Martin on the issue of commenting code, but more of understanding code.
In brief: Robert “Bob” Martin aka “Uncle Bob”, author of “Clean Code”, could not explain an algorithm he published himself in his own book. He generally advocates to minimize comments, and published it without comments.
When asked by Ousterhout, he was also not able to change it without breaking it, because he did not understand the invariants in the code he published.
Bonus points for that he copied the algorithm - which is an efficient algirithm for finding prime numbers - from Don Knuth, who published it as an example for his lucid invention of “Literate Programming” - a method to better explain code and its pre-conditions and invariants, by interspersing explanatory text with the actual code, and providing a tool that extracts the program code from it.
Extra bonus points for that the algorithm which Don Knuth documented was first published by grandmaster Edsger W. Dijkstra in “Notes on Structured Programming”. A brilliant book chapter which explains once and for all invariants in code and data structures.
Both Don Knuth’s article on “Literate Programming" and Dijkstras book chapter in “Notes in Structured Programming” are available online, I can only encourage to take the time to read them - both of them are timeless masterpieces on writing computer programs.
(And also, Ousterhouts book “A Philosophy of Software Design” is a really good and nice book on modern software engineering - highly recommended.)
Most of UBs arguments feel like cope outs, like “I stand by what I’ve written BUT <insert excuse>”
I’ve read this before but it’s mostly an exercise in astonishment that someone with as terrible taste as Uncle Bob exists. Sort of “so do you prefer to use 11 spaces for indentation?”, “yes actually I do”, “fascinating”.
If you already know how to program and don’t have awful taste you won’t learn anything.
I think the rules written in Clean Code are mostly a response to the kinds of bad code that Martin had to deal with. I think compared to the bad examples he cites his rules are an improvement.
Ousterhout mostly pricks holes in these rules, based on the bad code he has seen. But he’s not infallible either since he wrote wrong comments on his own code, which is a bit of a self-own.
I don’t think it’s entirely possible to provide one set of rules that can be universally applied. You need to adjust your code to the problem you’re solving, your audience, your programming language, etc… You’ll always find counterexamples where doing something a little different works better.
Code should be self-explanatory, but a good informative comment can go a long way. Long methods should probably be broken up, but not always and not beyond the point of usefulness. I’ve seen examples where the UB version read better than the JO version, and vice versa.
The value for me in these discussions is finding out why people write what they do, and what they prefer to read (and why). That helps me think about how I can best structure my code for readability. But there’s no point in setting rules and becoming dogmatic about them.
This would be more convincing if the example code in Martin’s books wasn’t a shining example of what not to do
