I like that recently there's been a meme floating around, started by one good blog post that got a lot of airtime, of posting and then talking about controversial opinions in programming; there are necessarily a lot of disagreements among programmers on how best to practice the art/engineering, bringing in personal risk aversion/embracement strategies as well as types of programmer (systems geeks versus graphics programmers versus...). Having conversations that are respectful to the people but disrespectful to the positions is a great way to hash all that stuff out and learn from each other, even if it's sometimes uncomfortable.
I particularly liked this one.
- I disagree that OOP should be introduced late; I concede that some kinds of OO make it hard to reason about code (is that the serialise() method of this class or that class or was it bound specifically to some object? Can be hard to track down a bug if the object type is only known at runtime; good tools help a lot), but I think objects-and-methods-with-methods-having-t
heir-own-namespace is great for organisation, and ideally you have good enough unit tests for classes that most kinds of bug become visible in them rather than in running code. I would introduce OO alongside a variety of other programming styles after some intro language were taught to a reasonable level (I'd suggest Python for that).
- I hope the complex optimisations are only enabled in anything like a default set of flags when people have reasoned enough about them to know that they're not likely to misbehave that way. Besides, reasoning about performance, at least with the kinds of compilers we have nowadays, isn't going to usually be changed that much by some flags. I'd rather go with the classic perspective of "optimise when you know you need to"
- I am inclined to agree with the idea of not designing interfaces for others until later, although some good training about library etiquette could reduce that "ten years" factor considerably. People should learn code refactoring when learning to code, and that'd make them close to being qualified a lot earlier.
- I think the "superficially ugly code is irrelevant" is missing the point; consistent and/or expressive formatting makes it easier to reason about the code. Mechanical fiddling isn't what these choices amount to; if we were to take a great novel and pass it through an automatic paraphraser, it would lose a lot in one dimension of goodness. Formatting isn't all there is to code, but it's part of it. Not a useless part.
- Mostly agreed on purely functional programming, although for some toylike or odd domains it does.
- I think it would be a mistake to extend his last point very far ("a software engineering mindset can prevent you from making great things"); an edge case doesn't justify bad practice (even as an excessively bureaucratic approach to coding is itself bad practics)