N/A
6:34 Yes, for example in Minecraft. Armour stands were at some point decided to inherit the "mob" class (which normally deals with sheep, zombies, dragons, etc. and not items, XP orbs, arrows, etc.), because they share a bunch of properties (gravity, flushed by water, get destroyed when attacked enough, can "wear" armour, …), so pretty much every time something new gets added that does something to all mobs, it almost always has a few bugs with armour stand in the first snapshot, which then need to get special-cased out in the armour stand class later. For example when a new enemy gets added that attacks everything, then it also attacks armour stands.
@3rdman99
"Speculative generalization" is a good phrase. I was looking for a phrase that is analogous to "premature optimization" in terms of premature generalizations that I've seen many, many programmers do (especially the ones who think themselves as very "smart"), and it's just as prevalent in the programming world as premature-optimization, and your description of "speculative generalization" is exactly what I was thinking. It should be taken with the same amount of skepticism and perhaps derision as the premature optimization whenever one sees it, since the speculative/premature generalization makes the code less maintainable, and (somewhat ironically but also predictably) makes the code a lot harder to be generalized down the road according to the ACTUAL requirements. It should be taught to everybody as one of the "anti-patterns".
@shaunpatrick8345
That wasn't real OOP. Real OOP has never been tried.
@BenRangel
I'm loving this video series. I was taught OOP in college, but I quickly grew resentful of things like inheritance and over-complicated encapsulation. But I've had a hard time defining and naming which kind of programming style I actually do advocate. This series has helped me a lot with that.
@josephfatur1747
Glad to see an update. Watched "OOP is Bad" several times. Excellent advice.
@SimGunther
"This is not the OOP I had in mind" - Alan Kay, 1997 OOPSLA in reference to Java/C++
@willmcpherson2
9:15 I have always felt this way about OOP, but I can never tell whether it's my inability to understand the code or the code's inability to be understandable.
@Cyberfoxxy
15 years in. There has never really been a time where speculation turned out in my favour. Everytime the boss comes around with a new idea which my speculation did not predict. As such my glorious framework coudln't accomdate this "rapid iterating". wasted time, and had to be redsigned a lot, didn't prevent bugs anyway. Nowadays. I just make the code as bare-bones as possible. Cleanup where neccesary.
@blood_rose_queen
By the time this man made this video, react was still mostly OOP. Now, most of that part is deprecated in favor of modularization and functional programming. Not only that, but this is more and more becoming the norm amongst widely used frameworks. In other words, this man was a visionary many years ago despite many people calling him crazy
@baconsledge
Best narratives on OOP and procedural programming. Brian gets it and can explain it!
N/A
9:23 Oh yes, I had to work in such a codebase for a while… A method "doThing" called a method "doTheThing", which called "doThatThing", which called "reallyDoThing"… and then it often eventually just lead to a library method, of which the source code was not available.
@UliTroyo
This video was released a few hours ago, so I’m assuming everyone who’s commenting actively follows the channel... so what’s the confusion? People are complaining that no code was shown or that Brian is flip-flopping, but if you’ve watched his videos... he’s explained this before, and given many code examples. Brian’s problem with OO has always been abstraction for abstraction’s sake. He’s demonstrated how imperative code is more straightforward and gives a clearer picture of the system rather than the individual part, and he’s argued that context is important to software—that a developer should be expected to understand the system and not just the arbitrary chunk of logic. This video just expands on these ideas. Watch his other vids if you’re still confused; it’s there; it’s good stuff.
@MrBranh0913
OO modularizes speculatively. Honestly I couldn't have said it better myself. I'm a Go developer and I recently started a job with a lot of Java developers. It's been hard having to go through these code bases that are overly abstract for the sake of abstract. Leading to simple things being done in complex ways. Go and to a lesser extent Rust are really going to save this industry. Go emphasis on simplicity has made my designs far more focused and minimal. And Ilve these videos that patiently deconstruct the dogma of OOP. As a former Java developer it even took me years to unlearn my brainwashing of OOP. I wish there were more people out here talking about this stuff. I also think young developers need to year these ideas.
@ethanbarnhart7714
I think anyone worth their salt who's coded for more than a couple weeks in a dynamic language celebrated for OO, like C#, Java, Ruby, etc begins to pick up procedural coding habits out of necessity whether they realize it or not. Even if they think their doing OOP. I tend to think OOP is pretty useful for dealing with dependancy, probably as a bias because it's what I cut my teeth on before going back to learn K&R C. But I also agree with about 95% of what you've said in these videos. In all honesty OOP and it's gurus just have bad theory and a Messianic complex, and anyone who follows their conventions will eventually get sick breaking themselves on the rocks of endless encapsulation and debugging for the stupid class interactions and inheritance they write for themselves, and just say "fuck this noise." And look to static classes and static methods called from main for their salvation because it easier to have one throat to choke when something breaks.
@davidnaegle5911
I'm happy to see a voice of sanity in sea of "fad followers". Thanks for the time and effort to make this series!
@LudwigvanBeethoven2
I programmed for 3 years with OOP in mind and could never do it perfectly. Not even decently, i always wasted time on thinking about abstractions, there goes 3 years wasting my time on OOP, how ever when i tried to write algorithms like sorting algorithm without thinking about objects i was always faster
@6754bettkitty
Great video! You make some good points about the useful parts of OOP. Unfortunately, many people take OOP to the extreme and make things way too complicated. That is why I usually try not to use OOP unless necessary and don't go overboard with it.
@wrfsh
I think your state/logic modules need an example. Otherwise this 9 minute video very clearly formulates what i was always feeling about modularization and OO but never could succinctly formulate. Thank you for that.
@woozie164
I found the idea of splitting into state and logic modules quite similar to what data-oriented design proposes. Although the idea there is more about collecting things in large arrays so they can be process efficiently together. Improved modularity and better handling of cross-cutting concerns is a nice benefit though.
@BertV1sser