Inheritance isn't the only way to do oop. What most ppl do is composition with interfaces only and dependency injection, which is very easy to read and understand.
fellas, if the code you write: * doesn't use inheritance; * doesn't encapsulate attributes; * utilizes dependency injection in order to control its state that's not object oriented code, that's procedural code
@@phillipanselmo8540 That isn't even true. You use objects to actually implement the contracts. In fact, the only real way to achieve composition is with objects. Now you can do this in procedural languages, since most have something which fills the role of an object (such as structs). But it is still an object-oriented style of programming.
@@gmodrules123456789 He's right. OOP is hardly the only paradigm with modules, interfaces, etc. Inheritance is the differentiator in oop and its largely seen as a mistake. Statements like "In fact, the only real way to achieve composition is with objects." Tells me you are very inexperienced and likely only know oop. Just saw your other responses, you aren't worth my time, don't bother.
TL:DR Smart person does not equal great programmer. There is beauty in simplicity, and it's a skill on it's own. This has nothing to do with OOP, but 100% with overengineered code
Greatness is subjective. I'm sure whoever wrote it felt great after applying a million different design patterns, doing everything exactly by the book, even if the result is complete chaos. OOP may not directly cause it, but it's a pattern that encourages design that leads to this. C++ just makes it a lot worse with 50 layers of macro expansions and function parameter overloading, both of which kill readability. OOP is a great recipe, when you want to cook some overengineering.
Agree! It takes a different kind of skill to write code that is not only clean and optimal, but also minimal and easily understood. Spent my career focusing on writing great code like that. Spent a lot of time un-over-engineering other people's code too.
@@gmodrules123456789 Which is precisely why I used the word "encourage"/"lead to", not "demand". A good engineer will know not to do it, but one idiot on the team can convince the management that that's "correct" way to do things, and then everyone will be forced to write these abominations to meet some corporate quota. There are too many conflicting OOP patterns that overlap and can be stacked, and this tends to cause some atrocities that could have been very easily avoided by applying common sense instead of "Clean Code(tm)" in its most naively literal interpretation. I can tell you, it's much more difficult to write code so convoluted and messed up in highly functional languages. Haskell may be impossible to read for outsides, but it's usually very clean and simple once you understand it because you have to follow very specific principles. If you don't know what type you're dealing with in Haskell, it's usually because it doesn't matter. All you know need to know what "interfaces" it implements.
As a C++ dev who can do some nasty wizardry, gotta say that whenever I have to use or modify some C code, no matter how bad the C code, it always feels ... relaxing xD
Every single time someone says that OOP is bad and have video, for some reason there is always someone talking about game programming, C++ with Visual Studio. Class hierarchies are almost always bad thing, and OOP doesn't mean that there should be some class hierarchy. When writing purely math and algorithms, there is nothing that benefits OOP, that is best to write as functional code. That is just bad code. Also, scientist write often bad code.
The pains for OOP in this video doesn't exist in Java with Intellij IDEA, I think C++ was just made overcomplicated for no reason when it was created. I can feel the pain in this video, and I think java oop is great.
@@fox2code Software development had two directions. First there was that machine language style, commands to turing machine. That evolved to structured programming and modern imperative languages with objects. Type systems come to help to avoid bugs.That is basicly crafting what system should do but languages got better. Other direction started from lambda calculus and functions, and make machine to evaluate them. And they got type systems, and objects to help expressing thoughts. We have known very long time that functional approach is very much ideal specification how the system should work. When writing Haskell, developer need to specify all the effects so it is hard to make bug. Performance reasons it was often preferred to write that machine language style and objects helps when program scope is more than single task. Now senior developers write functional style and add objects there only if it makes sense express thoughts better. Language roots can be seen in C++ that you don't write it functional way nicely. Stack overflow happens easily so recursion is bad thing in that language.
Yeah it really does just boil down to the same lame arguments. Almost every problem with OOP comes down to lack of developer experience with it. Maybe the real issue with OOP is that it makes it really easy to push bad code that works fine. Since logic and state are isolated, one bad part of the system doesn't impact the rest, making it easier for that bad code to slip through. The plus side is that its really easy to fix afterwards, because the logic and state are isolated. Refactoring the innards of an object is straightforward. The downside is that most places don't bother fixing the awful parts of the code, because it technically works, and development time is more important than code efficiency and readability. So you do get a lot of bad OOP code. But the nice thing about bad OOP code is that its actually not that bad. Bad C code is exceptionally bad. Obtuse typedefs and macros which expand into function calls which expand into more macros are a nightmare.
@@gmodrules123456789 Real issue is that it is misunderstood. OOP is modelling tool to define concepts. That doesn't mean that code should be full of hierarchices and state spread everywhere carelessly.
Your assumption that McGrath is going to generate the best OOP code is misguided. Programmers with math backgrounds often liter their code with deep levels of abstractions and create code that redirect way more than necessary. At its core, OOP is about encapsulation and sending messages. It is well suited for simulations or systems with discreet sub systems that need to interact. So if someone decides that OOP is the correct paradigm to follow for writing an EarCutr implementation, ehh... maybe read his books for the math and the algorithms, but do not look at it as an example of smart architectural decisions.
@@abcabc-ur3bf 99% of the time, the why is unit testing. At the same time, 99% of unit tests are completely unnecessary. You end up paying with code volume, complexity, and performance for questionable marginal gains.
@@youtubeenjoyer1743 Unit tests exist outside of the actual codebase. They exist to prevent other people from breaking your code, and sometimes to also prevent you from breaking your code. You need them for projects which you intend to change, or which will be changed by other people later on. So basically anything that isn't produced as a one-off.
@@gmodrules123456789 If words "module" or "application" fit your definition of a unit, then i agree. Otherwise, on a smaller scale, unit tests calcify the codebase, that is, resist change.
@@youtubeenjoyer1743 Unit would apply to different application layers or parts of the API. Something which tests modules or applications would be an integration test, or an end-to-end test.
One could make the exact same arguments about C code that takes opaque pointers and is composed of 500 nested macros. Your lack of ability to understand something doesn't make it bad, and regardless of how smart the guy who wrote the code is on a technical level, that doesn't mean he is good at writing clear code.
For real you can’t just sit 30s reading the start of the code and get mad if you can’t get shit because the codebase is huge, this isn’t some Python high level code or whatever I don’t know what he’s expecting us to answer when asking wtf that code is supposed to do
No this is 99% OOP. when you are reading any code in OOP you will be redirected a dozen times with functions that get redefined 6 times. All for the sake of encapsulation and abstraction. the idea that people should not know what the code is doing that they wrote, is a OOP idea.
@@Stars-Mine lay off the over opinionated youtube videos; that makes no fucking sense. many C codebases are exactly the same, see @spicynoodle7419 's comment on the video. also what are functions that get redefined 6 times? are you talking about function overloading? that is not oop my friend. also having a function call stack has nothing to do with oop
@@Stars-Mine You literally don't even know how to do OOP. Its actually extremely simple to do correctly. For some reason, people are allergic to doing it correctly.
I agree with you. I find that OOP often leads me from one place to another without actually showing what the code does. It’s ridiculous. OOP is a neat thought experiment but a multibillion dollar mistake.
"multibillion dollar mistake" Hardly. All the Fortune 500s follow it for a reason. They are the ones literally paying for it. You might not know this, but every single part of software lifecycle is billed. From drafting, to requirements planning, to the actual development, to UAT, to deployment, and to maintenance and upgrades. Software, at a minimum, costs hundreds of thousands of dollars once you factor in everything. They only pay for it if it brings a tangible benefit to the business process. So why would publicly-traded billion dollar companies who have a fiduciary responsibility to their shareholders, be wasting billions of dollars on an "experimental mistake" that presumably hurts them? Oh, it couldn't possibly be that OOP actually was a more profitable way to develop software. It couldn't possibly be that it actually streamlined a lot of the software lifecycle. The facts are very simple, OOP is generally more cost-effective for the very big corporate projects that run all of the backends and unseen business logic. Try writing an enterprise application in C99 and let me know how it goes. So what you have today is OOP in most major software, with FP being an alternative. C++ is used only where it actually matters. OOP isn't necessarily easier for the individual developer to work with. But it is easier for the business to work with. Which is ultimately the deciding factor.
That's becuase your signatures suck a%% and don't describe the behavior, simply build better APIs and you don't have that problem, the point of OOP is that you SHOULDN'T need to read the implementation to understand what something is doing, if you need to read the implementation then your abstraction sucks
It's a terrible decision. There's a difference between not wanting / having to think about implementation details and no longer being able to understand why / how something was implemented because of too many layers of indirection.
@@ArthurSchoppenweghauer I am mostly joking, but note that in the video he is taking a library that works perfectly and trying to change details that were never intended to be changed. Perhaps part of the problem stems from there.
Oh I feel your pain. Code base I am working on at the moment in c# has a whole bunch of reflection bs. They even have loads of decoy unused code everywhere so you can't reason about anything and because they use reflection you can't use any of the editors dead code detection to find stuff to delete.
I am so glad I found this video as your verbal barrage completely mirrors my own internal hate when I work with OOP (although I do PHP, not real code like you 😄). Which is why I developed a fully procedural function based framework and CMS platform.
I mean the c++ stdlib is formatted real fucking weird and heavily uses generics. I don't think the difficulty in reading it necessarily comes from the OOP'ness. If it was true blue dynamic dispatch OOP fuckery it'd be easier to understand, but less efficient
Paramteric polymorphism really isn't hard to reason about, c++ is just ass, because untyped template generics that are just glorified macros are ass. Ocaml parametetric polymorphism (generics) are easy to reason about.
His actual complaints: Flow control of the program is obfuscated Memory control of the program is obfuscated The functions and fields of a given type are obfuscated
My actual rebuttals: Textual flow control navigation has been solved by IDEs. Use your IDE features. Memory control is solved by automatic memory management. Use your automatic memory management. The "functions" and "fields" are called "methods" and "properties". You don't want to look at methods and properties - those are implementation details. Look at the public interface instead. OOP is easy, the dude just doesn't understand a single drop of it.
As a primarily C kernel dev, whenever I have to use C++, I always got brain damage from OOP. You create strong dependent hierarchy of useless abstract classes, that literally do nothing, and then, when you have to change something or delete an abstract class, the whole other program's code is dropping like flies. This is not issue in C, I can delete and rewrite exactly those lines of code, that matters. Also, when you write OOP, you generate so much useless code that does nothing. In procedural programming, every line of code doing something useful and valuable.
You only work with very low-level code, so you get no benefit from an object oriented paradigm. OOP is meant for large and generalized systems. This is why you see it in commercial applications. It is not optimized for systems programming, so it isn't useful there. C was designed from the outset as a systems level language.
@@gmodrules123456789 I can argue that even most of "business" logic can be done without OOP straightforwardly. OOP/Procedural styles are designing approaches, not architectural ones. It doesn't affect large distributed systems, it affects implementation level. In my experience, procedural style is more flexible to changes, than layers of layers of OOP abstractions, not considering that fact, that code execution, data locality, no need for vtables and ability for visual translation from C to machine code are closer to how cpu actually executes your code, when writing in procedural style. I don't stand against OOP as fanatic, I use some portions of it from time to time, whenever I see it may fit. My butthurt is I see many programmers (even old ones, with decades of experience) who follow OOP mantras without a second thought - "clean coders". They would smear everything with abstractions, even the simpliest things, and they generally have no desire for learning how OSes actually works and why their abstract approaches in critical-performant places are shit (they believe in compiler's divine powers).
@@markusasennoptchevich2037 Managing business logic is very time consuming with procedural styles. Hence why companies switched to OOP, and some others to FP. Performance is rarely the top priority for commercial applications. Algorithmic performance is typically the farthest that they will go, optimizing every possible instruction doesn't make sense for general purpose commercial software. The actual priorities are speed of development, and code correctness, and safety. Development speed means less billable hours per product. Correctness and safety yield fewer hours spent on bug fixes and general maintenance. This is also why memory-safe languages are so popular. These priorities feed into the single biggest priority, profitability. Highly optimized procedural code runs better. But to actually get that, you spend more time on both development and maintenance, which costs more money. Outside of high-performance firmware, rendering software, and financial tools, profitability doesn't scale with performance. For a general purpose commercial application, the difference between 25ms and 250ms isn't that significant in terms of profitability. But the difference between 200 billable hours and 600 billable hours is a big difference. This is why most software gets written in big frameworks such as .NET or NodeJS or Spring, as opposed to having it all written in C/C++.
@@markusasennoptchevich2037 Speed of development mainly. Which is actually the same reason for using OOP. Faster development means higher profits, which is the priority for commercial applications.
I feel your pain. I refuse to use anything I don’t write when dealing with OOP because if I didn’t write it, I probably am going to have to do more work figuring out what shit does than it would take me to rewrite everything myself from scratch
I've seen what could be simple APIs, interfaces with no more than 20 possible basic functions, turned into labyrinths of constructors and inheritance. A basic API with 20 calls and a rewrite would take less time than understanding the object structure and not hamper my productivity. I see much OOP code as the coder's over-indulgence in the act of abstraction (which is "just what smart people do") at the expense of practical consideration and the control and agency of future developers.
*Good code should he like a list of bullet points that any one can read and undwrstand. Not a Wikipedia page written in PhD language, linking 500 sub topics.* Regardless of the language or function. The only reason to write code like this is so that no one can ever replace you, because it would be easier to just rewrite the entire code base.
Says anyone who wants to rationalize bad software. The same thing vim guys say, instead of moving on to a modern IDE and forgetting about the editor which feels like 1972.
Lol, what are you talking about 🤣 modern IDE even have vim plugin/feature. Vim still exist for a reason. You have no idea, you are just hating for no reason😂 @@I_am_Raziel
It's anecdotical: "Software engeneer with debugging skill issue meets a matimatician with lack of a coding standarts". If someone get how to take energy from that duo, we gonna solve energy crisis at all
Honestly, the resize code at 10:38 just shows to me that this isn't only OOP's fault. The guy is optimizing, or doing whatever the f he does with macros. But seriously, even with all the introduction on how good he's supposed to be, when I read the code at 10:38, I'm not even sure anymore if he's that good in coding... He might be good in theory of algorithmics, but this code is plain bad. I've seen my fare share of C++, and this is pure nasty. The ONLY reason you would write that is for optimization. This might not be supposed to be that readable. My current project is 100k lines of C++ and you wouldn't find anything close to this mess in it. And I use OOP. But the good part, just a few interfaces or short inheritance here and there. Just having a "Window2" class shows he probably doesn't know what he's doing, really...
The code you are referring to is the std::vector. The reason it is so complicated is two words: “exception safety”. Look up other STL data structure implementations. They are absolutely nuts. All for what? For the bad experiment called “exceptions”.
Program code is as readable as architecture lets you. OOP of itself is not bad. You have defined rules to follow to make code more readable and comprehensible. Architecture is what makes code difficult to understand. For example: MVC. You know where are views stored, you know what does repository do, you immediately can use services to write your own code. If a code can't be read by another developer then it's a bad code. Or would you rather want to have everything in one class and be hard stuck for a year with one method that spans 1k lines of code?
He's one of "those" developers that you encounter from time to time who aren't actually that talented, and get upset if they can't understand something in 1 minute. They need all of their code in short, stack overflow posts in order to understand them.
Yep .... :> There's good concepts in OOP. But, ya ..... I mean, that's one reason Jonathon Blow created his own language. C++ is overly complicated. Like you asked, What is a WindowType? You should be able to look it up and just a struct definition should popup. Not something layers and layers deep.
@@kerojey4442 He definitely isn't a good programmer if this is how he conducts himself. It seems like a lot of "games programmers" are like this. Extremely arrogant and not very talented. It doesn't actually require a ton of expertise to write games.
Yes, writing OOP code is caused by skill issues, indeed. I know it because I'm no expert and I have trouble writing non-OOP code, because that's what I was taught in the Flash days and I'm still trying to shake it off.
@@gmodrules123456789 that's some pretty nice bs you got there. People write OOP not because they're experienced, but because that's what they're taught or because they have no choice, because the most popular languages and game engines are strictly OOP: Java, Haxe, Unity, Godot, JS, anything with C#... Even C++ and Python, despite not forcing OOP, are taught in OOP. I've been writing OOP code for almost 20 years, and I still write OOP code on a daily basis because game engines demand OOP. By your logic I should be an expert. WeIl, I do have the common sense of avoiding deep inheritance, which I learned from experience. Because that's really the problematic part of OOP. Back in the Flash days, everyone was parroting the mantra "composition over inheritance", but then everyone went with inheritance anyway. So that's what I and everyone else were taught.
@@gmodrules123456789 that's some pretty nice bs you got there. People write OOP not because they're experienced, but because that's what they're taught or because they have no choice, because the most popular languages and game engines are strictly OOP: Java, Haxe, Unity, Godot, JS, anything with C#... Even C++ and Python, despite not forcing OOP, are taught in OOP. I've been writing OOP code for almost 20 years, and I still write OOP code on a daily basis because game engines demand OOP. By your logic I should be an expert. WeIl, I do have the common sense of avoiding deep inheritance, which I learned from experience. Because that's really the problematic part of OOP. Back in the Flash days, everyone was parroting the mantra "composition over inheritance", but then everyone went with inheritance anyway. So that's what I and everyone else were taught.
7:49 I established that this dude has severe skill issue and decided to not watch the rest of it Yes, OOP is bad and all, but what he complained about so far is meaningless, you don't need to know the entire context at each line, in no paradigm you're supposed to know everything in every line from a glance, the expectation that he would read the 3rd line of main and know everything that a whole system does from it's signature is crazy. And of course he could imply by semantic what the system is about, but no, he goes following calls and declarations and calling it disorganized for no reason
A window manager interface can and should (in most cases) be much simpler. it's too convoluted and error prone here imo. WindowSystem.CreateWindow(parameters) -> there you have your window handle or whatever. Shouldn't go beyond that. The WindowType thing smells bad. Why would you need different window types ?
I think at least part of the point in this case is that the algorithm can be recreated in about 1k lines of straight-forward procedural code without all of the indirection and "data modeling" just for the sake of it.
@@soggy_dev so far at that point of the video there's no indirections everything is linear and surface-level and the guy was already yapping at it. Yes there is inheritance, which sucks, but no bad examples of inheritance usage, only separating generic abstractions from specific implementations. Again, you don't need to know the entire thing at a glance and regardless of the paradigm you would do as many jumps to find the rest of the context. I expected a well thought criticism of Object orientation, but the guy is yapping at a nothing burger there
Skill issue tbh. C is just as fucked. Oh let me trace through 50 function calls. Oh what is this, a typedef Rectangle that actually is a void pointer that is casted to different shit wherever the hell. Your debugging issues were 100% caused by the C++ stdlib. Oops, I pressed Step Into instead of Step Over, now i'm recursing from C++ 24 through 22, through 20, through 17 through 14, through 11, through 99, to a plain C while loop.
@@youtubeenjoyer1743 You've never seen wild C code, have you? Let me tell you, there is nothing worse than having to navigate a 3+ million LOC codebase written in C and C++ with minimal documentation. At least 75,000 of those lines were automatically generated macros created by bash scripts.
@@gmodrules123456789 I have seen both wild OOP and procedural code. The crucial difference is, OOP is naturally wild, while classic procedural code is not. You can generate horrific Java code too. Why? The answer lies within the word. It's called Object-*Oriented* Programming. The act of orientation around one very specific programming pattern is the problem.
@@youtubeenjoyer1743 Bad OOP code is almost always cleaner than bad procedural code. You talk like this is a rule for OOP code to be badly made, that its always going to be bad. No, if all the code you encounter is bad, its either a problem with your team, or a problem with yourself.
@@gmodrules123456789 I'm not saying it's a rule, only that it is natural for average OOP code to be worse than average procedural code. And the reason is shoehorning everything into objects with dynamic dispatch and many layers of unnecessary indirection. You talk in absolutes, and then accuse me of it. Classic.
Shawn McGrath strikes me as someone who isn't very mature and isn't very smart. Literally can't go 3 seconds without cursing. Has a strange affinity for slurs. Unkempt, and generally messy living space. The actual code he was going through doesn't even look that complicated. But I suppose he's one of "those" people who can't be bothered to spend more than 5 minutes actually trying to understand what he's looking at. I've met plenty of people in software who act like this, none of them ever get very far, and none of them are pleasant to work with. Literal manchild.
if you haven't actually noticed, and it seems you haven't because you didn't watch the video, he rewrote the triangulation code and uses it in his codebase. So not only he had to spent more than 5 minutes on it, he also understood it quite well. He just presented the journey he had with this code and how obfuscated it is. But I'm not surprised this went over your head.
@@nan0s500 No, he moaned and cried about it instead of just doing the work that needed to be done. He wasted a lot of time being a poorly-socialized manchild, instead of, you know, actually writing code. Something all too common with people of his "genre". I've meant plenty of people who are literal carbon copies of him, they all look, and sound, and act, the exact same way. I actually agree with his sentiment that the sourcecode was badly structured. It wasn't complicated, but it was definitely made by someone who isn't experienced. He did eventually get it working. I suppose we should give him a gold star for complaining for 30 minutes, and then copy-pasting the source code into his own project. Truly a momentous feat. If you plan on working in this field, you shouldn't be taking this guys advice. These people are bad influences. I encounter programmers who regurgitate this guys talking points, and they are impossible to work with and never improve. Don't end up like that.
C++ OOP looks like a nightmare from this video, and the tools look like they don't give any useful info. Java OOP is so much easier to understand, and Intellij IDEA actually always give useful information.
In my experience, Java programmers also have a tendency to bury their code in layers of inheritance and all sorts of intermediate stuff. Inheritance is the specific part of OOP that is the most problematic. I once read the code for a GUI library in Java, and I couldn't find the code the Button class. I just found fragments of it, buried deep in several places...
@@skaruts Intellij tells you every class that implement an actual function, and java always show the full stacktrace when an exception occurs. Inheritance is good when it's in good measure, on java I also often use the "static" keyword to do regular functional style programing. I think abusing Inheritance can make code harder to read or look at, you can see "FizzBuzzEnterpriseEdition" for a good example of that.
@@skaruts Well, Java built-in Swing/AWT library is over engineered, in java button rendering and other random stuff is handled by LAF (Look and feel) LAF is a cool feature, but it sure does make the java swing/awt code a nightmare to understand because of it.
@@ArthurSchoppenweghauer Functional programming goes step further. In functional programming, you write it stateless. C++ however sucks there because recursion and all functions calling functions can easily cause stack overflow, so there are are better languages to express algorithms.
Are you going to tell me that his rewrite is less readable? Are you ignoring the fact that this supposedly lousy programmer was able to rewrite the code he is complaining about? Anyone can make something complicated - the fact that people don't want to spend time navigating bespoke and unnecessary abstractions is not a skill issue, it's just common sense.
You're right, I hate it. I only do elixir, FP is superior P than OOP . Although elixir is not for game development. That being said shout out to pikdum/thistle_tea, he made a vanilla wow server in elixir.
Inheritance isn't the only way to do oop. What most ppl do is composition with interfaces only and dependency injection, which is very easy to read and understand.
fellas, if the code you write:
* doesn't use inheritance;
* doesn't encapsulate attributes;
* utilizes dependency injection in order to control its state
that's not object oriented code, that's procedural code
@@phillipanselmo8540
That isn't even true. You use objects to actually implement the contracts. In fact, the only real way to achieve composition is with objects. Now you can do this in procedural languages, since most have something which fills the role of an object (such as structs). But it is still an object-oriented style of programming.
@@gmodrules123456789 you can also create composition with indexes.
@@phillipanselmo8540 well maybe, but add the gamechanger, tell dont ask
@@gmodrules123456789 He's right. OOP is hardly the only paradigm with modules, interfaces, etc. Inheritance is the differentiator in oop and its largely seen as a mistake.
Statements like "In fact, the only real way to achieve composition is with objects." Tells me you are very inexperienced and likely only know oop.
Just saw your other responses, you aren't worth my time, don't bother.
Consider using 1080p for such small fonts
TL:DR Smart person does not equal great programmer. There is beauty in simplicity, and it's a skill on it's own. This has nothing to do with OOP, but 100% with overengineered code
Greatness is subjective. I'm sure whoever wrote it felt great after applying a million different design patterns, doing everything exactly by the book, even if the result is complete chaos.
OOP may not directly cause it, but it's a pattern that encourages design that leads to this.
C++ just makes it a lot worse with 50 layers of macro expansions and function parameter overloading, both of which kill readability.
OOP is a great recipe, when you want to cook some overengineering.
Agree! It takes a different kind of skill to write code that is not only clean and optimal, but also minimal and easily understood. Spent my career focusing on writing great code like that. Spent a lot of time un-over-engineering other people's code too.
@@NatiiixLP
It doesn't demand over-engineering. That usually comes down to the architecture of the program, not the paradigm that is used.
@@gmodrules123456789 Which is precisely why I used the word "encourage"/"lead to", not "demand".
A good engineer will know not to do it, but one idiot on the team can convince the management that that's "correct" way to do things, and then everyone will be forced to write these abominations to meet some corporate quota.
There are too many conflicting OOP patterns that overlap and can be stacked, and this tends to cause some atrocities that could have been very easily avoided by applying common sense instead of "Clean Code(tm)" in its most naively literal interpretation.
I can tell you, it's much more difficult to write code so convoluted and messed up in highly functional languages. Haskell may be impossible to read for outsides, but it's usually very clean and simple once you understand it because you have to follow very specific principles. If you don't know what type you're dealing with in Haskell, it's usually because it doesn't matter. All you know need to know what "interfaces" it implements.
As a C++ dev who can do some nasty wizardry, gotta say that whenever I have to use or modify some C code, no matter how bad the C code, it always feels ... relaxing xD
Every single time someone says that OOP is bad and have video, for some reason there is always someone talking about game programming, C++ with Visual Studio.
Class hierarchies are almost always bad thing, and OOP doesn't mean that there should be some class hierarchy. When writing purely math and algorithms, there is nothing that benefits OOP, that is best to write as functional code. That is just bad code.
Also, scientist write often bad code.
The pains for OOP in this video doesn't exist in Java with Intellij IDEA, I think C++ was just made overcomplicated for no reason when it was created.
I can feel the pain in this video, and I think java oop is great.
@@fox2code
Software development had two directions. First there was that machine language style, commands to turing machine. That evolved to structured programming and modern imperative languages with objects. Type systems come to help to avoid bugs.That is basicly crafting what system should do but languages got better.
Other direction started from lambda calculus and functions, and make machine to evaluate them. And they got type systems, and objects to help expressing thoughts.
We have known very long time that functional approach is very much ideal specification how the system should work. When writing Haskell, developer need to specify all the effects so it is hard to make bug. Performance reasons it was often preferred to write that machine language style and objects helps when program scope is more than single task. Now senior developers write functional style and add objects there only if it makes sense express thoughts better.
Language roots can be seen in C++ that you don't write it functional way nicely. Stack overflow happens easily so recursion is bad thing in that language.
Yeah it really does just boil down to the same lame arguments.
Almost every problem with OOP comes down to lack of developer experience with it.
Maybe the real issue with OOP is that it makes it really easy to push bad code that works fine. Since logic and state are isolated, one bad part of the system doesn't impact the rest, making it easier for that bad code to slip through.
The plus side is that its really easy to fix afterwards, because the logic and state are isolated. Refactoring the innards of an object is straightforward. The downside is that most places don't bother fixing the awful parts of the code, because it technically works, and development time is more important than code efficiency and readability.
So you do get a lot of bad OOP code. But the nice thing about bad OOP code is that its actually not that bad.
Bad C code is exceptionally bad. Obtuse typedefs and macros which expand into function calls which expand into more macros are a nightmare.
@@gmodrules123456789
Real issue is that it is misunderstood. OOP is modelling tool to define concepts. That doesn't mean that code should be full of hierarchices and state spread everywhere carelessly.
@@gruntaxeman3740 exactly.
OOP is a tool.
Use it where it brings value.
Don’t where it doesn’t.
The math library is a perfect example.
Your assumption that McGrath is going to generate the best OOP code is misguided.
Programmers with math backgrounds often liter their code with deep levels of abstractions and create code that redirect way more than necessary.
At its core, OOP is about encapsulation and sending messages. It is well suited for simulations or systems with discreet sub systems that need to interact.
So if someone decides that OOP is the correct paradigm to follow for writing an EarCutr implementation, ehh... maybe read his books for the math and the algorithms, but do not look at it as an example of smart architectural decisions.
Typical lazy brain blames everything on OOP instead of actually understanding why
@@abcabc-ur3bf 99% of the time, the why is unit testing. At the same time, 99% of unit tests are completely unnecessary. You end up paying with code volume, complexity, and performance for questionable marginal gains.
@@youtubeenjoyer1743
Unit tests exist outside of the actual codebase. They exist to prevent other people from breaking your code, and sometimes to also prevent you from breaking your code. You need them for projects which you intend to change, or which will be changed by other people later on. So basically anything that isn't produced as a one-off.
@@gmodrules123456789 If words "module" or "application" fit your definition of a unit, then i agree. Otherwise, on a smaller scale, unit tests calcify the codebase, that is, resist change.
@@youtubeenjoyer1743
Unit would apply to different application layers or parts of the API. Something which tests modules or applications would be an integration test, or an end-to-end test.
One could make the exact same arguments about C code that takes opaque pointers and is composed of 500 nested macros.
Your lack of ability to understand something doesn't make it bad, and regardless of how smart the guy who wrote the code is on a technical level, that doesn't mean he is good at writing clear code.
For real you can’t just sit 30s reading the start of the code and get mad if you can’t get shit because the codebase is huge, this isn’t some Python high level code or whatever I don’t know what he’s expecting us to answer when asking wtf that code is supposed to do
@@lucid_The codebase shown in the video is not huge at all. It just opens a windows and draws simple graphics as a demonstration of the algorithm.
This has 1% to do with OOP and 99% to do with C++ tho
Not really. In this case its both.
i just skipped through the video but templates are not c++
No this is 99% OOP. when you are reading any code in OOP you will be redirected a dozen times with functions that get redefined 6 times. All for the sake of encapsulation and abstraction.
the idea that people should not know what the code is doing that they wrote, is a OOP idea.
@@Stars-Mine lay off the over opinionated youtube videos; that makes no fucking sense. many C codebases are exactly the same, see @spicynoodle7419 's comment on the video. also what are functions that get redefined 6 times? are you talking about function overloading? that is not oop my friend. also having a function call stack has nothing to do with oop
@@Stars-Mine
You literally don't even know how to do OOP.
Its actually extremely simple to do correctly. For some reason, people are allergic to doing it correctly.
Thankfully they invented UML to make OOP undrestandable. xD.
beautiful.
Never seen this dude before but I like him already! This is how I feel every day working with code. I am glad I am not the only one! -=P
Seems like you're in the wrong field then.
I agree with you.
I find that OOP often leads me from one place to another without actually showing what the code does.
It’s ridiculous.
OOP is a neat thought experiment but a multibillion dollar mistake.
@@CoderDBF Well said 👏
"multibillion dollar mistake"
Hardly. All the Fortune 500s follow it for a reason. They are the ones literally paying for it. You might not know this, but every single part of software lifecycle is billed. From drafting, to requirements planning, to the actual development, to UAT, to deployment, and to maintenance and upgrades.
Software, at a minimum, costs hundreds of thousands of dollars once you factor in everything. They only pay for it if it brings a tangible benefit to the business process.
So why would publicly-traded billion dollar companies who have a fiduciary responsibility to their shareholders, be wasting billions of dollars on an "experimental mistake" that presumably hurts them?
Oh, it couldn't possibly be that OOP actually was a more profitable way to develop software. It couldn't possibly be that it actually streamlined a lot of the software lifecycle.
The facts are very simple, OOP is generally more cost-effective for the very big corporate projects that run all of the backends and unseen business logic. Try writing an enterprise application in C99 and let me know how it goes.
So what you have today is OOP in most major software, with FP being an alternative. C++ is used only where it actually matters.
OOP isn't necessarily easier for the individual developer to work with. But it is easier for the business to work with. Which is ultimately the deciding factor.
Same thing, every time. It's so annoying.
It adds tons of boilerplate code and complexity without necessity.
That's becuase your signatures suck a%% and don't describe the behavior, simply build better APIs and you don't have that problem, the point of OOP is that you SHOULDN'T need to read the implementation to understand what something is doing, if you need to read the implementation then your abstraction sucks
"We have decided to use C++ and OOP, we have decided to say, 'fuck it, we have no idea how this works.'" Encapsulation! It is a feature, not a bug.
It's a terrible decision. There's a difference between not wanting / having to think about implementation details and no longer being able to understand why / how something was implemented because of too many layers of indirection.
@@ArthurSchoppenweghauer I am mostly joking, but note that in the video he is taking a library that works perfectly and trying to change details that were never intended to be changed. Perhaps part of the problem stems from there.
Oh I feel your pain. Code base I am working on at the moment in c# has a whole bunch of reflection bs. They even have loads of decoy unused code everywhere so you can't reason about anything and because they use reflection you can't use any of the editors dead code detection to find stuff to delete.
Job security didn’t work
Consider total rewrite
Or suffer
Nice breakdown of the silliness of OOP
I am so glad I found this video as your verbal barrage completely mirrors my own internal hate when I work with OOP (although I do PHP, not real code like you 😄). Which is why I developed a fully procedural function based framework and CMS platform.
As far as I have watched you are mostly criticizing C++, and the idea of abstraction, which existed long before oop.
bro got covid from cpp code
Dude this came on auto play while I’m listening to random shit at work. Holy fuck I’m dying!!!!
I miss when Shawn use to stream.
This code is giving my mans COPD
lmfao real talk
I mean the c++ stdlib is formatted real fucking weird and heavily uses generics. I don't think the difficulty in reading it necessarily comes from the OOP'ness. If it was true blue dynamic dispatch OOP fuckery it'd be easier to understand, but less efficient
Paramteric polymorphism really isn't hard to reason about, c++ is just ass, because untyped template generics that are just glorified macros are ass. Ocaml parametetric polymorphism (generics) are easy to reason about.
His actual complaints:
Flow control of the program is obfuscated
Memory control of the program is obfuscated
The functions and fields of a given type are obfuscated
My actual rebuttals:
Textual flow control navigation has been solved by IDEs. Use your IDE features.
Memory control is solved by automatic memory management. Use your automatic memory management.
The "functions" and "fields" are called "methods" and "properties". You don't want to look at methods and properties - those are implementation details. Look at the public interface instead.
OOP is easy, the dude just doesn't understand a single drop of it.
Challenge: take a shot every Time he Said f*ck
38:26 of pure rage against OOP abstractions we love 😅
As a primarily C kernel dev, whenever I have to use C++, I always got brain damage from OOP. You create strong dependent hierarchy of useless abstract classes, that literally do nothing, and then, when you have to change something or delete an abstract class, the whole other program's code is dropping like flies. This is not issue in C, I can delete and rewrite exactly those lines of code, that matters. Also, when you write OOP, you generate so much useless code that does nothing. In procedural programming, every line of code doing something useful and valuable.
You only work with very low-level code, so you get no benefit from an object oriented paradigm.
OOP is meant for large and generalized systems. This is why you see it in commercial applications. It is not optimized for systems programming, so it isn't useful there. C was designed from the outset as a systems level language.
@@gmodrules123456789 I can argue that even most of "business" logic can be done without OOP straightforwardly. OOP/Procedural styles are designing approaches, not architectural ones. It doesn't affect large distributed systems, it affects implementation level. In my experience, procedural style is more flexible to changes, than layers of layers of OOP abstractions, not considering that fact, that code execution, data locality, no need for vtables and ability for visual translation from C to machine code are closer to how cpu actually executes your code, when writing in procedural style. I don't stand against OOP as fanatic, I use some portions of it from time to time, whenever I see it may fit. My butthurt is I see many programmers (even old ones, with decades of experience) who follow OOP mantras without a second thought - "clean coders". They would smear everything with abstractions, even the simpliest things, and they generally have no desire for learning how OSes actually works and why their abstract approaches in critical-performant places are shit (they believe in compiler's divine powers).
@@markusasennoptchevich2037
Managing business logic is very time consuming with procedural styles. Hence why companies switched to OOP, and some others to FP.
Performance is rarely the top priority for commercial applications. Algorithmic performance is typically the farthest that they will go, optimizing every possible instruction doesn't make sense for general purpose commercial software.
The actual priorities are speed of development, and code correctness, and safety. Development speed means less billable hours per product. Correctness and safety yield fewer hours spent on bug fixes and general maintenance. This is also why memory-safe languages are so popular. These priorities feed into the single biggest priority, profitability.
Highly optimized procedural code runs better. But to actually get that, you spend more time on both development and maintenance, which costs more money. Outside of high-performance firmware, rendering software, and financial tools, profitability doesn't scale with performance.
For a general purpose commercial application, the difference between 25ms and 250ms isn't that significant in terms of profitability. But the difference between 200 billable hours and 600 billable hours is a big difference.
This is why most software gets written in big frameworks such as .NET or NodeJS or Spring, as opposed to having it all written in C/C++.
@@gmodrules123456789 then, why does golang is so popular in backend nowadays?
@@markusasennoptchevich2037
Speed of development mainly. Which is actually the same reason for using OOP. Faster development means higher profits, which is the priority for commercial applications.
I feel your pain. I refuse to use anything I don’t write when dealing with OOP because if I didn’t write it, I probably am going to have to do more work figuring out what shit does than it would take me to rewrite everything myself from scratch
Shawn McGrath is the Angry Video Game Programmer
It's so sad though how limited the english language is for cursing.
This man is a great sage. Drink deep from the wellspring of wisdom, friends
Showing STL implementation is so funny :D
Been programming OOP in PHP for years. I feel your pain man.
I've seen what could be simple APIs, interfaces with no more than 20 possible basic functions, turned into labyrinths of constructors and inheritance. A basic API with 20 calls and a rewrite would take less time than understanding the object structure and not hamper my productivity. I see much OOP code as the coder's over-indulgence in the act of abstraction (which is "just what smart people do") at the expense of practical consideration and the control and agency of future developers.
What about testability? All this crazy indirection enables granular system configuration, which aids testing.
*Good code should he like a list of bullet points that any one can read and undwrstand. Not a Wikipedia page written in PhD language, linking 500 sub topics.*
Regardless of the language or function. The only reason to write code like this is so that no one can ever replace you, because it would be easier to just rewrite the entire code base.
Skill issue.
Yes because ur a better programmer than shawn mcgrath
OOP is simply a crutch for skill issues, therefore OOP-enjoyers are walking skill issues
Massive cope.
Says anyone who wants to rationalize bad software.
The same thing vim guys say, instead of moving on to a modern IDE and forgetting about the editor which feels like 1972.
Lol, what are you talking about 🤣 modern IDE even have vim plugin/feature. Vim still exist for a reason. You have no idea, you are just hating for no reason😂 @@I_am_Raziel
It's anecdotical: "Software engeneer with debugging skill issue meets a matimatician with lack of a coding standarts".
If someone get how to take energy from that duo, we gonna solve energy crisis at all
At this point start writing C or Zig code
Is Petzold's "Programming Windows" without OOP simpler?
Honestly, the resize code at 10:38 just shows to me that this isn't only OOP's fault. The guy is optimizing, or doing whatever the f he does with macros. But seriously, even with all the introduction on how good he's supposed to be, when I read the code at 10:38, I'm not even sure anymore if he's that good in coding... He might be good in theory of algorithmics, but this code is plain bad. I've seen my fare share of C++, and this is pure nasty. The ONLY reason you would write that is for optimization. This might not be supposed to be that readable.
My current project is 100k lines of C++ and you wouldn't find anything close to this mess in it. And I use OOP. But the good part, just a few interfaces or short inheritance here and there.
Just having a "Window2" class shows he probably doesn't know what he's doing, really...
The code you are referring to is the std::vector. The reason it is so complicated is two words: “exception safety”. Look up other STL data structure implementations. They are absolutely nuts. All for what? For the bad experiment called “exceptions”.
Dude stop complaining, this is job security! 😂
Your IDE is painful to watch, and OOP becomes shit when you really become a programmer for real.
Program code is as readable as architecture lets you. OOP of itself is not bad. You have defined rules to follow to make code more readable and comprehensible. Architecture is what makes code difficult to understand. For example: MVC. You know where are views stored, you know what does repository do, you immediately can use services to write your own code. If a code can't be read by another developer then it's a bad code. Or would you rather want to have everything in one class and be hard stuck for a year with one method that spans 1k lines of code?
What is the "good" style of programming called? Imperative or procedural?
Bro complains there's more comments than code, but needs more comments because he still doesn't understand the code...
I giggled
He's one of "those" developers that you encounter from time to time who aren't actually that talented, and get upset if they can't understand something in 1 minute. They need all of their code in short, stack overflow posts in order to understand them.
Yep .... :> There's good concepts in OOP. But, ya ..... I mean, that's one reason Jonathon Blow created his own language. C++ is overly complicated. Like you asked, What is a WindowType? You should be able to look it up and just a struct definition should popup. Not something layers and layers deep.
I dont know how i found you. But thumb up.
Is this code overcomplicated? Yes
Is this guy ignorant? Yes
Best Comment
Someone smart made overcomplicated code for fun.
Good game programmer with years of experience is ignorant and you are not, yeah totaly...
@@kerojey4442 I'm not questioning his competence but the way he presents himself is off puting.
@@kerojey4442
He definitely isn't a good programmer if this is how he conducts himself. It seems like a lot of "games programmers" are like this. Extremely arrogant and not very talented. It doesn't actually require a ton of expertise to write games.
Skill issue but you are also correct
Cope but you are half-correct.
skill issues
Coping issues.
Yes, writing OOP code is caused by skill issues, indeed. I know it because I'm no expert and I have trouble writing non-OOP code, because that's what I was taught in the Flash days and I'm still trying to shake it off.
@@skaruts
Writing OOP code generally means you have actual experience in software. Quick detail, but hobby projects in Flash are not "experience".
@@gmodrules123456789 that's some pretty nice bs you got there. People write OOP not because they're experienced, but because that's what they're taught or because they have no choice, because the most popular languages and game engines are strictly OOP: Java, Haxe, Unity, Godot, JS, anything with C#... Even C++ and Python, despite not forcing OOP, are taught in OOP.
I've been writing OOP code for almost 20 years, and I still write OOP code on a daily basis because game engines demand OOP. By your logic I should be an expert.
WeIl, I do have the common sense of avoiding deep inheritance, which I learned from experience. Because that's really the problematic part of OOP. Back in the Flash days, everyone was parroting the mantra "composition over inheritance", but then everyone went with inheritance anyway. So that's what I and everyone else were taught.
@@gmodrules123456789 that's some pretty nice bs you got there. People write OOP not because they're experienced, but because that's what they're taught or because they have no choice, because the most popular languages and game engines are strictly OOP: Java, Haxe, Unity, Godot, JS, anything with C#... Even C++ and Python, despite not forcing OOP, are taught in OOP.
I've been writing OOP code for almost 20 years, and I still write OOP code on a daily basis because game engines demand OOP. By your logic I should be an expert.
WeIl, I do have the common sense of avoiding deep inheritance, which I learned from experience. Because that's really the problematic part of OOP. Back in the Flash days, everyone was parroting the mantra "composition over inheritance", but then everyone went with inheritance anyway. So that's what I and everyone else were taught.
7:49 I established that this dude has severe skill issue and decided to not watch the rest of it
Yes, OOP is bad and all, but what he complained about so far is meaningless, you don't need to know the entire context at each line, in no paradigm you're supposed to know everything in every line from a glance, the expectation that he would read the 3rd line of main and know everything that a whole system does from it's signature is crazy. And of course he could imply by semantic what the system is about, but no, he goes following calls and declarations and calling it disorganized for no reason
A window manager interface can and should (in most cases) be much simpler. it's too convoluted and error prone here imo. WindowSystem.CreateWindow(parameters) -> there you have your window handle or whatever. Shouldn't go beyond that. The WindowType thing smells bad. Why would you need different window types ?
I think at least part of the point in this case is that the algorithm can be recreated in about 1k lines of straight-forward procedural code without all of the indirection and "data modeling" just for the sake of it.
@@soggy_dev so far at that point of the video there's no indirections everything is linear and surface-level and the guy was already yapping at it.
Yes there is inheritance, which sucks, but no bad examples of inheritance usage, only separating generic abstractions from specific implementations. Again, you don't need to know the entire thing at a glance and regardless of the paradigm you would do as many jumps to find the rest of the context. I expected a well thought criticism of Object orientation, but the guy is yapping at a nothing burger there
Yeah lol, that's why I love Clojure and data-oriented programming. Admittedly though, a major part of rant is on C++ more than OOP.
PHP OOP devs create the same horrible mess. It's not only C++.
@@LorenzVdv Best OOP is Erlang.
this is basically java
sempre que vejo esses textos criticando oop já sei quem não contratar
Skill issue tbh. C is just as fucked. Oh let me trace through 50 function calls. Oh what is this, a typedef Rectangle that actually is a void pointer that is casted to different shit wherever the hell.
Your debugging issues were 100% caused by the C++ stdlib. Oops, I pressed Step Into instead of Step Over, now i'm recursing from C++ 24 through 22, through 20, through 17 through 14, through 11, through 99, to a plain C while loop.
Ginormous cope.
@@youtubeenjoyer1743
You've never seen wild C code, have you? Let me tell you, there is nothing worse than having to navigate a 3+ million LOC codebase written in C and C++ with minimal documentation. At least 75,000 of those lines were automatically generated macros created by bash scripts.
@@gmodrules123456789 I have seen both wild OOP and procedural code. The crucial difference is, OOP is naturally wild, while classic procedural code is not. You can generate horrific Java code too.
Why? The answer lies within the word. It's called Object-*Oriented* Programming. The act of orientation around one very specific programming pattern is the problem.
@@youtubeenjoyer1743
Bad OOP code is almost always cleaner than bad procedural code.
You talk like this is a rule for OOP code to be badly made, that its always going to be bad. No, if all the code you encounter is bad, its either a problem with your team, or a problem with yourself.
@@gmodrules123456789 I'm not saying it's a rule, only that it is natural for average OOP code to be worse than average procedural code. And the reason is shoehorning everything into objects with dynamic dispatch and many layers of unnecessary indirection.
You talk in absolutes, and then accuse me of it. Classic.
Shawn McGrath strikes me as someone who isn't very mature and isn't very smart.
Literally can't go 3 seconds without cursing. Has a strange affinity for slurs. Unkempt, and generally messy living space.
The actual code he was going through doesn't even look that complicated. But I suppose he's one of "those" people who can't be bothered to spend more than 5 minutes actually trying to understand what he's looking at.
I've met plenty of people in software who act like this, none of them ever get very far, and none of them are pleasant to work with. Literal manchild.
if you haven't actually noticed, and it seems you haven't because you didn't watch the video, he rewrote the triangulation code and uses it in his codebase. So not only he had to spent more than 5 minutes on it, he also understood it quite well.
He just presented the journey he had with this code and how obfuscated it is. But I'm not surprised this went over your head.
@@nan0s500
No, he moaned and cried about it instead of just doing the work that needed to be done. He wasted a lot of time being a poorly-socialized manchild, instead of, you know, actually writing code. Something all too common with people of his "genre". I've meant plenty of people who are literal carbon copies of him, they all look, and sound, and act, the exact same way.
I actually agree with his sentiment that the sourcecode was badly structured. It wasn't complicated, but it was definitely made by someone who isn't experienced. He did eventually get it working.
I suppose we should give him a gold star for complaining for 30 minutes, and then copy-pasting the source code into his own project. Truly a momentous feat.
If you plan on working in this field, you shouldn't be taking this guys advice. These people are bad influences. I encounter programmers who regurgitate this guys talking points, and they are impossible to work with and never improve. Don't end up like that.
@@gmodrules123456789 the irony
Bro get to the point
skill issue :D
FP > OOP
C++ OOP looks like a nightmare from this video, and the tools look like they don't give any useful info.
Java OOP is so much easier to understand, and Intellij IDEA actually always give useful information.
So it takes a whole virtual machine with automatic memory management to enable OOP.
In my experience, Java programmers also have a tendency to bury their code in layers of inheritance and all sorts of intermediate stuff. Inheritance is the specific part of OOP that is the most problematic.
I once read the code for a GUI library in Java, and I couldn't find the code the Button class. I just found fragments of it, buried deep in several places...
@@skaruts Intellij tells you every class that implement an actual function, and java always show the full stacktrace when an exception occurs.
Inheritance is good when it's in good measure, on java I also often use the "static" keyword to do regular functional style programing.
I think abusing Inheritance can make code harder to read or look at, you can see "FizzBuzzEnterpriseEdition" for a good example of that.
@@youtubeenjoyer1743 Java restrictions that the JVM impose enable it to be more easily debugged.
@@skaruts Well, Java built-in Swing/AWT library is over engineered, in java button rendering and other random stuff is handled by LAF (Look and feel)
LAF is a cool feature, but it sure does make the java swing/awt code a nightmare to understand because of it.
if not oop, then what?
When writing algorithms, functional code is much better.
Procedural code + functions / procedures wherever you end up repeating yourself.
@@ArthurSchoppenweghauer
Functional programming goes step further. In functional programming, you write it stateless.
C++ however sucks there because recursion and all functions calling functions can easily cause stack overflow, so there are are better languages to express algorithms.
A lousy programmer tends to blame their surroundings instead of blaming themselves.
Maybe the the guy who single-handedly wrote Dyad is just a lousy programmer. But I doubt it.
Cope.
Are you going to tell me that his rewrite is less readable? Are you ignoring the fact that this supposedly lousy programmer was able to rewrite the code he is complaining about? Anyone can make something complicated - the fact that people don't want to spend time navigating bespoke and unnecessary abstractions is not a skill issue, it's just common sense.
A lousy commentators in youtube tends to spew nonsense
Right, no such thing as bad code. Just dudes not as good as you.
Clown
You're right, I hate it. I only do elixir, FP is superior P than OOP . Although elixir is not for game development. That being said shout out to pikdum/thistle_tea, he made a vanilla wow server in elixir.
Skill issue.