3 ms·

I enjoyed this. Skipped through the parts about the inner NES workings, but the "embarrassing" video is more to the point and shorter. I found myself agreeing w

I enjoyed this. Skipped through the parts about the inner NES workings, but the "embarrassing" video is more to the point and shorter. I found myself agreeing with a lot of points and disagreeing with some too. It's interesting how many comments there are, here and on YouTube, along the lines of the examples being "bad code, regardless of OOP", "not representative of a large team/project", "unmaintainable", etc. without even a link to an example snippet or repo, let alone a narrated walkthrough of existing code and possible alternatives like the author has provided. Without concrete examples, all of these counter-arguments are in danger of a No True Scotsman fallacy. In fact, the code in the "embarrassing" video are actual examples of respected OO programmers showing how OOP should be done, which is a high bar to refute. The author also addresses this a little, by pointing out the often-invoked circular reasoning of "my software's a mess even though I followed OOP", "if it's a mess you must not have been doing OOP properly".

Chris2048 11y ago
Sometimes software methodologies are a little like the stone-soup story; vaguely defined such that when it turns out bad, you can always wriggle out of it by claiming it was done wrong, and there's a better way to do it that works. When you follow up for details, the full "right way" has such a high bar, no one but a few true believers are gonna actually follow it. I want a methodology that provides improvement on average, even with only partial uptake. Many other best-practises are independently virtuous, hence have this quality.