When a programmer is adding ugly code to the codebase, he is making a marriage proposal. Unless the prospect with him or her (till death dues you part) is appealing, work to remove the offending code before children start coming in.
Have I been out of the programming world for too long, or do at least some of his complaints refer to using advanced features of programming languages in essentially the way they were intended?
You kinda have, basically there's been a mass epiphany that using most 'advanced' programming features tends to actually increase total lines of code and complexity for no discernible benefit.
It's a corollary from the idea that if you think you just wrote something really clever, you probably just wrote an unmaintainable mess that no-one else will really understand and will haunt you for a long time.
It's kinda one of those unsaid assumptions that everyone suddenly knew and yet no-one's really vocalised. Apart from maybe Yegge, I have a vague recollection that one of his articles touched on it.
He's talking in the context of console game programming (though it applies to everything). The current generation of consoles has pushed a lot of this stuff to the forefront - with in-order processors and cache behavior in particular exposing the flaws inherent in OOP/Inheritance based paradigms. I'd guess that it's a bit of a perfect storm - inflow of PC developers who previously could rely on hardware upgrades, massive increase in fresh/grad programmers (who are now filling positions on enormous teams of programmers compared to previous generations), and much more PC-like hardware that requires less specialized programming.
It's hugely important in console game programming to know exactly how you're using the system's resources - memory and clock cycles. The styles he's criticizing aren't just bad for limiting resource usage, they're hard to analyze. On top of that, it can be very difficult to silo components of game code (and game engines) behind nice clean interfaces. When you're the engine programmer tasked with optimizing game code because you're the one who knows how to squeeze performance out of the console, you don't want to have to climb up and down hierarchies to figure out where everything's hidden. I've been there - it's especially prominent in 3rd party developers with cross-platform game engines - and it's a nightmare.
Ugh. That's the one I'm continually running across. Inheritance is so heavily abused by novice programmers they shouldn't be allowed to use it without a twenty page written justification.
I can understand where he is coming from, but I wonder if he's ever experienced the other end of the spectrum, where everything is a quick hack, leaving you with methods that are 1000 lines long, in a class which is 10000 lines long. Oh man how I miss the days of 10 nested if statements! Code is so much easier to read!
And is he really bashing inheritance? Really?
Patterns: oh no a common way to approach a problem! But I want to come up with my own hack! That's real job security.
I don't find it hard to use inheritance, interfaces, patterns, etc. I do see a problem with using some of these tools when they are not needed, but honestly, I've seen the world where they are not used, and I'd rather overuse patterns etc.
10 comments
[ 2.7 ms ] story [ 34.5 ms ] thread(And I can say this because I've written asinine, passive-aggressive blog posts to boost the ego myself)
It's a corollary from the idea that if you think you just wrote something really clever, you probably just wrote an unmaintainable mess that no-one else will really understand and will haunt you for a long time.
It's kinda one of those unsaid assumptions that everyone suddenly knew and yet no-one's really vocalised. Apart from maybe Yegge, I have a vague recollection that one of his articles touched on it.
It's hugely important in console game programming to know exactly how you're using the system's resources - memory and clock cycles. The styles he's criticizing aren't just bad for limiting resource usage, they're hard to analyze. On top of that, it can be very difficult to silo components of game code (and game engines) behind nice clean interfaces. When you're the engine programmer tasked with optimizing game code because you're the one who knows how to squeeze performance out of the console, you don't want to have to climb up and down hierarchies to figure out where everything's hidden. I've been there - it's especially prominent in 3rd party developers with cross-platform game engines - and it's a nightmare.
Ugh. That's the one I'm continually running across. Inheritance is so heavily abused by novice programmers they shouldn't be allowed to use it without a twenty page written justification.
And is he really bashing inheritance? Really?
Patterns: oh no a common way to approach a problem! But I want to come up with my own hack! That's real job security.
I don't find it hard to use inheritance, interfaces, patterns, etc. I do see a problem with using some of these tools when they are not needed, but honestly, I've seen the world where they are not used, and I'd rather overuse patterns etc.