I think the real question at hand is one of organisation - when there's a lot of code it's difficult to keep track of it all and how it interconnects. OOP is an an attempt to solve that by making it more atomized and readable, but it's a double edged sword in that it doesn't always deliver on that promise (it can even do the opposite) and traps you into additional self-created constraints in exchange. But the trouble is we DO need to solve the organisation problem as best we can for all large software - even the act of separating source files and functions is a form of that. It's just very difficult to get right - it's a very abstract problem without clear ways to measure the efficacy of solutions. Re Jon's take - I do think he's being a bit rigid, but on the other hand if the mainstream has gone too far one way, loud advocates for the opposite can help to bring balance.
When I work on feature I need to understand the whole thing from input to output, trying to separate and atomize everything just makes it harder because I need to put a thousand atomic pieces together in my brain instead of having the whole process laid out in front of me. So we are diving code but it's only a visual division not a logical division because anyone who wants to change anything still has to read the whole thing and now the division just makes things harder to find. OOP software only cares about semantic redability, implementation and intentionality is just as important if not more import yet OOP activelity tries to obfuscate those instead of clarifying them. Your very post shows that kind of thinking that created oop: vague buzzwords. What's "organisation problems" ? what exacly are you trying to solve? You might say code size but if each feature is small them the overall size of the codebase is not relevant. There's a more nuance and fundamental issue at hand that must be clearly defined first before jumping at solutions.
Exactly, OOP started becoming popular when programs became so large that they were hard to manage (as well as GUIs). Indie developers doesn't have this programs since they don't have giant codebases where huge teams needs to collaborate that are meant to be maintained for decades. OOP is not the only way to solve this, if your language has a sophisticated module system like in F# or Ocaml that could do the trick too. The pendulum has begun to swing the other way though, with modern languages omitting inheritance in favor of interfaces. FP has also gotten some momentum.
Making everything atomic does make those atomic units more readable but it often makes the whole incomprehensible. It's like looking at sand from 1 inch away and trying to figure out the shape of the beach.
In my interpretation, he is not offering direct criticism but rather addressing its implications. This phenomenon is akin to frameworks, where individuals address a particular context-specific issue, devise a solution, and suddenly there's a push to apply it universally to all software, even when it's not relevant to the original problem. Similarly, with design patterns, while they serve a purpose, people tend to implement them ubiquitously without considering the specific contextual use case. As he suggested, the approach should be to build, and if the solution seems overly convoluted or makeshift, refine it as necessary.
When DP came out it was a big deal, the general impression was that they should become the new foundation of programming, not some tiny hyper-specific tool that you would use once in a blue moon. So people overuse them, but only because they were being guided by false expectations.
@@Vitorruy1 But also because the reuse-utopia can be a captivating dream. It was built on the extrapolation that higher levels and/or modularity is almost always a win, which was experienced as true when moving from machine code to ASM and then to procedural languages.
Pedro Nailed like a God, sometimes my criticism is that Blow's opinions are treated like hard truth by people in our field, when he actually brings thoughtful insights about it. The issue is when you see the Jhonatan stream where he starts to believe in this, making his opinion more like "the one truth" instead of discussions.
The problem is that management/corporate do not under almost any circumstance acknowledge refactoring as "real work", so programmers have to find a method for writing the "perfect" code on the first try. In a good programming environment you can write first something that works and then rewrite it to something that works and is easy to maintain, but that is not the reality of most companies.
I dont know if I was taught horribly or amazingly. For the longest time I did not realize that anything other than OO existed. I was taught that in the before time programmers made spaghetti code and no one could debug or understand it, and then OO was invented and programmers rejoiced. But I also was never taught that their were better or worse ways to solve programs, other than gotos and and similar were bad and it was worth trying to make your program logical, organized and understandable. But I never encountered anyone who tried to teach the proper way to solve a problem or how to structure your code. Just here is a bunch of programs, go solve them, if the program spits out the right answer you win. I had one class where code readability or style or whatever waas graded, but they never told you how to get better to worse grades at that, and it was a small enough part of the grade I just ignored it.
I had a similar experience with the one programming class I had to take for physics. We barely got through basic library calls and a few algorithms, so there wasn't enough time for style.
You can use Test-Driven Development to solve the confusion. The core idea is to write your tests first, then implement the simplest possible solution, then clean up your crappy code as much or as little as you want, while your test will inform you whether or not the new feature still works as expected. While all the other tests you have hopefully written before that, inform you whether the system as a whole is broken by your changes or not. If you produce working solutions, with high test coverage, reasonable performance and low bug-count over long periods of time and over multiple quarters of changing requirements - you have all the arguments in the world to write code however the **** you want. A lot of people are disgusted by writing a test first. There are reasons for why that is a good idea, but to be honest, it's fine too if you write your prototype first and then the test. It's just in human nature that the person will think to themselves "nahh you know what, why waste the time, I tested it once manually and that's good enough". Writing tests also opens up a new problem: Writing code that is actually testable. As it turns out, OOP is excellent in this regard, when done right. Keywords here are "dependency injection" and "composition over inheritance". Those things will probably not make sense to you right now, but they will do after a few years of trying to write testable, and especially, safely refactorable code. Because if one thing is for sure, it is that requirements will always change and that ALL our code sucks, three weeks from now. Being able to refactor it confidently is my number one concern. Which paradigm is used under the hood does not bother me in the least, as long as it can prove it holds up to this requirement better than the alternatives. And to the OP: There is a word for not having to care about all the implementation details all the time (including which programming paradigm, language or methodology is being used) and only focus on producing a working solution: abstraction.
@@BobrLovr Very true. As an aside, many paradigms overlap despite being seen as confusing to both paradigms. E.g. functional bros will write down a function that returns a function, and OO bros say it's too complex. Then OO bro writes down SomeFactory and functional bro says it's too complex. Meanwhile they're solving the same problems in each paradigm.
If i get my hands on an oop program, i can work with it. I can use existing class methods, inherite and all that. However, if i have to write a new program from scratch, there is no way in hell that i can do it in oop. Not that i choose not to do it, i don't know how to do it. My brain doesn't think that way, and i can't even comprehend how others think that way. The most polite way to put it, would be that for me, oop is extremely counterintuitive and an anomally from regular thinking. For me, procedural programming is a very logical way of thinking, where the program is executed in a set of sequential commands (functions are really just that as well, just organized - but they are jumped to, executed, and returned to linearly). Functional programming... I don't even know what that means. I am curious if other people think like me.
Functional programming is declarative. I think the style you’re praising is imperative, and yes I agree it’s the natural way to think through a problem. OOP is just adding more work for no actual reason. There is not a single advantage or use for it, and Im glad others see this.
Creating OO code is a skill like any other. You need to train it. People like Jonathan here just haven't explored it deep enough to reach the benefits yet.
OOP solves the problems it creates. It's abstraction for the sake of abstraction - as opposed to useful, functional abstractions. One of the problems it tries to solve is the one of modularity...but then it tightly couples data, functions and types (interfaces) which makes it inherently less modular. There are a few cases where it's useful but not that many. Nowadays I use it mostly for self-contained things like some specialized container classes.
Same, well sort of. I was learning programming and got to the point where I was starting to learn OOP and it never really felt right to me so I just kept programming without it. It just felt bad and without logic at all to add such an abstraction on top of something.
I too felt like I came quite far with OOP. Then I learnt about data-oriented design and how it actually solved problems in the way that computers _were supposed to_ - data is input, data is output, there are processes in between that can be made using functions, and we're crafting paths with less work to do using these functions which _can_ start to feel procedural-ish though they _get work done_ - oh, and during all of this, we're taking advantage of as many hardware features we can.
learning code right now and i was able to get almost everything i wanted to work with very basic oop but whenever i tried to clean up and remake it with actual oop, it was hard to make it work in the first place, cuz i was thinking about creating a framework more than sovle the main problems
Exactly my thoughts. OOP is essentially a framework! And like any other framework...by definition you don't need it. You can always use the core...the vanilla way...the procedural way.
The current "modern" languages don't support inheritance anymore for good. It probably was the misconception of what OOP is about. Everything was based on stiff and leaky inheritance based abstraction. Interfaces were and are a more lean and flexible approach, but they also are a little bit quirky and heavy in terms of computional overhead. Generics don't solve the problem either. I myself prefer to not use abstraction at all in the first place. I also duplicate code. I write simple C like functions where the parameters and the return type documents what the inputs and outputs are. But I use the abstractions provided by the stdlib. And time to time I introduce abstractions myself.
I don't know if I'm doing C++ wrong, but I always liked that objects exist, but I never liked them used unless it really gives you a benefit of making everything dead obvious. Somehow I always see objects that make no intuitive sense, that the stuff inside doesn't feel like they belong together. And building the objects the right way is so much writing ugly incoherent lines so often, just to "make it a real boy". Like it never works out of the bag. Something like a struct is usually where it still feels like it makes sense and beyond that it's just like please stop, you're building a non-existing idea of a thing and giving it so much work and attention. And when people really go in writing "proper" object-style coding, none of the actual program makes sense anymore, it's just full of all these helper keywords that don't communicate the idea.
Today I saw a “read_config_file” class. It took the config file, read it, then saved each value to a class attribute. Then an instance of this class was created and initialized with data by reading a config file. Then static global variables were created and filled with every value from the class instance. It doesn’t take a rocket scientist to realize that the global variables could have been filled with the data from the config file directly. So why did the programmer make the class to begin with? Because of bad education, bad information, and lack of common sense. People need to know it’s “okay” to toss OOP in the garbage bin. In fact, it’s healthy.
C++ objects are a pretty bad error prone implementation but if you treat it more similar to C structs it becomes simpler and has more language features to help you one of the reasons people use C++ classes alot it's because it has a few insanely useful features like scope destructors. generic copy and move interface. and compile time d parameters
@@Mallchad That is correct; you can use classes for other things than OOP. The problem with C++ and OOP is not that classes exist, it is the implication that every problem can be modeled as an interaction of independent objects that are an abstraction of a real-world concept. And that is obviously false. On the other hand, just because something is implemented in terms of a class does not make it object-oriented. It just uses a language feature to implement something. Doing OOP means thinking in objects and their interactions; you can use classes in other contexts just fine without the thing becoming OOP.
@@imagudspellr1644 Using objects is an implementation choice; thinking about a problem in terms of object interaction is object orientation. It is literally in the name. For example, I also like to group data and behavior together into a cohesive unit; however, I do not model my problem set in terms of interacting objects, but rather in terms of data and its transformation along a processing pipeline. The difference is in this example, OOP would stipulate that you look at each object (data item) individually, whereas in the data oriented approach you treat many instances of data in the same way all at once, e.g. by passing a huge array into a (member) function. The data itself has no behavior attached to it at all, but it is the center of the mental model. That is a whole other paradigm, and in many, many places goes against established OOP rules, and even if the pipeline stages may be implemented in classes, this is not object oriented. Object orientation has a very specific meaning, and just using classes for implementation does not suffice to make it OOP.
Encapsulation can be had with namespaces and structs. The problem with OOP is inheritance and overly complicated dependencies that bake in early (and usually wrong) architectural mistakes.
@@schmetterling4477 simplest self-sufficient independent encapsulation functionality can be just procedural all functionality in one file, ie class style functions c-style code.
I program under the "purposeful" paradigm. If I need an object, I'll have an object, if I need an object that can make related copies of itself and have personal functions glued to them I have a class, if I need something to be called to run a little task to return something I have a function... If I need a loop it's gonna be a for loop instead of any method most of the time, because I can't be bothered to learn 10 lookalike methods that do completely different things and most of the time require n callbacks (sloooow).
OOP wasn't invented as a broadly better way to code, but as a way to handle complexity of bigger codebases & bigger teams of developers. That's an important distinction. Jonathan, pretty much, advocates for bottom-up approach to software architecture. The bigger the codebase/team, the worse it would work. Because individual developers/systems would naturally diverge into random directions. That said, OOP hierarchy may be not the best way to handle the complexity. More functional style of coding is closer to what Jonathan says. Majority of engineers work on low-level issues, and for them, within defined boundaries of a structural unit, bottom-up likely works better than top-down. But, someone has to worry about the boundaries, and without those it'd be just a huge heap of mess. Which is why the "just do the job" mentality isn't universally applicable.
That is not why OOP was invented, either. It was invented at a time when computers had very little memory and code reuse was a necessity. OOP is one way to tell a compiler when it can reuse the same function in a different context, which avoids code duplication. At least that's the idea. In reality it doesn't do that, either, because if we need a slightly different version of the code in a derived class, then we either have to split the original function in two, three or even more sub-functions (really bad idea) or fork most of the original code (a much, much worse idea, still). Handling code reuse at compile time is a very bad idea from the get-go. The much better idea is to use runtime data type tests... which is what dynamic languages do, but that, too, comes at a high cost. Neither OOP nor functional programming are addressing complexity at all. Built in data types like Python's dictionaries and libraries like Python's scores of "batteries included" libraries do. Python's only real shortcoming are its dynamic type system and global interpreter lock. Other than that it's an ideal language model to battle complexity.
@@lepidoptera9337 Code reuse worked long before OOP. It's just a "goto" (Jump instruction) to a different place in memory. And the three pillars of OOP - encapsulation, inheritance, and polymorphism - are all about managing larger code bases.
@@SvargasName Yes, code reuse is not the problem. Automating code reuse is. That is what OOP tried to do initially, but it necessarily fails because it's a naive attempt. OOP also doesn't "manage" code bases. Your compiler strips all of your OOP boiler plate out. All it does at the compiler and language level is to increase compilation times by two orders of magnitude because of this unnecessary busy work. At the end of the day OOP is just a really, really poor form of program documentation. The only paradigm that beats OOP in stupidity was COBOL style "literal programming". ;-)
The goal of inheritance and polymorphysm is not to be code reuse automations. They were made to help bulding hierarchies in huge, hard-to-manage codebases. To manage not in a producer sense, but from programmer's perspective. The code reuse they provide is just one of tools. Same code could be reused with functions and function pointers (say, in C).
@@SvargasName Building large hierarchies is counterproductive. You are basically just hardcoding your biases about the problem into your program. That such code bases are hard to manage is a consequence of these biases. It's not a consequence of their size. The more assumptions get baked into the code, the more rigid it becomes and the harder it becomes to manage. Good code is open. It allows many different use cases. It allows user-workarounds. Reuse is a nice word, but apart from the most basic algorithms (think Knuth) it doesn't exist. A spreadsheet is a spreadsheet and a word processor is a word processor. There is virtually no overlap in that code. Neither will you find much code reuse in inherited classes. The entire reason why you have inheritance is because something is different. Let's say you have a 100 line method in the parent class. The derived class method differs in line 61-63 from the parent. What are you going to do? You are either splitting the parent method in multiple parts and you only change the smaller piece that needs changing in the derived class OR you fork the entire thing. Now you have a forking nightmare because if there is a bug in the parent method, then you have to comb through all the derived methods as well and make sure that you repair every one of these forks properly. That's just not going to happen. OOP causes more problems than it solves in such a case. Without OOP you would have simply inserted an if-then-else or switch statement that would have tested the type of the data it was operating on at runtime. That costs less than 10ns on a modern CPU. Moving that test into compile time will cost you days, weeks or months of boilerplate work and refactoring, it will rip the code apart over multiple files and make debugging a nightmare. It's the software equivalent of gunning for your own feet with a 16 inch naval gun. Don't do it.
Inheritance and class structures are such a pain in the ass... I do think there can be a place for OOP and I've found it pretty useful in game design when you need ~20 different versions of the same enemy class but slightly different. However it's grossly overused I feel to the point it just ends up being a bigger problem to manage in the end then not using it at all. Most programs in C++ should be structured like C programs for as long as you can I think. OOP should only be pulled out when all else fails. Crazy watching tutorials on TH-cam for C++ game programing and the first thing they do is make ~20 different classes just to do basic things.
There are things for which classes and objects are a good solution for, but it is rare to see those in programs smaller than 1000 lines of code. Classes and objects at the very least add a ton of overhead, and there are a ton of problem solving where trying to use objects to model it would make you lose out in a major way. I experienced one of those shortly after properly learning about objected oriented programming, and that made me immediately drop the idea of using objected oriented modeling as the core of how I conceptualize building programs and solving problems.
I think Typescript does it right with data interfaces uncoupled from logic. Unfortunately it tries to implement classical OOP as well, partly because its Javascript. My ideal language would have no classes but structural typing, data interfaces as well as syntactic sugar that converts x.method(y) to method(x, y).
The way I see it is that if your program is something big which would be referenced many times down the line in other bits of code, then it makes sense to put in a bit more effort and make it an object so it's a bit easier to make sure memory is created correctly and destroyed so too. If it's something simple or fast like a function or just code which only has one single purpose and doesn't fit as an object (i.e you create an object but it doesn't have any use of inheritance or destructors or its usage is like only once) then you just code it normally.
Exactly. This is how I programmed for 24 years until I started working as a software dev and the team forced me to use classes and abstraction for everything. Even when there’s no concrete reason to do so.
Programming in a team is very different from building our own projects. In a team there's often a coding structure already there and when adding new code you have to follow that structure. This has its pros and cons and there's a lot of times when people who implemented and enforce those code conventions don't know what they are doing
The thing I've found is that if there's no abstraction, people are more hesitant to add their own. This then leads to very different implementations for very similar problems.
@@alf5197 Yep. A struct with associated functions. With Java, C#, etc. they basically just look like void foo(&T this, int param) if written in C, which can be seen if you look into how the compiled code works.
Object Oriented is more of a management choice, helping them to stay in an illusion that they were reducing development costs by increasing modularity. For now microservices serve a similar purpose. On the techical side, OOP results from the two fundamental false assumptions: 1. Software doesn't have to be designed as a whole, it can evolve from a bunch of separately developed classes. Every new methodology diminishes the role of the design in the software development. E.g. waterfall prohibits design decisions at coding stage, and agile removes the design activity entirely. 2. The world is organized as a tree-like hierarchy of concepts. E.g. home cats and tigers had some common predecessor from whom, presumably, they have spontaneously mutated. So anyone who believes in that idea would inevitably start modelling a cat with a data type inheriting its properties from a data type representing that mythical predecessor. And often they build that predecessor type just for it being there, not because it's actually supposed to hold some essential properties.
OOP exists to solve a fundamental problem of software development - managing "state" and understanding it's effects on the code is really hard. When you're working on your own on a project with any real complexity it's hard and if you then have to get other people involved who are working on the same code it's even harder. So many critical bugs exist in software because people make assumptions about state which aren't true and often these are the hardest to identify and solve because the cause is so disconnected from the effect. The problem is that the major paradigms (functional and OOP) are both "extremist" ways to manage state in an application - either you have a totally rigid and defined state hierarchy where objects can only talk to their parents or children or you just nuke state from your program entirely. You shouldn't be applying these paradigms religiously - they exist to solve problems and so when the problems don't exist you shouldn't add complexity just out of habit. But simultaneously, you shouldn't wait until you have a problem to fix it because it's much harder to untangle a knot than to form it. Knowing how to start approaching a problem is a skill, as is knowing when is the best time to change what you've written before. You need to pay attention to the effects of your own and other's decisions to really get a sense for the best approach to any given problem rather than following some kind of blanket advice from Blow or some kind of paradigm.
Can’t find state? Insert a breakpoint, debug and check the values of variables? You still have to do that regardless of whether you use OOP or not. The truth is good code is logically organised code. Some guy could invent their logic on the spot and as long as others working on the software know that logic, it will still work. OOP is not the be all end all. It’s just one paradigm that the industry decided to adopt as their golden calf, which they worship and never question.
Thing is (pure) FP does not "nuke the state". Yes, the very basic building blocks are stateless and don't really have a concept of execution or time, but that doesn't mean you can't write stateful programs! You just write a bit of `State Foo` here, some `runState bar` there and you've successfully got some stateful computation going. It's just explicit and clearly marked in your types.
Most nuanced take on OOP vs FP I've read 👏👏👏 Sussman would be so proud considering his work on propagators does not believe in extremisms of paradigms either.
OOP is an extremist ideology. It's pillar is encapsulation, in order to ensure it, you need rigid hierarchies. Saying "OOP isn't bad just dont take it too far" makes no sense because if you don't take it far you are no longer doing OOP.
@@ifstatementifstatement2704 If you work in a truly functional way (pure functions with no side effects) no you don't. No one actually works in a purely functional way either though because it's too cumbersome and most programs require state. Breakpoints also won't magically save you from real complexity. Even in a single threaded application there's no certainty that state values will be the same at the start and the end of a block of code either because of a side effect of some called function or because the state existed and was changed outside of the program (i.e. a config file or a web service). You say that you can invent code on the spot and it will be good enough and in many instances that might be true, but in many others it isn't and when it bites you you have to fight hard to free yourself. You will make assumptions that you don't even realise as you're writing code. Sometimes these will be true, sometimes they will be false and cause bugs, sometimes they will be true at the time and later become false when either someone else or you makes a change. Categorising state into neat packages and making the only way to modify that state be through those packages ensures that you can quickly understand what state looks like and where/how it changes. That is valuable enough for many applications that it's worth enforcing across the board even in cases where individually there might have been a cleaner custom solution.
Ditto. Handmade Hero revived my programming enthusiasm. I had been so disengaged with the ephemeral frameworks and paper pushing without really realizing why.
I started to program when OO wasn't a thing, I would never go back, it's just a requirement. However I would also advise programmers to know & understand how their language/compiler (it's kinda standardized though) handles objects and what it means as for structure, memory & speed. Like, learn what is a VMT, what are static vs dynamic functions, etc. It's a tool but it shouldn't be a black box. OO is very important when working with other programmers, especially when you want to hide stuff & make it easier for others to access only what they're supposed to, and let you change the internals without breaking anything. And by other programmers, I also mean future yourself.
If you really want to "hide stuff" you simply don't give others (write) access to the source code of your module. If you do, then OOP won't save you from a colleague who doesn't like the way you are doing things, either.
@@lepidoptera9337 It's not about editing code, it's about ensuring future compatibility. For ex, you may publish a variable, as a direct access to the internal variable. If you only let people interact using that published variable, then later you can, if necessary, change that published variable to point to a function instead of the variable directly. For the user of your object, it's not gonna change anything, he's still accessing your published variable, only he's now calling a function unknowingly.
@@anothergol Future compatibility? In an industry in which APIs change monthly? Hardly. Most of the code that is being written today won't last for a year or two. The code that does last shouldn't. See Linux. That's just one horrible hack after another. If you are still worried about namespaces, then you simply haven't figured out, yet, what's really important about code. It does not make any difference to code quality if somebody changes a variable directly or through some access function. These are all band aids on gushing wounds that have absolutely nothing to do with reliability, safety and performance.
@@lepidoptera9337 APIs don't change monthly And I started a popular app in '98 and it's still active today, so.. Software lasts and has to, when it's used.
@@lepidoptera9337 Limiting how internals of a class is accessed helps with future compatibility. Say you want to change the entire implementation of a class, but not change the definition of exposed methods. This can be really difficult if variables are directly accessed by external parts of the code, especially if your new implementation doesn’t need these variables anymore. Now you need to ensure any code that uses these variables directly doesn’t break.
So true. In 1989 I bought Stanley B. Lippman's C++ PRIMER. As a mathematician and programmer I had wanted to see what all the OOP fuss was about. Reading through chapters 6&7 convinced me that OOP abstractions were an unnecessary evil (i.e. pOOP) and would never take off. While I was wrong about it's adoption, I still don't understand how so many seemingly intelligent people could fall victim to the pOOP craze. Alas it just goes to show you the reality of how blindly following a trend can lead to technological devolution and stagnation.
It has nothing to do with intelligence. The average coder is neither intelligent nor can he/she decide how to code. That decision rests with middle-managers, be it architects or project managers. Those have to report progress and other metrics to upper management and once an erroneous management style has established itself, it's very hard to go back to your superiors and say that "we are behind time and budget despite not using really bad industry practices". You can only report that "we are behind time and budget despite the BEST industry practices", even though everybody with half a brain knows that that's a lie. This is how all religions are self-perpetuating mind-viruses. They force stupid people to repeat the same mistakes as in the past.
I think it comes down to the fact that if you did game programing in the 90s, there was basically C++ and nothing else. So everyone just accepted OOP as the way you do things because that's what we had, only when Rust showed up did people start to realize C++ is rather convoluted mess and OOP is probably a bad solution to a complex problem.
Code can be horrible no matter what paradigm we use, so we may as well engineer the best solution we can and write up the findings for the specific problem....unless it's already been solved before; in which case, we talk this out and think about why this is the best paradigm to solve the problem performance wise and readability wise while minimizing/eliminating errors, NOT just blindly say "let's use OOP or Functional Programming because it's flavor of the week". That's what paradigms are for: patterns we can pick from based on problems previously solved. If the problem hasn't been solved, GREAT! Be open to new solutions and refine them as a team. After all, 80% of engineering is talking about the problem and its surface area, not _just_ going clicky clacky independently when defining the problem and designing its solution so you have something to talk about come time for the meeting 2 minutes from now that could've been an email.
I largely agree, but "talking [it] out" often means subjective reasoning though, in my experience. When you instead reason about the theoretical limits of the hardware, and its bottlenecks, then the discussions become much more rooted in reality - because you can measure how far from your target you are, and where the bad parts of the software are. Instead of just talking about anecdotal or authority-based experiences. And while I haven't found a great way to objectively reason about readability or iteration speed, we're using all the data we can and Clean Code OOP is definitely never a good pick for anything I've ever worked with. It usually seems more like a comfort pick.
@@Muskar2 Which is why we need to measure that readability first BEFORE simply "talking it out" when we find that readability is (almost) exactly the same between two pieces of code organized in different ways. I can agree that in 25+ years of "OOP Clean Code" the way Robert C Martin writes/talks about, we're nowhere closer (perhaps we've strayed further away?) to a real and clear method of SCIENTIFICALLY MEASURING the readability and maintenance of code given different problems we are solving as engineers.
@@Muskar2 Random A/B testing such that one group reads snippet 1 before reading snippet 2 while the other group reads snippet 2 first before snippet 1. We assume that both snippets deliver the same output given the same input to not muddy the waters. After each snippet, we record how fast they read through the snippet and see how accurately/precisely they understood the functionality and behavior of the snippets via multiple choice quiz. If there's no significant difference in recall/reading time, the snippet that is shorter in character/line count wins out. Making software that measures readability is gonna be a challenge, but I'm always up for a good challenge.
I have the same problem because I come from embedded/ industry background (C and C like C++) I wanted to make a game with game engines and how the established OOP was horrible. I knew how I would make the game instances to communicate with each other but the OOP was built so unintuively it took me hours to understand how I can react with different scenes and instances. It was horrible. With C I would have done it totally differently and at that point (game was small) I started to think about porting it to C. In the end I didn’t but now when it is finished I start with plain C unless the game is bigger one. But yeah I think OOP has done a lot of harm in software development community. All the projects which use OOP has been quite heavy and expensive.
I'm not a professional C or C++ programmer, but I do know my way around C pretty well. I was given someone else's C++ program to do code coverage on. So it was my first real exposure to C++. My impression was the the code was way over bloated with levels of abstraction that weren't really necessary. The actual working code was small compared to all the other definition and header files. So I agree with this video.
Object-oriented programming is very nice when used to bundle like data into conceptual things. The problem is all the formality that C++ and Java enforce around it. I quite like the CLOS but even then, my programs are always mixed paradigm. A young and inexperienced programmer wants a single paradigm to lock into so he doesn't have to learn anything. Sussman said it best - different parts of a program want to be different things. Sometimes that means modeling sometimes that means changing control flow and sometimes that means first class functions and closures instead. What even is an object? People don't even realize that you can make your own object system from some simple closures. But they're too lost in the notion of classes which is where languages like Java and C++ are too schizophrenic and rigid for their own good.
I don't agree. I think "never use classes" is as religious as "always use classes". Opponents of OOP is not automatically saying "never use classes" even though some people end op in that camp.
This is basically just "the right tool for the right job". OOP (ala Smalltalk) was designed to allow the construction of large complex systems that modeled real world processes like a company payment scheme or something, that had to be long lasting and would probably change quite a bit. Data hiding, complex domain modeling, robustness and easy of change was far more important than high performance, nor would it ever be expected that the system would be understood by one person. The original metaphor Alan Kay had was the functioning of a human cell, instead of a dog house. A single person can build a dog house pretty easily but if you scale a dog house out to the size of a cathedral it falls to pieces. You don't build a catheral the way you build a dog house. If you need to build something as complex as a human cell you need to shift to a different metaphor. That is of course the exact opposite of a low level game engine an indie dev is going to write, that is trying to squeeze performance but is a relatively small problem (ie one person can understand it) and once you have it written it is basically written, you aren't evolving it constantly nor are you modelling a particular complex problem domain. Basically use OOP to build cathedrals not dog houses.
Except that Kay himself never wrote a large system, so he wouldn't have known what was actually important or not. More importantly, OOP wasn't invented by Kay. The idea of design reuse by function reuse had been around much earlier and it wasn't invented for large programs. It was invented for programs that had to run on machines with very small memory units. What OOP really does is to move type checking from the runtime domain into the compilation. Your classes are basically just telling the compiler when to reuses an existing function. It saves you the trouble of having to carefully select from a number of similar functions called doThisOneWay(), doThisAnotherWay(), doTheSameThingSlightlyDifferentlyHere(). That, of course, was NEVER the correct way of "doing this" in the first place. The correct way would have been to define ONE universal function doThisTheRightWay() which could differentiate between the slight variations of what had to be done and how at runtime. If there was no such solution, then the way the problem was structured was wrong in the first place. OOP doesn't solve that problem... how to structure software. If anything, it loads it with additional theoretical baloney.
Many of you in comments missed his point, and will probably only realize after 15-20 years of actual hands on programming and building big systems, the problem with designing interfaces and their hierarchy with modern OOPs methodologies is when adding more features or optimizing your code in future you'll realize your interfaces are not good design and are breaking those said methodologies, because you never actually thought about what combinations of concrete classes of those interfaces would actually look like, you just assumed based on your experience, intelligence and little bit of faith.
I have been writing software for 15 years. This video is trash advice and your comment here gives away the fundamental misunderstandings which cause you to seek people like Blow for validation. To Use OOP well, one must use TDD and defer design decisions until the correct abstractions emerge. If you are unable to safely refactor your code after you have written it, that is a skill issue, not a problem with the methodologies themselves. It's like none of you weirdos read Sandi Metz or Martin Fowler. Might seem to make sense if you make things with very short life cycles, but most real life projects aren't like video games in that way.
Good take, nowadays beginner programmers are not taught how to program but how to conform to OOP principles. And that's hurting both developers and the OOP paradigm. OOP's a just a tool, often times is best to use that tool for designing your public API's yet to do this everywhere is nonsensical, why would I spend hours writing a complex interface hierarchy when it won't even be exported by the module? It may be more extendible for the future but then again I will rewrite it once when I (if I ever) need to actually extend, that is far more efficient than doing it the "OOP way" in the first place.
He is right and wrong at same time. It's like Uncle Bob says in Clear Code/Architecture, there is always a trade off and it all depends on development cycle. If you don't have any functionality and start creating very abstract, futuristic interfaces for things that are not created yet, you are really wasting your time. Specifications can change, your interface might not include every simple use case and we might decide not to use it after all. If we spend time thinking it through, sitting with graphs, designing architecture properly then it can become a solid building block but we will still have no functionality. On other hand, if we start hacking some solutions, duck taping them with if statements, not writing solid test cases but testing manually just to see if it works for common use case and jump to another task. We will create a lot of stuff really fast but it will become harder and harder to manage or modify it. Architecture always have it's price and whether you pay it early or later is a choice but you always do. In my current project I started with hacking functionalities, cleaning up code afterwards. Getting feature done, then going back, refactoring and structuring it better. Adding another feature, cleaning up, refactoring etc. Now I have solid base for architecture that is easily manageable, intuitive and scalable and it paid off as I went back to functionalities I wrote month ago (completely forgetting file content etc, it's best test of time to see how fast and how well you can navigate in code you forgot about) and could easily find what I was looking for, expand, move on. Clean Architecture really is a good read. I recommend anyone struggling with high abstraction when it comes to class hierarchy.
If statements are not duct tape. They are proof that case handling is needed. Replacing them with an object hierarchy does only one thing: it moves them from runtime to compile time. That's a waste of effort IMHO. On a modern machine an if statement executes in sub-ns while its actual lasting consequence, an instruction or data cache miss blocks the CPU for a hundred times longer. The actually important thing that the programmer has to watch out for is data and code layout, so that the cache miss doesn't happen. The decision itself is a trivial amount of overhead. One of the problems with OOP is that it is preventing us from performing those optimizations since we are leaving the decision where to locate the code at the end of the decision to the compiler.
Beginner here does coding in c++ require using and understanding classes? I am very hesitant on learning and using it because of that, i want to think of c++ like c with more features. Is it possible to not bother with classes when coding?
You are asking the wrong question. You should rather ask the question "What is a class?". As long as the class is not polymorphic, it is the same, also cost-wise, as a struct in C. So yes, you can use C++ just as C, but with more convenience,features, and power of expression.
@@r2com641 Because he keeps rambling about what people believe/are taught to believe. That's not the problem, that's just the symptom. The real problem is this: most programmers simply don't know computer science. If they did, they would never have to resort to beliefs. They would know better. The other problem is that it's not even the individual programmer who makes these poor choices. In most companies they are being made for him by the architect and/or the team leader. It doesn't matter that a programmer knows the OOP is not the right style to attack a problem. He/she doesn't get a choice. That's an organizational problem.
unix was developed to play a space trade simulation, and the first app written for graphical output was a game, so no, it was never about only solving problems, it was always also artistic.
You're missing his point completly, his point was make a program function first, whether that is a game or a untility or whatever. After the program is functional worry about how the code is structured. The way the code is structured does not change the output of the program, that is why he called it shuffling paper around. It's like changing variable names for readability might make the code better, but it has zero impact of the function of the program.
If a dev eats, drinks, and sleeps OOP, I'd ask them why aren't they using OOP in their shell scripts? (crickets) Oh yeah. There are use cases where OOP isn't appropriate. And if there's one use case, there's likely others (i.e. data retrieval, device drivers, operating systems, distributed compute, shaders, compilers, performant algorithms, or one time use programs.)
Throughout my career dogmatic was the status quo. On one particularly annoying occasion I got lectured about using OOP practices when I updated a legacy C application that was running alongside a newer C++ application. My updates to the C app were in C style, and matched the coding style of the legacy code. I believe updates should never leave fingerprints. No one should be able to tell from the coding style anyone was fiddling with the code. There should be no visible seams. My code reviewer wanted me to use C++ objects that would have required rewriting too much code for a simple update and would have left behind sasquatch sized footprints. @@bullpup1337
I once worked with a system that processed large datasets. The data was logged as flat text files, then parsed and cooked, and loaded into a large parallelized RDBMS (Netezza). A coworker was seriously arguing that our flat files were a bad implementation. We should use XML instead. We're talking about 1 terabyte flat files exploded into XML files. Btw, this was almost 20 years ago, so they were big files back then. We said "No, we will not do that." I mention an XML example, because I think it's a kind of class and object representation of data. @@Vitorruy1
That guy is basically that senior dev you meet at your job, who has 20 years of experience, spent his whole career on the same tech but never got offered the opportunity to be a tech lead or architect. And there is a huge reason why. "You end up taking on all these very large belief structures that are very hard to conform to." No, they are hard to conform to *for you*. That guy basically confessed that he absolutely can't work in a team and conform to a team thought pattern, which is why abstraction exists. So his way has to be the real way: "abstraction sucks". Which is also why this guy only released two games in something like fifteen years.
The guy wrote a compiler for his own programming language and his new game use his own game engine with his programming language, I mean, he doesn't work only for the money. Morover, you miss the point...
@@elturco9573 Reinventing the wheel is not as great an accomplishment in reality as it seems to be in your mind. We don't need more languages. We need more people who know how to use the ones we have efficiently.
I guess one can put up Alan Kays original definition of object oriented and say that C++'s is bad, but does that actually help? What Alan Kay had in mind is a lot like what we now call an agent system. Now, an agent system can sometimes be nice, with emphasis on 'sometimes'. Object orientation is useful in a much broader context. And one does not even have to have one of the famous object oriented languages. Even the linux kernel, written in C uses object orientation quite a lot. Johnathan Blow is very much correct that people have gone overboard in their usage of object orientation. It is absolutely not useful to fit all concepts in the world in some grand hierarchy of all possible stuff. Also, many objects don't need to inherit from anything and are quite well off as a standalone class. Also, some operations don't need to be methods. E.g., the sine function has no reason whatsoever to be a method, it can be a standalone function. But I also think that at least 50% of code lives quite happily inside objects. As soon as you have a bit of data and think that you would rather have people use it through a defined set of methods instead of directly being able to do anything with it, you have a case for an object. And even if you were to decide to make the data public, if there are functions that belong very strongly to the data one might as well make them methods. To summarize: there really is not all that much wrong with object orientation in C++....
Kay was very unclear about how he used words at times. Having said that, even he admitted that the design of Smalltalk was NOT a definition of OOP. Of course you can use the sine function in an OOP way... e.g. if you want it to have meaning for vectors and matrices as well (which mathematically it does). None of that is the problem with OOP. The problem is that OOP is basically program documentation (the compiler strips all of it) that forces inefficient memory layout and that leads to early (and usually wrong or at least uninformed) global design decisions that require refactoring to undo. The latter problem also happens when there are requirement changes. Now instead of just changing code to include new requirements we have to change memory layout and interfaces in addition.
@@schmetterling4477 You are right that memory layout in OOP is generally a bit less efficient. It is a price one pays for easier programming. I think your remark about changing code is wrong. When memory layout has to change, object orientation generally makes this quite a bit easier. Generally the memory layout is hidden in the private members of a class and if lucky one only has to change one class. If the memory layout is visible everywhere it may be that lots and lots of code needs to change. And if other things need to change as well, object oriented code lives at a somewhat higher level of abstraction usually meaning that change is more contained and less code needs to be changed. The thing I said earlier about paying a performance price for easier programming is true in this case as well.
@@chrisdams OOP isn't "easier programming", either. It's a lot of boilerplate. Everything that OOP can do, name spaces and runtime switches can do much, much better. Changes in memory layout require a complete refactoring in OOP languages. That is not "quite a bit easier". It's actually much harder. private/public has nothing to do with memory layout. That is all happening at the compiler level. What I am talking about is the actual position of data in the computer's memory, which is absolutely crucial to optimize cache strategies. Dynamic and interpreted languages do not even allow the programmer to access that level of control, which is absolutely deadly to performance.
I used to write business apps in BASIC, and am much happier doing them in C#. If you go around using inheritance as your only tool then of course it will be painful, but that's not how to use OOP.
I don't know what makes you so happy about C#. It's not the most terrible language in terms of productivity and maintainability, sure, but the common libraries are awful - especially the Web and ORM ones. It's not uncommon that you have configs in XAML and JSON, and then hide all the implementation details of the state machine through dependency injection and classes that are just function pointers but with vague names (like ContextOptions, ServiceProvider, Builder) and additional layers of complexity. The most managable C# codebases I've worked in have strayed far from the .NET conventions, and used T4 preprocessors and centralized the logic in SQL stored procedures and occasional extensions to generalized classes. But still depending on ephemeral web frameworks, because it pays to be trendy. I find it much better than Kotlin, PHP and JS, but it's so far from the ease and power from working in Jai-lang. And even though I'm not an old-timer who knows C very well, I still prefer verbose C to C# - because I never feel like I lose control over the hardware - and I desire more and more control, the more experience I get. I'm very surprised if you wouldn't, with your (I assume) long career.
In my perspective, all these abstraction theories are kept into industry to involve more man power knowing the fact that there more dumb people than smart people because most of programmers are not even 1 percent of what programmers in 80s could do.
Yes, abstraction is what makes programming accessible to people with a lower IQ. But that goes into all levels. A 5 million line script doesn't fit into any programmer's head, even if they have an IQ of 180. You have to start extracting behaviors and be able to say "I do not want to worry about this right now". If you take it too far, every unit can be understood by a 5th grader, but the complexity of the system's organization (putting everything together again) is skyrocketing. Let's be real, no matter how hard you try - a 5 million line codebase is doomed to be unmaintainable, no matter how many people you sit in front of it. This is why not only abstractions, but also microservices were invented. Microservices are the bane for performance and simplicity, and yet they let you limit codebases to something under, let's say, 100k lines to guarantee *someone* is able to understand it at all. I'm tired of cowboy coders who come up with greenfield projects in their basement for 10 years, apparently never having working on a large project with multiple people of varying skill levels involved, ranting about how abstraction is bad. And specifically about OOP I gotta say, people who know what they are doing barely use state or inheritance anymore. It's just a nice framework for composing behaviors, similarly to how it is done in FP. Composing them via classes gives you a lot of expressiveness, so that's nice, but I wouldn't say it's mandatory.
@@holonaut That is not what destroys projects, though. It doesn't matter if you have fifty lines or 5 million lines of code... as long as the state space of the program is small and everybody understands at all times "what the program is doing right now". Heck, we can write a three line, single variable code that nobody, not even the best mathematicians understand! It's called the Collatz Conjecture. Look it up, it's a really fun case of "gotcha with minimal effort"! In practice a "useful" program that is not a brain teaser like Collatz can accommodate a state space of dozens to probably a hundred variables before it gets really hard to understand their dependencies. Beyond that both understanding and testing become very, very hard and are generally close to impossible. Large state spaces is where bugs live. That's what a smart programmer will avoid at all cost. That and concurrency. Concurrency is the next level of hell. Been there, done that.
You can structure your code however you want when working by yourself. People are taught a certain way because some sort of industry "standard" is required when working with other people. Most people will have to work in teams when entering the workforce It would be a shitshow if everyone on a large project structured their code differently. Nobody wants to go through a bunch of unreadable, esoteric documentation while refactoring the absolute clusterfuck some guy created before leaving the company.
I’d just feed it to ChatGPT and copy paste whatever it says. If they expect me to be a robot then they’ll get a robot. Because they clearly do not want free-thinking human beings. They just want someone who will follow the same patterns and principles that are standard in the industry, without seeing if they are appropriate for the actual software in front of their noses. That makes the jobs a lot easier for devs. Clock in, clock out. Get paid. No headache.
I'm not saying OOP is the best or that it's the only way, but I find those who revile OOP to be far more dogmatic than what they accuse those who use OOP as being. He's conflating the part with the whole. OOP does not equal hierarchies of objects, per se. That's just one implementation you can do in OOP. That's not a belief structure that OOP paradigm makes mandatory to conform to. You can use OOP constructs even if your architectural approach emphasizes different design philosophies besides inheritance hierarchies.
Abstraction can be done without OOP. If you need encapsulation, then namespaces and structs are a far better choice. If you need polymorphism and inheritance, then run-time case statements are far more flexible. They only cost a few nanoseconds of runtime penalty on a modern machine, which in most cases is more than made up by the cache miss penalty that strict adherence to OOP carries.
How many people work on Insomniac Games? They share his opinion, but go even more hardcore toward being aware of the footprint of every instruction. Also, larger teams aren't necessarily a good thing. You can have 30k employees and be outcompeted by a few people who really know solve data transformation problems in a way that the compilers and hardware understand them - there's many examples of this. The most recent one I'm excited about is "Disk Voyager" from Handmade Network. I think the knowledge gap is growing because it seems very few modern developers actually have a job that requires them to understand what's under the hood.
I like author’s comments, and I actually like to program myself in a such manner. But try to lead/manage a team of junior developers without predefined OOP style)) “Just do functionality first” will quickly become spaghetti hell
Spaghetti within a module doesn't matter much. For a team of developers one has to create separation of concerns anyway. Having one person do the IO, another the UI and a third the core functionality will not result in hell but it will very soon clear up the problems at the interfaces that even a good architect may not be able to predict correctly.
I agree with most of the point Jonathan is making here but I think he's missing the (arguably) useful part and that is if you work on a big team or multiple teams across a big codebase, that belief structure helps to guess what the other person was probably thinking - a lot of context is shared if we've all read the same bible, so to speak. Obviously it goes too far, and often fast, but I think it's that concept that wasn't addressed in this clip
just because we're all worshiping at the same cargo-cult icons doesn't mean we're not worshiping cargo-cult icons. If everyone is thinking the same way, it is likely that **nobody** in the organization is aware of the shared confusion. Ok, great. You've engineered a social situation where everyone is getting along, and there's less friction. Because "shared context". But the program still sucks. Eventually the customer is going to notice.
In practice that simply doesn't work. My time working in a highly abstracted 'clean code' codebase was hell. Reading and understanding straightforward code is easy, compared to having to jump through multiple files, dozens of small functions and seven layers of abstraction just to find out how something works.
@@antongorov5275 I think so, but I will admit I've seen it done badly more often than not. It's better to say that a shared convention makes it easier for others to understand your code, and that OO is a convention. (And scaling a software team *is* a real problem)
@@Rakkoonn strong agree. "clean code" is a fiction, because it models a reality that doesn't exist. reality isn't clean, and obfuscating that reality does more harm than good.
I was called a luddite in the late 90s & early 2000s because I thought OOP was crap. I basically quit working tech because I was so frustrated with OOP. 20 years later it seems like it has gotten way more acceptable to criticize OOP thankfully.
Your problem wasn't that you were calling it out, but that you didn't know WHY it was crap. Do you know today or are you just expressing your frustration with the fact that you don't actually understand what the problems with it are?
I don't think it's more acceptable to criticize OOP. What gave you that impression? Perhaps you could convince me a little bit with the rise of Rust's popularity. But I see OOP paradigms everywhere I go. FAANG, smart devices, consumer software, IDEs etc. all by very much into OOP and seem to have no clue how much performance (and complexity reduction) they're giving up. I personally think it stems from there being such a massive demand for software, that developers don't _need_ to create great software. It just needs to be correct enough to profit.
@@Muskar2 Please take a look at just the performance problems that the OOP approach causes on machines that rely on cache memory to fill their CPU pipelines. That's pretty much every machine out there that goes past a 32 bit CPU running at 40MHz. OOP trades form for function and gives you a false sense of writing "good code". It is true, though, that lot of people don't know the first thing about computer science and they don't how their computers actually work and they think that hardcoding documentation into the program structure, which is pretty much the only thing that OOP does well, is the way to go.
@@lepidoptera9337 I'm well aware of the many problems with OOP, especially performance. But I don't think the vast majority of software developers are. That's why I'm asking you why you think so.
@@Muskar2 You said that it wasn't appropriate to criticize OOP. That's not true. Bad solutions can always be criticized, but the criticism has to be fact based rather than emotional.
Reposting this as I want to voice it directly: My take is that the dream of Smalltalk ultimately died. OOP as it was implemented failed to deliver on both of its biggest promises: encapsulation and scalability of software. Inheritance is a fundamentally flawed concept that breaks compositionality and reduces the ability to reason about code. Further, OOP is almost certainly the wrong way to express distribued algorithms, and as it happened computing moved to distributed systems (infinite streams, many cores, many machines). This is why real world OOP systems in the 2020s largely consist of hundreds of lens-like static classes that feel just like the spaghetti code OOP was designed to address. To me, this explains why virtually zero new programming languages are designed within the OOP paradigm. It’s just a waste of effort and time and there are not very many compelling reasons to do it beyond maintaining legacy software. And there’s nothing wrong with maintaining what came before! But we’re talking paradigmatics here. I argue that, however successful, these flawed implementations from decades ago have fallen out of favor for good reasons.
I'm studying high performance computing and many PDE solvers and distributed implementations are made with OOP paradigm. The fun thing is no one in my class understands what is the actual computation instead we have to simply parrot the code of the professor (which itself is a parroted copy)
What do you mean “lens-like?” I understand everything else, you are describing the “Class Oriented Programming “ style I discuss in my free course on my channel Which is not OOP at all Lots of confusion here
@@ChrisAthanas by lens-like I mean simple getters and setters that don’t use inheritance or other forms of extension; they’re basically data classes. I agree that it doesn’t follow the tenents of OOP or any other paradigm, but this is what I have continued to see over a decade of working with developers who claim OOP as the primary methodology by which they build systems. IMO this helps my argument that it just isn’t a practical solution to real-world software complexity, and it never was.
Maintaining codebases with millions of LoC with rotating team members which take minimal onboarding while not drowing in technical depth is hard to comprehend for a procedually programming game dev who produceses throwaway software every 1-3 years with a lot of crunch-time at the end.
Funny, cause I have been working on projects with rotating team members - not millions of LoC, but still subtantially big - and technical debt was pretty much present everywhere. OOP does not prevent any of that, it is just a set of rules, that we promise to follow, but since they are not straightforward and different people have different interpretations of them the end results can still be a mess. OOP might decrease the chance of that, but that is it really.
@@Salantor I worked on an amazing project that showed me that it is possible to maintain low tech debt and strict rules and it wasn't a startup, they were up for 6 years. Best part is that after a while clean code expectations become second nature and you just start thinking that way.
For real. My first job was on a dispatching system used by several hundred users. The codebase was upwards of 10 million LoC. All C++. The network layer was in C. Parts of it were written in Java and sent data to the servers using an ancient object broker protocol. We were still adding stuff to it.
I'm pretty sure the point of OOP is to get coders to conform to a teachable standard, so any one CompSci graduate can be fired and replaced with any other without affecting productivity
Not even that is the case. To be productive in an OOP framework requires quite a bit of experience. The real reason is this: all projects are late and have cost overruns. No manager wants to he fired because he didn't use OOP when all of his bosses (none of whom are computer literate) know that OOP guarantees on-time and on-budget delivery. ;-)
The problem solved by OOP or any paradigm is that it promotes a way of thinking that lends itself, more or less, to the solving of various types or problems. I'm a fan of OOP, and I find it to be a commonly useful way to think about my programs.
That only works if you are within a rather tightly restricted class of programs. In general OOP gets in the way. And even within your class you have to pray that the first architect gets it right and that the requirements don't change in a major way, otherwise you will be refactoring this weekend... and the next and the next.
Right on point. Programs are made to solve very specific problems. When you wish to solve multiple problems, you have to rethink your approach. Hasn't anyone ever wondered what the purpose of a long switch statement is? For example, you're passing in an input and the switch statement decides the output. It would have been a totally different world if instead your program knew what the input already was and passed it to the appropriate place to generate the output you need, and it would also be a totally different world if the program directly generated the output when the input was conceived instead of filtering a raw input to a switch statement or a function pointer to that type of input. You can solve the same problem in a myriad of ways in programming but each one of them carries it's own side effects or set of problems that also require solving.
Programming is one thing; developing another. Hierarchies have an ordering of topology and toponomy, but at this level many more categorization gained relevance. So yeah, the pointer is as relevant as concept as it was on it's invention. Most languages implemented this feature, and you can make use of it in programmatical and functional ways.
OOP meant Smalltalk, that's correct. But with minor work arounds you can pretty much follow any paradigm you want in C++, including proper OOP, as giant class hierarchies are often not a good way to achieve oop anyway. So the benefit of already established languages such as C++ outweighs the cost of creating a new one by far.
OOP existed long before Smalltalk and even Kay said explicitly that the design of Smalltalk does NOT define OOP. Most people aren't even getting the computer science history right on this one.
That's a good analogy. It's a seemingly good idea in theory, a lot of people sign up for it, but we don't actually know and it might have put us in a bind. But hey, writing code in any way works at the end of the day.
This take is basically wrong - most (knowledgeable) OO programmers don't start with hierarchies - you may indeed end up with some hierarchies in a large collection of types/classes, but most of the classes/types are related through the messages they pass.
Classes don't pass messages. They call member functions. The only reason to pass messages is if you are building concurrent systems, in which case... god be with you. You will need his protection. :-)
@@perprerp It's perfectly acceptable to call out some who I've seen attack others and has personally attacked me. Oh, and of course he did it on a "public forum". Why don't you worry about your own virtue, because you clearly lack any whatsoever.
@@perprerp Of course negative reinforcement helps people. If your parents had simply hit you as a child every time you threw a tantrum like this, you wouldn't be such an insufferable hypocrite. I have work to do, but will definitely put you in your place later on.
Abstracting for the sake of abstracting is bad, but OOP is really not the problem there. You find similar problems in all paradigms if you decide to make a bunch of abstractions.
At the end of the day someone has to come up with a structure. I don’t give a fuck what paradigm is used and how classes are designed. However it is I’ll adapt because I know that no matter what, the code will have to be run, tested, debugged, fixed and made to work. No amount of design is going to magically make software run as intended. The implementation of functionalities is what truly matters.
OOP is overabstraction. You have to make a class for everything and they have to be completely encapsulated which requires rigid hierarchies. The reason you think OOP is not the issue is because you are not doing OOP.
@@Vitorruy1 Sounds like you confuse OOP with the hell that is Clean Code. That shit is awful and mostly unnecessary. As for what you mention about having a class for everything, that's not really the case. Having one class per data structure is nice, but you can just make everything public and readonly if it's not going to change, minimizing boilerplate. That's useful just to know what is expected to exist. You can just use maps for everything and go crazy with unknown data structures and types, but that sucks and is why we don't do that in OOP. The hierarchies you mention exist in other systems as well. Come back once you've worked in a large team with something other than OOP. You'll have pretty much the same complaints.
@@ifstatementifstatement2704 The structure you mention will exist regardless of paradigm. It just looks different with different paradigms. If your architect is awful, then the structure will be awful to work with.
That's literally how you learn about it in SICP using Scheme. You make objects using functional constructs. It's pretty cool and made me think about OOP in a different way. (As for OOP itself: I think it's a very sophisticated tool that sometimes have it's uses, but you better be damn sure you truly need it before you actually use it because it has a significant cost in complexity. And as for inheritance part of OOP: *everyone* thinks that's bad these days anyway, Java guys have been sceptical of it for decades due to seeing how bad it can get.)
@@torb-no If you take inheritance out then OOP is really just a glorified use of structs. Your compiler doesn't care. It compiles everything into pointers (relative addresses) anyway. Your CPU doesn't speak struct and class. :-)
@@lepidoptera9337 "Glorified use od structs" is doing *a lot* of heavy lifting here. By your compiler logic, there is no such thing as functional programming as it's compiled down to programs that fundamentally mutate state (CPU registers, memory, etc). That's kinda silly, in both cases we have abstractions that exist mainly for the benefit of humans. And those abtractions can absolutely be valuable, otherwise we would all be programmig in assembly (which even itself is an abstraction, tho a fairly thin one). Regardless: OOP is way more than inheritance, but I can understand people failing to get the value of OOP if all you see it is in terms of these horrible inheritance structures. Computer science schools have definetely failed in this regard. The big problem with all of programming is how to deal with state. That is where so many of our bugs and problems lie. Proceural programming have traditionally stored a lot of state globally, and for small programs that can be fine, but it often becomes a mess. With OOP we solve this problem by storing state in objects which themselves know how to properely deal with this data and only give outside access to certain parts, thereby reducing the surface area of bugs. In a sense you can call this a struct combined with functions with specific access patterns. Hell, with extension functions in languages like Kotlin you literally can use OOP method syntax for what are static functions on objects. If you don't need polymorphism (and you often don't) that can be a reasonable way to program. Of course, functional programming takes it one step further and just tries to do away with state altogether, which is certainly what a lot of us strive for these days.
Premature abstraction has nothing to do with OOP. It's a bad practice no matter which paradigm you are using. Yes in schools they teach you to think about a hierarchy first, but I'm fairly sure teachers would screw that up equally for any other paradigm. You can build hierarchies in procedural and functional programming too. Using TDD I come up with a solution as simple as it gets, and once it runs reliably I start refactoring to a degree that is obvious to me. But I don't go overboard with it. After time passes and I see duplicated code, I may extract some things into a shared unit. I never do it the other way around.
The problem is that OOP is the religion of "architect fast, fail fast, refactor always". It's the great-grand-daddy of bad software practices. Duplicated code is, by the way, of absolutely no concern in a world that has computers with 16+GByte of memory. The few kBytes that your code duplication wastes may trigger your OCD, but they won't make any difference to your memory efficiency.
@@holonaut Just saying. Inheritance was invented to avoid code duplication when machines had 4-16kBytes of main memory. That reason was soon forgotten and then it became the religion of a failed solution that kept looking for a problem. By the time a failed biologist named Kay starts preaching it the original reasoning behind OOP had long been forgotten. OOP is really a case that should be sent for final analysis to the "history of religions" department. ;-)
@@lepidoptera9337 I don't like inheritance either and avoid it like the plague. There is nothing wrong with reusing a part of functionality via composition. Which is something you can do in any paradigm, but OOP and FP lend themselves to it pretty well. Also isn't Alan Kay like the most quoted opponent of inheritance? “OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.” ~ Alan Kay And I've never heard the idea of OOP was to reduce memory consumption. That is an absurd statement when you can just use functions instead. OOP was a response to shared global mutable state, to which procedural programming was so vulnerable. Programming paradigms are almost always about taking away power from the programmer. To reduce the ways in which they can shoot themselves in the foot
@@holonaut I agree about inheritance. It's very problematic and not an obvious solution to any serious problem. I don't know why people think that Kay thought that OOP was messaging. There is a quote of his that relates messaging to the implementation of Smalltalk rather than OOP principles in general. In your quote the kicker is "..to me...". He is uttering an opinion there, at most. I wouldn't use that as a "definition" for anything. OTOH messaging is one of the most evil and wasteful techniques in CS. It is necessary for concurrent systems... and that is the only place in the universe where it is necessary. Online apps are wasting GBytes of code on trivial problems that can be solved without a network in 8k of assembly language... because they need to pass messages over an insecure and unreliable network instead of just doing what needs to be done with a trivial function call (like modifying a string in a data base with setSurname(personPointer, "Smith")). "OOP was a response to shared global mutable state, to which procedural programming was so vulnerable." All state is global. If it isn't global, then it's not state but just a local scratch variable. All state is also mutable... so the user can modify it. What else would it be good for if nobody can modify it? Immutable state is called "a book". We store it in libraries and even then it's not completely immutable... but we have to print a new edition to make changes. ;-) The problem of rational programming IS NOT to be afraid of state. The problem is to keep state minimal and to restrict it to allowed states at all times. There are different techniques to achieve that goal (like state machines!) but procedural/functional programming paradigm wars are NOT a solution to that problem.
Hmmmmm. And how my team should understand 10M+ linese of code without OOP? How somebody should find a place where things broke and so on? OOP helps for people to understand what its mean in term of problem we are solving, give us simple and easy to use abstraction layer. Without OOP we should do same things, but with unnecessary complexity. For example - we are reading data from bunch of devices. Devices can be different, protocols and interfaces can be different, device can return same data in different format. How we are should take it all together without OOP? We should build ugly framework around and teach every new programmer how to work with it monster, and be a very carefully for any changes and adding new feature, because if some of programmer pass wrong void* - all our program just crash at runtime and for finding this bug we should build another ugly monster with bunch of abstractions and so on and so on. With OOP in C++/Java/C# style - all this stuff is checked by compiler and we are just solving problem around business and not building our own framework like its done in Linux/GTK and other complex C language project. Sorry for my bad english
How does OOP help them understand 10M LOC? It's impossible to understand 10M LOC - especially if atomized with dozens of layers of black boxes. There's a difference between "understanding" and "correct enough to profit". And I think one of the best tests are: do you have any idea what the theoretical maximum performance your application(s) could run, if it/they utilized the hardware's capabilities. It should be very easy to reason about, even for very large codebases.
@@Muskar2 OOP forces you to break your code into modules and layers. After that, you can add tests and make sure your code does what it should. Have you worked with any large C code base? Global variables for switching application states. Access to any part of the application to any other (IT IS EASIER than doing it right, every programmer after dive into project start doing that, cause - why not). A simple representation of the data that doesn't let you know what you're looking at without traverse all calls of the function (maybe for big brain programmers are obviously, but for me `OP_RESULT HANDLE_TASKS(BYTE *devices, UINT32 devices_count, INT32 *tasks, UINT32 tasks_count)` - magic until i figure out why device is just a BYTE, why task is INT32). I worked with embedded C code in the early 2000s. And it was terrible. Because every new project, even similar ones, must be started from the very beginning. Write another task scheduler, write a bunch of code to read data from sensors, write another file datastore, write a bunch of code to send telemetry to servers, write memory diagnostic tools; write your own loggers, tools for working with peripherals, another level of data security required by government organizations; for the millionth time solving problems with time, time zones, representation of text for different regions. And the transition from C to C++ made it possible to force developers to at least break it all into modules and add an abstraction layer over the hardware. Allowed us not to throw away the work of previous projects each time, but to reuse the code. And to build a full-fledged modular platform for almost any device. And about application performance. The C code was not significantly more performant than the C++ code. But there was an opportunity to support, develop and distribute work between teams.
@@stanislavsh6582 I agree that global variables aren't suitable for production code. I have only been exposed to 100k codebases in C (about a third of it generated through metaprogramming), with very small teams, but I can see how things can become a mess in larger teams if there isn't proper culture-screening. Apart from having to write everything from scratch in new companies, I would also say that C isn't very good at making it clear what good code looks like. If the standard library that was written by developers with 30+ years of experience of building great applications and APIs, then it'd be a very different story. That's one of the reasons I'm looking forward to JAI-lang becoming public. Another reason is that C has outdated concepts in it and lacks a lot of modern features. Like length-prefixed strings, modern arrays (fixed, views and resizable), static polymorphism, much better metaprogramming, basic memory management structs (pools, ring buffers, scratch pads) etc. C's strength is that it can do everything the hardware can do, and is very close to how the hardware and compiler reasons - so you have great power and control. You don't have many guard rails though, and the standard conventions aren't great. I strongly disagree that code reuse is inherently a good thing. I fell into that trap for the first decade of my career. Code should fit the problem it solves, and code reuse is a tool that should be considered carefully. You can reuse a great API, but then it needs to provide granularity that goes from automation and powerful singular statements, and all the way to controlling every tiny thing you need to. If you instead reuse something where the generalization makes compromises that gets rid of vital context in order to be reusable, handling scenarios that are never realistic - to guard against hypothetical future problems - and start creating a dependency graph of such generalized modules, then you're headed toward bloated software that end up like Windows 11 that has volume mixers from several previous versions and the latest ones are extremely sluggish to use while the oldest ones are fairly snappy. I do agree that C isn't likely to be a great language to have large teams in, unless you have a great culture that has fairly tight rules. But that's not a problem with procedural code in general - it's a problem with legacy languages. I think the problem is that procedural languages haven't been evolved very much - before Odin-lang, Jai-lang and Rust.
So I should always just start hacking away haphazardly for any new project paying no mind to the overall architectural structure of the code base, because that would be solving a problem that is irrelevant to whatever problem the project is meant to solve. And only when the project is "functional" and the code base amassed a shitton of technical debt should I go back and consider restructuring things to be more readable and maintainable. Sounds reasonable. Look I watch JB for the steaming hot takes like anyone else but this is just pissing me off because he will curse modern software for being dysfunctional in various ways due to poor programming habits, and then in the same breath talk down design patterns that we came up with to combat buggy software. I'm not even a supporter of OOP i just hate how contradictory this take is.
I assume you are being sarcastic that this is reasonable, so I'll disagree. If you know the problem domain well, sure you can architect in advance. If you do not, then doing so is just making your program harder to change. When you don't understand the domain clearly, I think it is in fact better to first solve the problem, and then step back and see what kind of mess you've made and make a decision about where to go from there. Sometimes you can simply rewrite it now that you have experience and a bunch of nice abstractions will jump out at you. OOP is too vague a term to argue about. It means different things to different people, and different things to different programming languages and problem domains.
You've got it exactly the wrong way around: If you just assume OOP by default, you can't pay mind to the overall architectural structure of the code base. Dynamic dispatch is so rarely the best way to do polymorphism it's absurd that OOP, as the term is generally used today, got as ubiquitous as it did.
If your code is written reasonably well, it is easy to extract parts of it into new classes and functions, if/when you need to do so (when it solves a real problem in your code, such as code repetition for example). If you preemptively create classes and interfaces for literally everything OOP-style, you may just be adding extra work and complexity for no reason. Maybe you know exactly what you need and that happens to be lots of OOP-style classes, but currently the average programmer who thinks OOP is a good way to design code tends to overdo it by a lot, to their own detriment.
If abstraction and object orientation is so bad why don't you write in assembly. This is the problem with software engineering rockstars, they don't get the idea, misuse it, then smear it with bunch of nonsense.
That's a really good point to make. I am beside myself that so many developers denounce abstraction. You want me to go out there and rub some sticks together until something shows up on the screen? I'll whip up an abstraction, no problem. Wait... You want me to do that every time? Why in the hell would you want to solve similar problems over and over again in potentially different ways just because you might not account for something? Even if you failed in that respect, you still have the option of making a change or worst case, solving it for that edge case. It makes no sense to me. Also, if people stopped avoiding it like the plague they might actually get better at it.
That's a strawman, but I'll assume that you're still actually asking. Abstractions aren't inherently bad. But they also have a cost. And a common problem with abstractions is when they get in the way of understanding the problem, rather than making it easier. A common misuse of abstractions is thinking that when you make an interface boundary, you can now treat it as a black box. But doing so will only make it harder to reason about - especially when the black boxes multiply to several levels. It's never a good sign when looking into the abstraction is overwhelming to understand. Not to mention, much of OOP's bad parts are about inheritance, v-tables and atomizing everything that doesn't need to be.
@@Muskar2 "a common problem with abstractions is when they get in the way of understanding the problem" I don't know how meaningful that is, because doing it badly doesn't say much about its value. I'd agree with the use of inheritance as a problem, but that's because inheritance is a stack of black boxes obscuring contracts. I think abuse and poor design is the big problem, not oop itself. Good oop is good. Bad oop is bad. There is a pretty big gap to cross between the two without a lot of resources that actually help build the intuition for it, along with a lot of bad resources.
@@TruthAndLoyalty To me, "good OOP is good, bad OOP is bad" is a common truism that doesn't add anything. No tool or strategy should be used where it isn't appropriate - that goes without saying. Procedural code also has objects. OOP doesn't have a clear definition. So you might as well be saying that good OOP is the same things you'd do in a strongly typed, procedural language with compile-time polymorphism. In my experience, OOP usually means inheritance, garbage-collected (performance careless), constructors & destructors, mapping programs after mental models, and focus on data as masses of individual encapsulated elements, in stark contrast to batches of data transformations designed to solve specific problems. And at the very minimum OOP means methods (functions attached to objects) and encapsulation. What is good OOP to you?
@@Muskar2 Do You need to understand what is happening in the gearbox to drive a car? Understanding gear shifts is enough, also universal gearbox interface allows cars to be produced with both manual and automatic configurations while having minimal impact on the rests of the components (like engine type for example). Am i wrong? Also data orientation does not invalidate object orientation. Both of those are tools you need to learn to understand when to use appropriate one.
associating behavior with classes was the brilliant improvement that OOP brought to the programming world. All of the other stuff: polymorphism, class inheritance, GC... that's the stuff that broke things.
@@schmetterling4477 I'd call it more organization but, yeah, that's why it didn't break anything. If you want to write reliable code, you need to write as closely to the hardware's understanding of logic, rather than expecting the hardware to think abstractly like you.
@@venalleader2909 Exactly. What the OOP/FP/"chose your favorite programming paradigm here" spat does is to avoid the real issues in professional programming (like memory organization, state management etc..).
I still think this is a graphics centric view. In audio it's so common to have many things relating to control rate signals and many to audio rate, it's not an impediment to use a class interface for those two. It's you limit it to that level it's not practically different to using flags or function pointers . I get the world modelling objection, but there are areas where the objection is just emotional.
Object-oriented is amazing an it makes our lives easier by providing names and namespaces. Let's not confuse bad design with bad paradigm. Using pointers for ifs, really?
That's one possible implementation of inheritance. Your compiler may or may not use it. There is nothing wrong with that, by the way. Pointers are a necessary evil because it makes a difference in effort if you point to the mountain or if you move the mountain. Even on a fast CPU. He was correct that everything that one can do with OOP can be done in the runtime with if-then-else and case statements. Namespaces can be done with structs. Most of what OOP does is syntactic sugar and one can live without all of it.
@@lepidoptera9337 Every language is mostly about syntactic sugar, isn't it? You can live without OOP and also without structs and case statements. Just use MOV and registers, one can live without that nonsense. Not sure how long though
@@sergeibatiuk3468 That's an important insight. All our CPUs understand are arithmetic, logic and program flow instructions (branches and subroutine calls). They have different addressing modes for data that we abstract into pointers and references. Everybody should keep in mind that no matter what they are writing, it ends up as a stream of those instructions. I had a chance to be TA on an introductory computer science course when I was a student. We actually taught our students to analyze their compiler's assembly output. It's amazing how much one can learn about compilers, languages and CPUs by looking at that. It does, after all, entail the condensed expertise of the compiler designer's knowledge about the architecture and the language. I have done some symbolic assembly programming in the deep past (without knowing much about assembly, at all) and it was far easier than I imagined. People have this horror of low level programming that is unsupported by evidence. As long as the assembler and linker are doing the address calculations and symbolic names are available for memory locations and jumps, it's almost as easy as C IMHO. The main downside is that optimizing compilers can do a far better job than humans can with regards to optimization, so the techniques is obsolete for that reason alone. What gets me all the time (maybe my brain is not good at left/right) is endianness and byte-alignment. That's something high level languages don't do well, either. Many are even ignoring the problem by not giving access to memory layout (which is bad for many problems).
@@sergeibatiuk3468 Pointers are not. They are fundamental to achieve reasonable performance. I can live without OOP forever. I can't live without pointers (whether they are explicit or implicit) for even ten minutes. I would suggest you learn some introductory computer science.
The concerns you are addressing aren't related to Object-Oriented Design but to Waterfally-like organizations that ask to think & plan ahead. It is absolutely not tied to Object-Oriented Design whatsoever. It just happened that OOP has been so prevalent that design phase often incurs up-front design. The same problem can happen for a Structured Program or a Functional Program, it's just not that common to use these paradigms. And that's why Agile in the first place. If you listen to the proponent of Agile such as Kent Beck or Robert Martin, they're also fond of Object-Oriented Design and are perfectly able to fit OOD into Agile. The idea isn't to waste time on papers and design documents and al. The idea is to sketch a working program (first, make it work) and THEN make it a robust solution (then make it right) if required / if reasonable. That is a perfectly fine way to do OOD and once again is unrelated to what you say is "the problem" with OO but rather the problem with IT management.
Object oriented programming doesnt mean "pre planning" or this "uml modeling" thing that people do. You'll never "pre plan" code thats any good, I'm not smart enough, you're not smart enough. You absolutely should just start writing code, ideally through TDD in my opinion, and this would conform to his idea here that you need to begin immediately solving problems. TDD just helps with ensuring you're solving tiny problems.
This is a dumb take. Yes, when planning software in OOP you are doing some prework before actually coding, but isn't that, the "paperwork" planning phase, also the case for any other large software project, even with a non-OOP paradigm? Or is he suggesting that teams should just start writing code immediately, without having worked out a coordinated plan and software structure in mind to make everything fit together? And no, you don't HAVE to adherre strictly to OOP principles, you can write object-oriented code without, for example, writing getters and settterrs for everything. "So even the term object oriented is wrong, it means smalltalk, not C++" Who claims that OOP is a synonyme for C++? OOP is a way to program, it is not tied to any programming language.
The problem with OOP is not that you are asked to do architecture but that OOP makes false assumptions about the structure of your problem (because they are independent of your actual problem). In the real world methods and the data they are acting on are usually not neatly grouped. Dependencies form graphs, not trees. Dependencies also tend to be fluent during the development process. OOP suggests that freezing them very early is a good idea. In reality that's a horrible idea that will lead to endless refactoring.
Dear young developers watching this video, please do not listen to this incredibly shallow and silly take from JBlow. Certain problems with will DEFINITELY benefit from OOP abstractions and/or well-chosen design patterns, you can't replace them by just "throwing in a function pointer", as our big brained presenter suggested. There is a reason why OOP became so popular as features and software complexity increased exponentially. Sure you can write functions for everything, but this is a dumb self-limiting, dogmatic approach that will not grant you anything but headaches. Many junior/young devs fall into this kind of dogmatic thinking, that they should never do this, or always do that, etc. Don't think like that, problems are unique, and having all of the tools at your disposal, and understanding them WELL will be your biggest asset.
How is your take any more nuanced or instructive than what Blow is saying? Dogmatically believing that any one toolset is "the correct way" is wrong. That's part of what Blow is saying. And that you shouldn't try to fit a generalized abstraction to real-world problems. Solve the problem at hand. Discover the patterns that you need. Invent patterns. Whatever. But don't start with religious adherence to The Pattern. I don't understand why this is controversial.
@@justinj4394He says "people USED to solve problems in the 80s etc etc" and that we don't solve problems anymore with things like OOP and design patterns, but rather we create problems. Adding those abstractions and patterns for him is just, nothing, it doesn't solve anything. He says "if you go to program in C++ object oriented, you create a hierarchy of objects", which he calls "the framework you've decided on" which doesn't solve any problems". Just referring to OOP as just "a hierarchy of objects" is a gross oversimplification, which he only uses to justify his hard-headed stance. He fails to realize that laying down a thought out framework for your program, whether its founded in OOP or something else, is exactly how most software needs to be written on the vast majority of real projects (not just gamedev). I can't tell you how many times I've had to refactor or clean up after other programmers who were like "just get it to do the thing you want, write a function here and there, solve the problem, see it working". Well, in the real world, you don't get paid to go back and completely refactor your sloppy unmaintainable code, especially if it is in production. You have to make decisions and commit to them, then hope you've made the right ones as your scope and requirements change. I have 20 years of experience as a senior dev / systems architect, in the real world you mostly cripple your timelines, deliverables and create nonsense work with that line of thinking. OOP and design patterns are for solving higher-level problems, not just deciding whether you're gonna use a few classes and virtual methods when implementing your noise generating algorithm. He doesn't draw a clear line between high level architectural design decisions and solving isolated technical problems. This is because he has made a career of staying in the weeds, he knows the nitty gritty quite well, but probably would not do very well working at large bank or another institution where a large number of massive systems need to operate in an orchestrated way.
I agree. I don’t think Blow has ever worked in a large team setting making truly complex software. There is no one magical best paradigm or framework, but if you have a hundred devs working on some giant architecture and you are just winging it “solving real problems” you’re going to end up with a disastrously broken and un maintainable code base
Games like Witness certainly qualify as "truly complex software." Your comment about a project with "a hundred devs" is too big a topic to discuss in TH-cam comments. But it suffices to say that most features in most companies don't have a hundred devs. And when they do, sometimes it's because they've overcomplicated the design with their chosen paradigm. I'm obviously not suggesting that OOP is "wrong." I'm just saying that there aren't any easy answers, either. @@jtms1200
You don't think Jon ever worked on truly complex software? How do you get more complex than video games? Did you ever consider how many complex systems they need? He writes his own engines btw. edit: Also, he is currently working on his own language.
As always he takes some good idea like "too much abstraction is bad" and runs with it till it becomes ridicilous. OOP is good. It's a very convinient, easy and efficient way to structure your programms. It's a GOOOD layer of abstraction. Of course, you need to understand what you are doing, and don't just blindly use OOP everywhere - do not replace all your "switch" statements with virtual functions - that would be really bad - if you know in advance all your cases, put it into a switch statment. But in many other cases - yes, using virtual functions instead of switch would be good.
A switch statement will cost you 3ns on a modern CPU. Replacing it with a class will cost you weeks of restructuring if you get your classes wrong. It's a no-brainer: switch statements all the way. :-)
It's like the books of religions VS real life... Welcome to the atheistic side of programming! 😅💻 Keep in mind that religions were created to keep people in line, so the atheistic side of programming should be used with caution, ensuring you know what you're doing! ⚠
I completely disagree. The reason why things like OOP were invented was not because people had too much compute power, it was because they had to solve bigger and more complex problems. Things like oop are abstractions that help you handle larger and more complex software problems. I think your whole reasoning is based on false presumptions.
You would be incorrect about that, as well. OOP was invented at a time when machines had very small memory and an optimization was needed that would allow the compiler to reuse code. It was meant as a memory compression technique. It solves a tiny problem (poorly) but does not address how to build large systems, at all. You can clearly see this in the number of failures of OOP projects.
He talks thrash about C++ and don't know that C++ is not a OOPL, Bjarne has a ton of talks where he emphasize that C++ is a multi paradigm programming language... No to mention the fact that most of the code of this guy is written in C++ in NON OOP manner, so how is C++ a OOPL? OMG...
OOP solves a problem, by using a paradigm which makes it easy to share functional blocks of code amongst many people. I was prepared to hear some intelligent counterarguments, but I found none here.
That is not the problem OOP was trying to solve in the beginning because that problem can be solved much better with libraries. The original goal of OOP was design reuse to lower memory demand for code. It does that really, really poorly while causing all kinds of performance problems and architectural nightmares.
Technically, the Sokoban game is more or less a tech demo for a programming language that he is still making. 10 years for a programming language is a bit much. C was released in '72 and K&R C was released 6 years later.
I don't really follow him, so it might come down to selection bias or sathever, but I feel like lately his takes have been becoming almost a parody of his previous takes
@@jc_dogen right, right. making your own language and compiler is the most sensible thing to do when you want to develop a Sokoban clone. because c++ is terrible, c is terrible, rust is terrible, oop is terrible, game engines are terrible... Jai is an interesting language, but we all know it won't replace any other language in any meaningful way. It's closed source, with zero adoption, no community, first announced in like 2011...
@@user-sl6gn1ss8p Yeah, and it's the same with Muratori. It's always fun to hear these procedurally programming solo indies who never worked in a large team spout wannabe hot takes such as "why do we need polymorphism when we have switch statements?" or something along the lines.
Uh my dude has a weird way of phrasing... "object oriented is a belief system' is words I've never heard before. Sort of like building a chair with joinery is a belief system.
What? This argument is too abstracted. OOP solved the problem in my gamedev of being able to define functionality for an entity within that entity. Not using OOP would mean some kind of manager abstraction that checks their state and run the programs on entities. The code would be less structured and easily maintainable and readable if there was some monolith state checker deciding what happens to each entity on tick. OOP Solves a very clear organisational problem where code can be shared clearly and easily between entities. Clearest and most obvious example is enemies and player characters sharing movement code which is in the object they both extend. How is that shuffling papers around and not solving problems? For sure OOP doesn't solve anything on its own, it's a paradigm, a structure, not code. But using it isn't a problem in and of itself. There is an argument that being so strict about following OOP principles and not using any other way to solve problems (if they exist.) That's a problem, but that's not a problem with OOP itself, it's a problem with people using it as they are. (I think this is what was trying to be said without being offensive?)
Yes, graphics libraries are the best example for OOP. They are also almost the only example that truly works. In almost any other domain OOP quickly becomes a hassle for hassle's sake.
Guy, you are talking about something here you haven't really understood yet. Object oriented programming is not a dogma, but an opportunity. Not everything in programming can be solved using object orientation, but a reasonable portion of it can. Object oriented programming does not mean class hierarchies by law. Using classes gives structure. Ok, one can say that using a singleton pattern (creating just one instance of a class) can also be solved in different ways, what is completely true, but there is nothing wrong with using classes. Open your mind, and no, you don't act open minded. That also applies for your statement on taking the wrong path as developer when doing web development, what you did in another viedo. I'm 58 years old and chief architect eBusiness in a big German company and I was showing this video to my daugther, who is also doing software development. Her statement was just: Narrow minded bullshit. I do not argue that harsh , but you should really think twice about your position on modern software development, cursing keys principles without understanding the context.
I agree with you. It is not that OOP is the default. It's that problems are solved by breaking them down into smaller pieces, and it is common for those pieces to be able to be structured and manage themselves in classes.
@@alf5197 you can break down problems in pieces using functions only. What matters is how organised you are. And when in a team, they would need to understand that structure. If teams can adapt to using classes spread across multiple files, they can certainly adapt to using functions in the same file.
@@ifstatementifstatement2704 Sure, let me limit my toolbox to only using standalone functions and then have to manually take/free resources. Oh wait, that's a really lame idea, because it doesn't solve the problem of automatic resource releasing.
I am a 124 year old CEO of japanese medtech corporation. And i have shown this comment to my grandchildren. All, 46 of them in unison said " merde", which means shit in french. I wouldnt be so harsh, but OOP people are too cultist about their absolute solid beliefs.
using classes != OOP. OOP is 100% a dogma. The "oriented" part of it means classes are the smallest unit of the program. This hybrid and flexible approach you propose is not OOP but something else.
OOP is not Smalltalk. Smalltalk is a programming language. OOP is a programming paradigm. The biggest problem with OOP is the Object-Relational Impediment Mismatch, and that issues is not directly an OOP problem but more of a divergence between the way we model real world objects and the way we store information about them.
Complete nonsense. Most of these Paradigms and "belief structures" were invented way before the 80s. Think about Lisp. Also code from the 80s was horrible. If that stuff worked we would still be coding the same way today. Facebook did what you said and they learned that the hard way.
I think he's right to imply there is a lot of wastage nowadays, but also I think he's too used to working by himself and with the tiny number of people who can work with him. In places where there are hundreds or even thousands of engineers, rightly or wrongly, they're working in domains of complexity beyond what one person or a small team can manage cognitively. He's very derisive of web development for some reasonably good reasons but also misses that web programmers have to be more aware of certain scaling, security and performance issues than with other styles of programming when you own the whole machine. I do like a good Jonathan Blow rant but there's a bit of baby and bathwater, too
Yeah, Dijkstra was broadly thinking about things like this in the 60s at least, even if these specific paradigms weren’t realized or realizable yet. Even more broadly, mathematicians cared about how problems were solved as well as merely solving them hundreds of years earlier, in some cases even arguably thousands of years earlier. You can waste time by focusing too much on abstractions and elegance for small and unimportant tasks, but you can also waste time by focusing on them too little when the problem is sprawling and long-term. It’s an inherent trade-off in problem-solving, but I would say that I think it’s much easier to underestimate complexity and long-term effects than the reverse.
@@jmxtoob In more experience, the more complex the project, the least OOP is used. Which is ironic for a philosophy designed around "managing complexity"
"We don't solve REAL problems anymore" The state of the internet circa 2023 is absolutely unprecedented. Computers literally couldn't talk to eachother reliably prior to the mid 2000s. Windows machines and Linux machines required heavy middleware to send packets of structured data. Every company had their own way of doing things that was incompatible with everyone else. The invention of REST and SOAP as transfer protocols literally allowed any computer and any application written in any language to reliably communicate. This was a huge problem in the software/internet world. This problem has been solved. So don't tell me that programmers don't solve "real" problems anymore.
also compare games, software for 3D rendering, simulation, data routing, not to mention all the AI related stuff, etc etc, almost everything is crazy more advanced and way more complex nowadays. Not saying nothing was lost in the way, and I sure agree a lot of times people can miss the forest for the threes, or take tools for creeds and what not, but this take about not solving real problems is just really weird.
Programmers today patch code together. They get a pre-made file structure, get some pre-made clean code design, import libraries, copy paste code into methods and create a config file. Worse yet, they download docker images and it’s all good to go. Where’s the fucking fun in all that?!
@@ifstatementifstatement2704 They really did take the fun out. The best part of writing a backend back in the day was when it randomly crashed due to buffer overflows. Or when you forgot to correctly handle bad http data from the client and have the program try to process garbage data. These days a programmer can setup a functioning backend, frontend, and database; host it on any computer that supports docker, and have it be accessible to the entire world within about 3 hours. No fun at all.
Agreed. Software is used to solve more complex problems than ever, we got a protocol standardized for almost every kind of common problem, distributed systems have become the norm with 99.999% uptime SLAs for big companies, and my man is like "engineers dont engineer anymore". Hard disagree. It's easy to look at shitty chat app XY written in Electron, using 4GBs of RAM and be cynical, but if you do that you also got to look on the other end of the spectrum and see how awesome a lot of the software is that we use day to day.
While the OOP kool-aid is terrible, whether or not you are solving a real problem is independent from how you choose to visualize and tackle it. Whatever makes sense for you mentally as a code layout, provided you arent doing insane things with memory or stuff like that, is not related to whether your program is solving problems or not. You could just as easily write a procedural style program that doesnt solve anything. This is a small-brain take from Jon here imo, he probably was just mad about something else.
@@ChrisAthanas You can't even do a Google search for it? What are you? An intellectually lazy kid in a cold basement? Here, let me give you some attention. :-)
@@ChrisAthanas Alan Kay himself. He said that messaging was an implementation detail of Smalltalk. It was not meant as a definition of OOP. Other than that... OOP is older than Kay's work on it, but you will have to research that yourself. When you do, you will find that it was originally meant as a memory optimization technique.
I think the real question at hand is one of organisation - when there's a lot of code it's difficult to keep track of it all and how it interconnects. OOP is an an attempt to solve that by making it more atomized and readable, but it's a double edged sword in that it doesn't always deliver on that promise (it can even do the opposite) and traps you into additional self-created constraints in exchange.
But the trouble is we DO need to solve the organisation problem as best we can for all large software - even the act of separating source files and functions is a form of that. It's just very difficult to get right - it's a very abstract problem without clear ways to measure the efficacy of solutions.
Re Jon's take - I do think he's being a bit rigid, but on the other hand if the mainstream has gone too far one way, loud advocates for the opposite can help to bring balance.
When I work on feature I need to understand the whole thing from input to output, trying to separate and atomize everything just makes it harder because I need to put a thousand atomic pieces together in my brain instead of having the whole process laid out in front of me.
So we are diving code but it's only a visual division not a logical division because anyone who wants to change anything still has to read the whole thing and now the division just makes things harder to find.
OOP software only cares about semantic redability, implementation and intentionality is just as important if not more import yet OOP activelity tries to obfuscate those instead of clarifying them.
Your very post shows that kind of thinking that created oop: vague buzzwords. What's "organisation problems" ? what exacly are you trying to solve? You might say code size but if each feature is small them the overall size of the codebase is not relevant. There's a more nuance and fundamental issue at hand that must be clearly defined first before jumping at solutions.
Exactly, OOP started becoming popular when programs became so large that they were hard to manage (as well as GUIs). Indie developers doesn't have this programs since they don't have giant codebases where huge teams needs to collaborate that are meant to be maintained for decades. OOP is not the only way to solve this, if your language has a sophisticated module system like in F# or Ocaml that could do the trick too. The pendulum has begun to swing the other way though, with modern languages omitting inheritance in favor of interfaces. FP has also gotten some momentum.
Making everything atomic does make those atomic units more readable but it often makes the whole incomprehensible. It's like looking at sand from 1 inch away and trying to figure out the shape of the beach.
@@gileee Its a very delicate balance and also personal preference.
count on Jon to be unreasonably rigid and self-oriented
In my interpretation, he is not offering direct criticism but rather addressing its implications. This phenomenon is akin to frameworks, where individuals address a particular context-specific issue, devise a solution, and suddenly there's a push to apply it universally to all software, even when it's not relevant to the original problem. Similarly, with design patterns, while they serve a purpose, people tend to implement them ubiquitously without considering the specific contextual use case.
As he suggested, the approach should be to build, and if the solution seems overly convoluted or makeshift, refine it as necessary.
When DP came out it was a big deal, the general impression was that they should become the new foundation of programming, not some tiny hyper-specific tool that you would use once in a blue moon.
So people overuse them, but only because they were being guided by false expectations.
@@Vitorruy1 But also because the reuse-utopia can be a captivating dream. It was built on the extrapolation that higher levels and/or modularity is almost always a win, which was experienced as true when moving from machine code to ASM and then to procedural languages.
Pedro Nailed like a God, sometimes my criticism is that Blow's opinions are treated like hard truth by people in our field, when he actually brings thoughtful insights about it.
The issue is when you see the Jhonatan stream where he starts to believe in this, making his opinion more like "the one truth" instead of discussions.
The problem is that management/corporate do not under almost any circumstance acknowledge refactoring as "real work", so programmers have to find a method for writing the "perfect" code on the first try. In a good programming environment you can write first something that works and then rewrite it to something that works and is easy to maintain, but that is not the reality of most companies.
I dont know if I was taught horribly or amazingly. For the longest time I did not realize that anything other than OO existed. I was taught that in the before time programmers made spaghetti code and no one could debug or understand it, and then OO was invented and programmers rejoiced.
But I also was never taught that their were better or worse ways to solve programs, other than gotos and and similar were bad and it was worth trying to make your program logical, organized and understandable. But I never encountered anyone who tried to teach the proper way to solve a problem or how to structure your code. Just here is a bunch of programs, go solve them, if the program spits out the right answer you win. I had one class where code readability or style or whatever waas graded, but they never told you how to get better to worse grades at that, and it was a small enough part of the grade I just ignored it.
I had a similar experience with the one programming class I had to take for physics. We barely got through basic library calls and a few algorithms, so there wasn't enough time for style.
OO is the best we have for certain domains, and DOD is better for other domains it's not that complicated bro
You can use Test-Driven Development to solve the confusion. The core idea is to write your tests first, then implement the simplest possible solution, then clean up your crappy code as much or as little as you want, while your test will inform you whether or not the new feature still works as expected. While all the other tests you have hopefully written before that, inform you whether the system as a whole is broken by your changes or not. If you produce working solutions, with high test coverage, reasonable performance and low bug-count over long periods of time and over multiple quarters of changing requirements - you have all the arguments in the world to write code however the **** you want.
A lot of people are disgusted by writing a test first. There are reasons for why that is a good idea, but to be honest, it's fine too if you write your prototype first and then the test. It's just in human nature that the person will think to themselves "nahh you know what, why waste the time, I tested it once manually and that's good enough".
Writing tests also opens up a new problem: Writing code that is actually testable. As it turns out, OOP is excellent in this regard, when done right. Keywords here are "dependency injection" and "composition over inheritance". Those things will probably not make sense to you right now, but they will do after a few years of trying to write testable, and especially, safely refactorable code. Because if one thing is for sure, it is that requirements will always change and that ALL our code sucks, three weeks from now. Being able to refactor it confidently is my number one concern. Which paradigm is used under the hood does not bother me in the least, as long as it can prove it holds up to this requirement better than the alternatives.
And to the OP: There is a word for not having to care about all the implementation details all the time (including which programming paradigm, language or methodology is being used) and only focus on producing a working solution: abstraction.
It’s because the teachers didn’t know
These were, and still are, closely guarded secrets
Money is involved so you’re gonna get a lot of fuckery
@@BobrLovr Very true. As an aside, many paradigms overlap despite being seen as confusing to both paradigms. E.g. functional bros will write down a function that returns a function, and OO bros say it's too complex. Then OO bro writes down SomeFactory and functional bro says it's too complex. Meanwhile they're solving the same problems in each paradigm.
If i get my hands on an oop program, i can work with it. I can use existing class methods, inherite and all that. However, if i have to write a new program from scratch, there is no way in hell that i can do it in oop. Not that i choose not to do it, i don't know how to do it. My brain doesn't think that way, and i can't even comprehend how others think that way. The most polite way to put it, would be that for me, oop is extremely counterintuitive and an anomally from regular thinking. For me, procedural programming is a very logical way of thinking, where the program is executed in a set of sequential commands (functions are really just that as well, just organized - but they are jumped to, executed, and returned to linearly). Functional programming... I don't even know what that means. I am curious if other people think like me.
Functional programming is declarative. I think the style you’re praising is imperative, and yes I agree it’s the natural way to think through a problem.
OOP is just adding more work for no actual reason. There is not a single advantage or use for it, and Im glad others see this.
Creating OO code is a skill like any other. You need to train it. People like Jonathan here just haven't explored it deep enough to reach the benefits yet.
OOP is couterintuitive because C++ ( for example) is based on a language designed for simulation. But yeah, I can't think in OOP either.
Another OOP snob ?@@creo_one
I'm glad I'm not the only one. This is the hardest thing for me to grasp.
OOP solves the problems it creates. It's abstraction for the sake of abstraction - as opposed to useful, functional abstractions.
One of the problems it tries to solve is the one of modularity...but then it tightly couples data, functions and types (interfaces) which makes it inherently less modular.
There are a few cases where it's useful but not that many. Nowadays I use it mostly for self-contained things like some specialized container classes.
I kinda learned your point the hard way.
Same, well sort of. I was learning programming and got to the point where I was starting to learn OOP and it never really felt right to me so I just kept programming without it. It just felt bad and without logic at all to add such an abstraction on top of something.
I too felt like I came quite far with OOP. Then I learnt about data-oriented design and how it actually solved problems in the way that computers _were supposed to_ - data is input, data is output, there are processes in between that can be made using functions, and we're crafting paths with less work to do using these functions which _can_ start to feel procedural-ish though they _get work done_ - oh, and during all of this, we're taking advantage of as many hardware features we can.
learning code right now and i was able to get almost everything i wanted to work with very basic oop but whenever i tried to clean up and remake it with actual oop, it was hard to make it work in the first place, cuz i was thinking about creating a framework more than sovle the main problems
Exactly my thoughts. OOP is essentially a framework! And like any other framework...by definition you don't need it. You can always use the core...the vanilla way...the procedural way.
> ...the procedural way.
Which is really the only way. OO decays to step-1, step-2, step-3. Some people like their style over substance.
The current "modern" languages don't support inheritance anymore for good. It probably was the misconception of what OOP is about. Everything was based on stiff and leaky inheritance based abstraction.
Interfaces were and are a more lean and flexible approach, but they also are a little bit quirky and heavy in terms of computional overhead.
Generics don't solve the problem either.
I myself prefer to not use abstraction at all in the first place. I also duplicate code. I write simple C like functions where the parameters and the return type documents what the inputs and outputs are. But I use the abstractions provided by the stdlib. And time to time I introduce abstractions myself.
I don't know if I'm doing C++ wrong, but I always liked that objects exist, but I never liked them used unless it really gives you a benefit of making everything dead obvious. Somehow I always see objects that make no intuitive sense, that the stuff inside doesn't feel like they belong together. And building the objects the right way is so much writing ugly incoherent lines so often, just to "make it a real boy". Like it never works out of the bag. Something like a struct is usually where it still feels like it makes sense and beyond that it's just like please stop, you're building a non-existing idea of a thing and giving it so much work and attention. And when people really go in writing "proper" object-style coding, none of the actual program makes sense anymore, it's just full of all these helper keywords that don't communicate the idea.
Today I saw a “read_config_file” class.
It took the config file, read it, then saved each value to a class attribute.
Then an instance of this class was created and initialized with data by reading a config file.
Then static global variables were created and filled with every value from the class instance.
It doesn’t take a rocket scientist to realize that the global variables could have been filled with the data from the config file directly.
So why did the programmer make the class to begin with? Because of bad education, bad information, and lack of common sense.
People need to know it’s “okay” to toss OOP in the garbage bin. In fact, it’s healthy.
C++ objects are a pretty bad error prone implementation but if you treat it more similar to C structs it becomes simpler and has more language features to help you
one of the reasons people use C++ classes alot it's because it has a few insanely useful features like scope destructors. generic copy and move interface. and compile time d parameters
@@Mallchad That is correct; you can use classes for other things than OOP. The problem with C++ and OOP is not that classes exist, it is the implication that every problem can be modeled as an interaction of independent objects that are an abstraction of a real-world concept. And that is obviously false.
On the other hand, just because something is implemented in terms of a class does not make it object-oriented. It just uses a language feature to implement something. Doing OOP means thinking in objects and their interactions; you can use classes in other contexts just fine without the thing becoming OOP.
Yes you can write "spaghetti" object code, in fact you can write 'arcane' code in any language !
@@imagudspellr1644 Using objects is an implementation choice; thinking about a problem in terms of object interaction is object orientation. It is literally in the name.
For example, I also like to group data and behavior together into a cohesive unit; however, I do not model my problem set in terms of interacting objects, but rather in terms of data and its transformation along a processing pipeline. The difference is in this example, OOP would stipulate that you look at each object (data item) individually, whereas in the data oriented approach you treat many instances of data in the same way all at once, e.g. by passing a huge array into a (member) function. The data itself has no behavior attached to it at all, but it is the center of the mental model. That is a whole other paradigm, and in many, many places goes against established OOP rules, and even if the pipeline stages may be implemented in classes, this is not object oriented. Object orientation has a very specific meaning, and just using classes for implementation does not suffice to make it OOP.
encapsulation is a better goal, a main concept in the oop. doing fall in the oop mantra stuff. only use what is actually useful.
Encapsulation can be had with namespaces and structs. The problem with OOP is inheritance and overly complicated dependencies that bake in early (and usually wrong) architectural mistakes.
@@schmetterling4477 you dont have to do extreme oop, just use what is useful.
@@schmetterling4477 simplest self-sufficient independent encapsulation functionality can be just procedural all functionality in one file, ie class style functions c-style code.
@@gsestream Totally agree. KISS (Keep It Simple Stupid) rocks.
I program under the "purposeful" paradigm. If I need an object, I'll have an object, if I need an object that can make related copies of itself and have personal functions glued to them I have a class, if I need something to be called to run a little task to return something I have a function...
If I need a loop it's gonna be a for loop instead of any method most of the time, because I can't be bothered to learn 10 lookalike methods that do completely different things and most of the time require n callbacks (sloooow).
OOP wasn't invented as a broadly better way to code, but as a way to handle complexity of bigger codebases & bigger teams of developers. That's an important distinction.
Jonathan, pretty much, advocates for bottom-up approach to software architecture. The bigger the codebase/team, the worse it would work. Because individual developers/systems would naturally diverge into random directions.
That said, OOP hierarchy may be not the best way to handle the complexity. More functional style of coding is closer to what Jonathan says. Majority of engineers work on low-level issues, and for them, within defined boundaries of a structural unit, bottom-up likely works better than top-down. But, someone has to worry about the boundaries, and without those it'd be just a huge heap of mess. Which is why the "just do the job" mentality isn't universally applicable.
That is not why OOP was invented, either. It was invented at a time when computers had very little memory and code reuse was a necessity. OOP is one way to tell a compiler when it can reuse the same function in a different context, which avoids code duplication. At least that's the idea. In reality it doesn't do that, either, because if we need a slightly different version of the code in a derived class, then we either have to split the original function in two, three or even more sub-functions (really bad idea) or fork most of the original code (a much, much worse idea, still). Handling code reuse at compile time is a very bad idea from the get-go. The much better idea is to use runtime data type tests... which is what dynamic languages do, but that, too, comes at a high cost.
Neither OOP nor functional programming are addressing complexity at all. Built in data types like Python's dictionaries and libraries like Python's scores of "batteries included" libraries do. Python's only real shortcoming are its dynamic type system and global interpreter lock. Other than that it's an ideal language model to battle complexity.
@@lepidoptera9337 Code reuse worked long before OOP. It's just a "goto" (Jump instruction) to a different place in memory. And the three pillars of OOP - encapsulation, inheritance, and polymorphism - are all about managing larger code bases.
@@SvargasName Yes, code reuse is not the problem. Automating code reuse is. That is what OOP tried to do initially, but it necessarily fails because it's a naive attempt. OOP also doesn't "manage" code bases. Your compiler strips all of your OOP boiler plate out. All it does at the compiler and language level is to increase compilation times by two orders of magnitude because of this unnecessary busy work. At the end of the day OOP is just a really, really poor form of program documentation. The only paradigm that beats OOP in stupidity was COBOL style "literal programming". ;-)
The goal of inheritance and polymorphysm is not to be code reuse automations. They were made to help bulding hierarchies in huge, hard-to-manage codebases. To manage not in a producer sense, but from programmer's perspective. The code reuse they provide is just one of tools. Same code could be reused with functions and function pointers (say, in C).
@@SvargasName Building large hierarchies is counterproductive. You are basically just hardcoding your biases about the problem into your program. That such code bases are hard to manage is a consequence of these biases. It's not a consequence of their size. The more assumptions get baked into the code, the more rigid it becomes and the harder it becomes to manage. Good code is open. It allows many different use cases. It allows user-workarounds.
Reuse is a nice word, but apart from the most basic algorithms (think Knuth) it doesn't exist. A spreadsheet is a spreadsheet and a word processor is a word processor. There is virtually no overlap in that code. Neither will you find much code reuse in inherited classes. The entire reason why you have inheritance is because something is different. Let's say you have a 100 line method in the parent class. The derived class method differs in line 61-63 from the parent. What are you going to do? You are either splitting the parent method in multiple parts and you only change the smaller piece that needs changing in the derived class OR you fork the entire thing. Now you have a forking nightmare because if there is a bug in the parent method, then you have to comb through all the derived methods as well and make sure that you repair every one of these forks properly. That's just not going to happen.
OOP causes more problems than it solves in such a case. Without OOP you would have simply inserted an if-then-else or switch statement that would have tested the type of the data it was operating on at runtime. That costs less than 10ns on a modern CPU. Moving that test into compile time will cost you days, weeks or months of boilerplate work and refactoring, it will rip the code apart over multiple files and make debugging a nightmare. It's the software equivalent of gunning for your own feet with a 16 inch naval gun. Don't do it.
Inheritance and class structures are such a pain in the ass... I do think there can be a place for OOP and I've found it pretty useful in game design when you need ~20 different versions of the same enemy class but slightly different. However it's grossly overused I feel to the point it just ends up being a bigger problem to manage in the end then not using it at all. Most programs in C++ should be structured like C programs for as long as you can I think. OOP should only be pulled out when all else fails. Crazy watching tutorials on TH-cam for C++ game programing and the first thing they do is make ~20 different classes just to do basic things.
There are things for which classes and objects are a good solution for, but it is rare to see those in programs smaller than 1000 lines of code. Classes and objects at the very least add a ton of overhead, and there are a ton of problem solving where trying to use objects to model it would make you lose out in a major way. I experienced one of those shortly after properly learning about objected oriented programming, and that made me immediately drop the idea of using objected oriented modeling as the core of how I conceptualize building programs and solving problems.
I think Typescript does it right with data interfaces uncoupled from logic. Unfortunately it tries to implement classical OOP as well, partly because its Javascript. My ideal language would have no classes but structural typing, data interfaces as well as syntactic sugar that converts x.method(y) to method(x, y).
The way I see it is that if your program is something big which would be referenced many times down the line in other bits of code, then it makes sense to put in a bit more effort and make it an object so it's a bit easier to make sure memory is created correctly and destroyed so too.
If it's something simple or fast like a function or just code which only has one single purpose and doesn't fit as an object (i.e you create an object but it doesn't have any use of inheritance or destructors or its usage is like only once) then you just code it normally.
Exactly. This is how I programmed for 24 years until I started working as a software dev and the team forced me to use classes and abstraction for everything. Even when there’s no concrete reason to do so.
Programming in a team is very different from building our own projects. In a team there's often a coding structure already there and when adding new code you have to follow that structure. This has its pros and cons and there's a lot of times when people who implemented and enforce those code conventions don't know what they are doing
The thing I've found is that if there's no abstraction, people are more hesitant to add their own. This then leads to very different implementations for very similar problems.
Just remember, classes do not always mean abstraction. You can make very very simple classes for the sole purpose of managing their own resources.
@@alf5197 That is an abstraction of memory management.
@@alf5197 Yep. A struct with associated functions. With Java, C#, etc. they basically just look like
void foo(&T this, int param)
if written in C, which can be seen if you look into how the compiled code works.
Object Oriented is more of a management choice, helping them to stay in an illusion that they were reducing development costs by increasing modularity. For now microservices serve a similar purpose. On the techical side, OOP results from the two fundamental false assumptions:
1. Software doesn't have to be designed as a whole, it can evolve from a bunch of separately developed classes. Every new methodology diminishes the role of the design in the software development. E.g. waterfall prohibits design decisions at coding stage, and agile removes the design activity entirely.
2. The world is organized as a tree-like hierarchy of concepts. E.g. home cats and tigers had some common predecessor from whom, presumably, they have spontaneously mutated. So anyone who believes in that idea would inevitably start modelling a cat with a data type inheriting its properties from a data type representing that mythical predecessor. And often they build that predecessor type just for it being there, not because it's actually supposed to hold some essential properties.
OOP exists to solve a fundamental problem of software development - managing "state" and understanding it's effects on the code is really hard. When you're working on your own on a project with any real complexity it's hard and if you then have to get other people involved who are working on the same code it's even harder.
So many critical bugs exist in software because people make assumptions about state which aren't true and often these are the hardest to identify and solve because the cause is so disconnected from the effect.
The problem is that the major paradigms (functional and OOP) are both "extremist" ways to manage state in an application - either you have a totally rigid and defined state hierarchy where objects can only talk to their parents or children or you just nuke state from your program entirely. You shouldn't be applying these paradigms religiously - they exist to solve problems and so when the problems don't exist you shouldn't add complexity just out of habit. But simultaneously, you shouldn't wait until you have a problem to fix it because it's much harder to untangle a knot than to form it.
Knowing how to start approaching a problem is a skill, as is knowing when is the best time to change what you've written before. You need to pay attention to the effects of your own and other's decisions to really get a sense for the best approach to any given problem rather than following some kind of blanket advice from Blow or some kind of paradigm.
Can’t find state? Insert a breakpoint, debug and check the values of variables? You still have to do that regardless of whether you use OOP or not.
The truth is good code is logically organised code. Some guy could invent their logic on the spot and as long as others working on the software know that logic, it will still work.
OOP is not the be all end all. It’s just one paradigm that the industry decided to adopt as their golden calf, which they worship and never question.
Thing is (pure) FP does not "nuke the state". Yes, the very basic building blocks are stateless and don't really have a concept of execution or time, but that doesn't mean you can't write stateful programs!
You just write a bit of `State Foo` here, some `runState bar` there and you've successfully got some stateful computation going. It's just explicit and clearly marked in your types.
Most nuanced take on OOP vs FP I've read 👏👏👏
Sussman would be so proud considering his work on propagators does not believe in extremisms of paradigms either.
OOP is an extremist ideology.
It's pillar is encapsulation, in order to ensure it, you need rigid hierarchies.
Saying "OOP isn't bad just dont take it too far" makes no sense because if you don't take it far you are no longer doing OOP.
@@ifstatementifstatement2704 If you work in a truly functional way (pure functions with no side effects) no you don't.
No one actually works in a purely functional way either though because it's too cumbersome and most programs require state.
Breakpoints also won't magically save you from real complexity. Even in a single threaded application there's no certainty that state values will be the same at the start and the end of a block of code either because of a side effect of some called function or because the state existed and was changed outside of the program (i.e. a config file or a web service).
You say that you can invent code on the spot and it will be good enough and in many instances that might be true, but in many others it isn't and when it bites you you have to fight hard to free yourself.
You will make assumptions that you don't even realise as you're writing code. Sometimes these will be true, sometimes they will be false and cause bugs, sometimes they will be true at the time and later become false when either someone else or you makes a change. Categorising state into neat packages and making the only way to modify that state be through those packages ensures that you can quickly understand what state looks like and where/how it changes. That is valuable enough for many applications that it's worth enforcing across the board even in cases where individually there might have been a cleaner custom solution.
I completely agree with this. Hierarchies are disgusting!
Datastructures are where it's at! A model? Use a data structure.
Yeah and then it's not really object oriented any more
@@Boxing_Gamer Correct. The problem in OOP is not objects, it's the "oriented" part.
Let me guess:
1) Bloat.
2) Dozens of layers of inheritance, the inheritance pyramid of doom.
I'd say this is a large reason why I, and likely many others, tend to burn out these days. Shuffling papers vs solving actual problems.
Yes, that's a good way of putting my feelings, which I've had trouble describing recently.
Ditto. Handmade Hero revived my programming enthusiasm. I had been so disengaged with the ephemeral frameworks and paper pushing without really realizing why.
I started to program when OO wasn't a thing, I would never go back, it's just a requirement. However I would also advise programmers to know & understand how their language/compiler (it's kinda standardized though) handles objects and what it means as for structure, memory & speed. Like, learn what is a VMT, what are static vs dynamic functions, etc. It's a tool but it shouldn't be a black box.
OO is very important when working with other programmers, especially when you want to hide stuff & make it easier for others to access only what they're supposed to, and let you change the internals without breaking anything. And by other programmers, I also mean future yourself.
If you really want to "hide stuff" you simply don't give others (write) access to the source code of your module. If you do, then OOP won't save you from a colleague who doesn't like the way you are doing things, either.
@@lepidoptera9337 It's not about editing code, it's about ensuring future compatibility. For ex, you may publish a variable, as a direct access to the internal variable. If you only let people interact using that published variable, then later you can, if necessary, change that published variable to point to a function instead of the variable directly. For the user of your object, it's not gonna change anything, he's still accessing your published variable, only he's now calling a function unknowingly.
@@anothergol Future compatibility? In an industry in which APIs change monthly? Hardly. Most of the code that is being written today won't last for a year or two. The code that does last shouldn't. See Linux. That's just one horrible hack after another.
If you are still worried about namespaces, then you simply haven't figured out, yet, what's really important about code. It does not make any difference to code quality if somebody changes a variable directly or through some access function. These are all band aids on gushing wounds that have absolutely nothing to do with reliability, safety and performance.
@@lepidoptera9337 APIs don't change monthly
And I started a popular app in '98 and it's still active today, so..
Software lasts and has to, when it's used.
@@lepidoptera9337 Limiting how internals of a class is accessed helps with future compatibility. Say you want to change the entire implementation of a class, but not change the definition of exposed methods. This can be really difficult if variables are directly accessed by external parts of the code, especially if your new implementation doesn’t need these variables anymore. Now you need to ensure any code that uses these variables directly doesn’t break.
So true. In 1989 I bought Stanley B. Lippman's C++ PRIMER. As a mathematician and programmer I had wanted to see what all the OOP fuss was about. Reading through chapters 6&7 convinced me that OOP abstractions were an unnecessary evil (i.e. pOOP) and would never take off. While I was wrong about it's adoption, I still don't understand how so many seemingly intelligent people could fall victim to the pOOP craze. Alas it just goes to show you the reality of how blindly following a trend can lead to technological devolution and stagnation.
It has nothing to do with intelligence. The average coder is neither intelligent nor can he/she decide how to code. That decision rests with middle-managers, be it architects or project managers. Those have to report progress and other metrics to upper management and once an erroneous management style has established itself, it's very hard to go back to your superiors and say that "we are behind time and budget despite not using really bad industry practices". You can only report that "we are behind time and budget despite the BEST industry practices", even though everybody with half a brain knows that that's a lie. This is how all religions are self-perpetuating mind-viruses. They force stupid people to repeat the same mistakes as in the past.
I think it comes down to the fact that if you did game programing in the 90s, there was basically C++ and nothing else. So everyone just accepted OOP as the way you do things because that's what we had, only when Rust showed up did people start to realize C++ is rather convoluted mess and OOP is probably a bad solution to a complex problem.
Code can be horrible no matter what paradigm we use, so we may as well engineer the best solution we can and write up the findings for the specific problem....unless it's already been solved before; in which case, we talk this out and think about why this is the best paradigm to solve the problem performance wise and readability wise while minimizing/eliminating errors, NOT just blindly say "let's use OOP or Functional Programming because it's flavor of the week".
That's what paradigms are for: patterns we can pick from based on problems previously solved. If the problem hasn't been solved, GREAT! Be open to new solutions and refine them as a team. After all, 80% of engineering is talking about the problem and its surface area, not _just_ going clicky clacky independently when defining the problem and designing its solution so you have something to talk about come time for the meeting 2 minutes from now that could've been an email.
EXACTLY!
I largely agree, but "talking [it] out" often means subjective reasoning though, in my experience. When you instead reason about the theoretical limits of the hardware, and its bottlenecks, then the discussions become much more rooted in reality - because you can measure how far from your target you are, and where the bad parts of the software are. Instead of just talking about anecdotal or authority-based experiences. And while I haven't found a great way to objectively reason about readability or iteration speed, we're using all the data we can and Clean Code OOP is definitely never a good pick for anything I've ever worked with. It usually seems more like a comfort pick.
@@Muskar2 Which is why we need to measure that readability first BEFORE simply "talking it out" when we find that readability is (almost) exactly the same between two pieces of code organized in different ways.
I can agree that in 25+ years of "OOP Clean Code" the way Robert C Martin writes/talks about, we're nowhere closer (perhaps we've strayed further away?) to a real and clear method of SCIENTIFICALLY MEASURING the readability and maintenance of code given different problems we are solving as engineers.
@@SimGunther So how do you propose we measure readability?
@@Muskar2 Random A/B testing such that one group reads snippet 1 before reading snippet 2 while the other group reads snippet 2 first before snippet 1.
We assume that both snippets deliver the same output given the same input to not muddy the waters. After each snippet, we record how fast they read through the snippet and see how accurately/precisely they understood the functionality and behavior of the snippets via multiple choice quiz.
If there's no significant difference in recall/reading time, the snippet that is shorter in character/line count wins out.
Making software that measures readability is gonna be a challenge, but I'm always up for a good challenge.
Object Oriented is not a programming solution. It is a management solution.
I have the same problem because I come from embedded/ industry background (C and C like C++) I wanted to make a game with game engines and how the established OOP was horrible. I knew how I would make the game instances to communicate with each other but the OOP was built so unintuively it took me hours to understand how I can react with different scenes and instances. It was horrible. With C I would have done it totally differently and at that point (game was small) I started to think about porting it to C.
In the end I didn’t but now when it is finished I start with plain C unless the game is bigger one.
But yeah I think OOP has done a lot of harm in software development community. All the projects which use OOP has been quite heavy and expensive.
I'm not a professional C or C++ programmer, but I do know my way around C pretty well. I was given someone else's C++ program to do code coverage on. So it was my first real exposure to C++. My impression was the the code was way over bloated with levels of abstraction that weren't really necessary. The actual working code was small compared to all the other definition and header files. So I agree with this video.
10 secs in I thought of the Mrs. Liskov and it was C++ 😂
Object-oriented programming is very nice when used to bundle like data into conceptual things. The problem is all the formality that C++ and Java enforce around it. I quite like the CLOS but even then, my programs are always mixed paradigm. A young and inexperienced programmer wants a single paradigm to lock into so he doesn't have to learn anything. Sussman said it best - different parts of a program want to be different things. Sometimes that means modeling sometimes that means changing control flow and sometimes that means first class functions and closures instead. What even is an object? People don't even realize that you can make your own object system from some simple closures. But they're too lost in the notion of classes which is where languages like Java and C++ are too schizophrenic and rigid for their own good.
Saying "never oop" is as religious as "always oop"
I don't agree. I think "never use classes" is as religious as "always use classes". Opponents of OOP is not automatically saying "never use classes" even though some people end op in that camp.
This is basically just "the right tool for the right job".
OOP (ala Smalltalk) was designed to allow the construction of large complex systems that modeled real world processes like a company payment scheme or something, that had to be long lasting and would probably change quite a bit.
Data hiding, complex domain modeling, robustness and easy of change was far more important than high performance, nor would it ever be expected that the system would be understood by one person. The original metaphor Alan Kay had was the functioning of a human cell, instead of a dog house. A single person can build a dog house pretty easily but if you scale a dog house out to the size of a cathedral it falls to pieces. You don't build a catheral the way you build a dog house. If you need to build something as complex as a human cell you need to shift to a different metaphor.
That is of course the exact opposite of a low level game engine an indie dev is going to write, that is trying to squeeze performance but is a relatively small problem (ie one person can understand it) and once you have it written it is basically written, you aren't evolving it constantly nor are you modelling a particular complex problem domain.
Basically use OOP to build cathedrals not dog houses.
Except that Kay himself never wrote a large system, so he wouldn't have known what was actually important or not. More importantly, OOP wasn't invented by Kay. The idea of design reuse by function reuse had been around much earlier and it wasn't invented for large programs. It was invented for programs that had to run on machines with very small memory units. What OOP really does is to move type checking from the runtime domain into the compilation. Your classes are basically just telling the compiler when to reuses an existing function. It saves you the trouble of having to carefully select from a number of similar functions called doThisOneWay(), doThisAnotherWay(), doTheSameThingSlightlyDifferentlyHere(). That, of course, was NEVER the correct way of "doing this" in the first place. The correct way would have been to define ONE universal function doThisTheRightWay() which could differentiate between the slight variations of what had to be done and how at runtime. If there was no such solution, then the way the problem was structured was wrong in the first place. OOP doesn't solve that problem... how to structure software. If anything, it loads it with additional theoretical baloney.
Many of you in comments missed his point, and will probably only realize after 15-20 years of actual hands on programming and building big systems, the problem with designing interfaces and their hierarchy with modern OOPs methodologies is when adding more features or optimizing your code in future you'll realize your interfaces are not good design and are breaking those said methodologies, because you never actually thought about what combinations of concrete classes of those interfaces would actually look like, you just assumed based on your experience, intelligence and little bit of faith.
I have been writing software for 15 years. This video is trash advice and your comment here gives away the fundamental misunderstandings which cause you to seek people like Blow for validation.
To Use OOP well, one must use TDD and defer design decisions until the correct abstractions emerge. If you are unable to safely refactor your code after you have written it, that is a skill issue, not a problem with the methodologies themselves.
It's like none of you weirdos read Sandi Metz or Martin Fowler. Might seem to make sense if you make things with very short life cycles, but most real life projects aren't like video games in that way.
@@steveripberger1802"the correct way of writing OOP is to spend 90% of your time solving problems with OOP" is essentially what you just said
Good take, nowadays beginner programmers are not taught how to program but how to conform to OOP principles. And that's hurting both developers and the OOP paradigm. OOP's a just a tool, often times is best to use that tool for designing your public API's yet to do this everywhere is nonsensical, why would I spend hours writing a complex interface hierarchy when it won't even be exported by the module? It may be more extendible for the future but then again I will rewrite it once when I (if I ever) need to actually extend, that is far more efficient than doing it the "OOP way" in the first place.
He is right and wrong at same time. It's like Uncle Bob says in Clear Code/Architecture, there is always a trade off and it all depends on development cycle. If you don't have any functionality and start creating very abstract, futuristic interfaces for things that are not created yet, you are really wasting your time. Specifications can change, your interface might not include every simple use case and we might decide not to use it after all. If we spend time thinking it through, sitting with graphs, designing architecture properly then it can become a solid building block but we will still have no functionality.
On other hand, if we start hacking some solutions, duck taping them with if statements, not writing solid test cases but testing manually just to see if it works for common use case and jump to another task. We will create a lot of stuff really fast but it will become harder and harder to manage or modify it. Architecture always have it's price and whether you pay it early or later is a choice but you always do. In my current project I started with hacking functionalities, cleaning up code afterwards. Getting feature done, then going back, refactoring and structuring it better. Adding another feature, cleaning up, refactoring etc. Now I have solid base for architecture that is easily manageable, intuitive and scalable and it paid off as I went back to functionalities I wrote month ago (completely forgetting file content etc, it's best test of time to see how fast and how well you can navigate in code you forgot about) and could easily find what I was looking for, expand, move on. Clean Architecture really is a good read. I recommend anyone struggling with high abstraction when it comes to class hierarchy.
If statements are not duct tape. They are proof that case handling is needed. Replacing them with an object hierarchy does only one thing: it moves them from runtime to compile time. That's a waste of effort IMHO. On a modern machine an if statement executes in sub-ns while its actual lasting consequence, an instruction or data cache miss blocks the CPU for a hundred times longer. The actually important thing that the programmer has to watch out for is data and code layout, so that the cache miss doesn't happen. The decision itself is a trivial amount of overhead. One of the problems with OOP is that it is preventing us from performing those optimizations since we are leaving the decision where to locate the code at the end of the decision to the compiler.
Beginner here does coding in c++ require using and understanding classes? I am very hesitant on learning and using it because of that, i want to think of c++ like c with more features. Is it possible to not bother with classes when coding?
You are asking the wrong question. You should rather ask the question "What is a class?". As long as the class is not polymorphic, it is the same, also cost-wise, as a struct in C. So yes, you can use C++ just as C, but with more convenience,features, and power of expression.
I’ve definitely heard this before.
And it was just as wrong back then as it is now. ;-)
@@lepidoptera9337why, explain
@@r2com641 Because he keeps rambling about what people believe/are taught to believe. That's not the problem, that's just the symptom. The real problem is this: most programmers simply don't know computer science. If they did, they would never have to resort to beliefs. They would know better. The other problem is that it's not even the individual programmer who makes these poor choices. In most companies they are being made for him by the architect and/or the team leader. It doesn't matter that a programmer knows the OOP is not the right style to attack a problem. He/she doesn't get a choice. That's an organizational problem.
unix was developed to play a space trade simulation, and the first app written for graphical output was a game, so no, it was never about only solving problems, it was always also artistic.
100% agree
Making a game you want to play is also solving a real problem, specifically, the problem of wanting to play a game nobody made yet
Which game? Whirlwind II and SAGE was an Air Force flight simulator is the earliest visual program I can think of
It was called Space Travel
You're missing his point completly, his point was make a program function first, whether that is a game or a untility or whatever. After the program is functional worry about how the code is structured. The way the code is structured does not change the output of the program, that is why he called it shuffling paper around. It's like changing variable names for readability might make the code better, but it has zero impact of the function of the program.
Sure it's "not solving the problem," but what OOP does help you with is organizing your code and making it easier to maintain in the future.
Yes if everyone understands the metaphors used and does not overextend them
Which is all very unlikely
If a dev eats, drinks, and sleeps OOP, I'd ask them why aren't they using OOP in their shell scripts?
(crickets)
Oh yeah. There are use cases where OOP isn't appropriate.
And if there's one use case, there's likely others (i.e. data retrieval, device drivers, operating systems, distributed compute, shaders, compilers, performant algorithms, or one time use programs.)
I had a library to read spreadsheets that was super slow and crashed often.
Turns out they were making a class instance for each cell. lol.
use the right tool for the problem. Sometimes oops is best. Sometimes it isn’t. Don’t be dogmatic about it.
Well if you use PowerShell you probably are using objects in your scripts 😂
Throughout my career dogmatic was the status quo. On one particularly annoying occasion I got lectured about using OOP practices when I updated a legacy C application that was running alongside a newer C++ application. My updates to the C app were in C style, and matched the coding style of the legacy code. I believe updates should never leave fingerprints. No one should be able to tell from the coding style anyone was fiddling with the code. There should be no visible seams.
My code reviewer wanted me to use C++ objects that would have required rewriting too much code for a simple update and would have left behind sasquatch sized footprints.
@@bullpup1337
I once worked with a system that processed large datasets. The data was logged as flat text files, then parsed and cooked, and loaded into a large parallelized RDBMS (Netezza). A coworker was seriously arguing that our flat files were a bad implementation. We should use XML instead. We're talking about 1 terabyte flat files exploded into XML files. Btw, this was almost 20 years ago, so they were big files back then.
We said "No, we will not do that."
I mention an XML example, because I think it's a kind of class and object representation of data.
@@Vitorruy1
That guy is basically that senior dev you meet at your job, who has 20 years of experience, spent his whole career on the same tech but never got offered the opportunity to be a tech lead or architect. And there is a huge reason why. "You end up taking on all these very large belief structures that are very hard to conform to." No, they are hard to conform to *for you*. That guy basically confessed that he absolutely can't work in a team and conform to a team thought pattern, which is why abstraction exists. So his way has to be the real way: "abstraction sucks". Which is also why this guy only released two games in something like fifteen years.
OOP doesn't support team development, either. It has the same problems when used by a team as when used by a single developer. ;-)
The guy wrote a compiler for his own programming language and his new game use his own game engine with his programming language, I mean, he doesn't work only for the money. Morover, you miss the point...
@@elturco9573 Reinventing the wheel is not as great an accomplishment in reality as it seems to be in your mind. We don't need more languages. We need more people who know how to use the ones we have efficiently.
@@elturco9573 which is all an absolute waste of time
@@elturco9573 So, to me this feels like he's not "solving a problem" (releasing a game), but rather shuffling papers around
I think is more of a critique on framework than OOP itself.
No he’s directly referring to the OOP paradigm pushed by C++ fan boys
no need for OOP to abstract or simplify, code is simple by nature
Where do you work?
“There are only two kinds of languages: the ones people complain about and the ones nobody uses.” - Bjarne Stroustrup, creator of C++
OOP in not a programing language btw
but oop isn't a programming language
This is bullshit and we should starts calling it bullshit.
I guess one can put up Alan Kays original definition of object oriented and say that C++'s is bad, but does that actually help? What Alan Kay had in mind is a lot like what we now call an agent system. Now, an agent system can sometimes be nice, with emphasis on 'sometimes'. Object orientation is useful in a much broader context. And one does not even have to have one of the famous object oriented languages. Even the linux kernel, written in C uses object orientation quite a lot. Johnathan Blow is very much correct that people have gone overboard in their usage of object orientation. It is absolutely not useful to fit all concepts in the world in some grand hierarchy of all possible stuff. Also, many objects don't need to inherit from anything and are quite well off as a standalone class. Also, some operations don't need to be methods. E.g., the sine function has no reason whatsoever to be a method, it can be a standalone function. But I also think that at least 50% of code lives quite happily inside objects. As soon as you have a bit of data and think that you would rather have people use it through a defined set of methods instead of directly being able to do anything with it, you have a case for an object. And even if you were to decide to make the data public, if there are functions that belong very strongly to the data one might as well make them methods. To summarize: there really is not all that much wrong with object orientation in C++....
Kay was very unclear about how he used words at times. Having said that, even he admitted that the design of Smalltalk was NOT a definition of OOP. Of course you can use the sine function in an OOP way... e.g. if you want it to have meaning for vectors and matrices as well (which mathematically it does). None of that is the problem with OOP. The problem is that OOP is basically program documentation (the compiler strips all of it) that forces inefficient memory layout and that leads to early (and usually wrong or at least uninformed) global design decisions that require refactoring to undo. The latter problem also happens when there are requirement changes. Now instead of just changing code to include new requirements we have to change memory layout and interfaces in addition.
@@schmetterling4477 You are right that memory layout in OOP is generally a bit less efficient. It is a price one pays for easier programming. I think your remark about changing code is wrong. When memory layout has to change, object orientation generally makes this quite a bit easier. Generally the memory layout is hidden in the private members of a class and if lucky one only has to change one class. If the memory layout is visible everywhere it may be that lots and lots of code needs to change. And if other things need to change as well, object oriented code lives at a somewhat higher level of abstraction usually meaning that change is more contained and less code needs to be changed. The thing I said earlier about paying a performance price for easier programming is true in this case as well.
@@chrisdams OOP isn't "easier programming", either. It's a lot of boilerplate. Everything that OOP can do, name spaces and runtime switches can do much, much better. Changes in memory layout require a complete refactoring in OOP languages. That is not "quite a bit easier". It's actually much harder. private/public has nothing to do with memory layout. That is all happening at the compiler level. What I am talking about is the actual position of data in the computer's memory, which is absolutely crucial to optimize cache strategies. Dynamic and interpreted languages do not even allow the programmer to access that level of control, which is absolutely deadly to performance.
I used to write business apps in BASIC, and am much happier doing them in C#. If you go around using inheritance as your only tool then of course it will be painful, but that's not how to use OOP.
C# almost pushes towards a more functional style now with mostly data classes. With services only serving the point of splitting up code into files.
@@gileeeyeah, C# is a great language for many reasons, like its multi-paradigm features
@@Decimation001 APIs in C# look almost like Node APIs at this point. It's great.
@@gileeewhat makes c# a great language? I hardly see it advertised as much as python does
I don't know what makes you so happy about C#. It's not the most terrible language in terms of productivity and maintainability, sure, but the common libraries are awful - especially the Web and ORM ones. It's not uncommon that you have configs in XAML and JSON, and then hide all the implementation details of the state machine through dependency injection and classes that are just function pointers but with vague names (like ContextOptions, ServiceProvider, Builder) and additional layers of complexity. The most managable C# codebases I've worked in have strayed far from the .NET conventions, and used T4 preprocessors and centralized the logic in SQL stored procedures and occasional extensions to generalized classes. But still depending on ephemeral web frameworks, because it pays to be trendy. I find it much better than Kotlin, PHP and JS, but it's so far from the ease and power from working in Jai-lang. And even though I'm not an old-timer who knows C very well, I still prefer verbose C to C# - because I never feel like I lose control over the hardware - and I desire more and more control, the more experience I get. I'm very surprised if you wouldn't, with your (I assume) long career.
Ok, lets just pass around 20 parameters to every function. It will do the job. Oh , you pass a struct pointer ? Well, thats an object.
There’s some oopish stuff going on with 1960s vector display computers but information is scarce
Sutherland?
@@jacobzimmerman3492 exactly
In my perspective, all these abstraction theories are kept into industry to involve more man power knowing the fact that there more dumb people than smart people because most of programmers are not even 1 percent of what programmers in 80s could do.
Yes, abstraction is what makes programming accessible to people with a lower IQ. But that goes into all levels. A 5 million line script doesn't fit into any programmer's head, even if they have an IQ of 180. You have to start extracting behaviors and be able to say "I do not want to worry about this right now". If you take it too far, every unit can be understood by a 5th grader, but the complexity of the system's organization (putting everything together again) is skyrocketing.
Let's be real, no matter how hard you try - a 5 million line codebase is doomed to be unmaintainable, no matter how many people you sit in front of it. This is why not only abstractions, but also microservices were invented. Microservices are the bane for performance and simplicity, and yet they let you limit codebases to something under, let's say, 100k lines to guarantee *someone* is able to understand it at all.
I'm tired of cowboy coders who come up with greenfield projects in their basement for 10 years, apparently never having working on a large project with multiple people of varying skill levels involved, ranting about how abstraction is bad. And specifically about OOP I gotta say, people who know what they are doing barely use state or inheritance anymore. It's just a nice framework for composing behaviors, similarly to how it is done in FP. Composing them via classes gives you a lot of expressiveness, so that's nice, but I wouldn't say it's mandatory.
Facts
@@holonaut That is not what destroys projects, though. It doesn't matter if you have fifty lines or 5 million lines of code... as long as the state space of the program is small and everybody understands at all times "what the program is doing right now". Heck, we can write a three line, single variable code that nobody, not even the best mathematicians understand! It's called the Collatz Conjecture. Look it up, it's a really fun case of "gotcha with minimal effort"! In practice a "useful" program that is not a brain teaser like Collatz can accommodate a state space of dozens to probably a hundred variables before it gets really hard to understand their dependencies. Beyond that both understanding and testing become very, very hard and are generally close to impossible. Large state spaces is where bugs live. That's what a smart programmer will avoid at all cost. That and concurrency. Concurrency is the next level of hell. Been there, done that.
You can structure your code however you want when working by yourself. People are taught a certain way because some sort of industry "standard" is required when working with other people. Most people will have to work in teams when entering the workforce
It would be a shitshow if everyone on a large project structured their code differently. Nobody wants to go through a bunch of unreadable, esoteric documentation while refactoring the absolute clusterfuck some guy created before leaving the company.
"Documentation? It's obvious what this 500 line ISR does." - The people who wrote the code I read daily
I’d just feed it to ChatGPT and copy paste whatever it says. If they expect me to be a robot then they’ll get a robot.
Because they clearly do not want free-thinking human beings. They just want someone who will follow the same patterns and principles that are standard in the industry, without seeing if they are appropriate for the actual software in front of their noses. That makes the jobs a lot easier for devs. Clock in, clock out. Get paid. No headache.
9 times out 10 the guy who created the clusterfuck is an OOP guy trying to follow some "standard".
I'm not saying OOP is the best or that it's the only way, but I find those who revile OOP to be far more dogmatic than what they accuse those who use OOP as being. He's conflating the part with the whole. OOP does not equal hierarchies of objects, per se. That's just one implementation you can do in OOP. That's not a belief structure that OOP paradigm makes mandatory to conform to. You can use OOP constructs even if your architectural approach emphasizes different design philosophies besides inheritance hierarchies.
Abstraction can be done without OOP. If you need encapsulation, then namespaces and structs are a far better choice. If you need polymorphism and inheritance, then run-time case statements are far more flexible. They only cost a few nanoseconds of runtime penalty on a modern machine, which in most cases is more than made up by the cache miss penalty that strict adherence to OOP carries.
Where is the original video?
How many people work on Jonathan Blow's projects? A benefit of OOP is a logical organization which benefits teams.
How many people work on Insomniac Games? They share his opinion, but go even more hardcore toward being aware of the footprint of every instruction. Also, larger teams aren't necessarily a good thing. You can have 30k employees and be outcompeted by a few people who really know solve data transformation problems in a way that the compilers and hardware understand them - there's many examples of this. The most recent one I'm excited about is "Disk Voyager" from Handmade Network. I think the knowledge gap is growing because it seems very few modern developers actually have a job that requires them to understand what's under the hood.
I like author’s comments, and I actually like to program myself in a such manner. But try to lead/manage a team of junior developers without predefined OOP style)) “Just do functionality first” will quickly become spaghetti hell
Spaghetti within a module doesn't matter much. For a team of developers one has to create separation of concerns anyway. Having one person do the IO, another the UI and a third the core functionality will not result in hell but it will very soon clear up the problems at the interfaces that even a good architect may not be able to predict correctly.
I agree with most of the point Jonathan is making here but I think he's missing the (arguably) useful part and that is if you work on a big team or multiple teams across a big codebase, that belief structure helps to guess what the other person was probably thinking - a lot of context is shared if we've all read the same bible, so to speak. Obviously it goes too far, and often fast, but I think it's that concept that wasn't addressed in this clip
Could there be a belief structure that actually helps to solve real problems?
Also, does OOP actually help people understand others code?
just because we're all worshiping at the same cargo-cult icons doesn't mean we're not worshiping cargo-cult icons.
If everyone is thinking the same way, it is likely that **nobody** in the organization is aware of the shared confusion.
Ok, great. You've engineered a social situation where everyone is getting along, and there's less friction. Because "shared context". But the program still sucks. Eventually the customer is going to notice.
In practice that simply doesn't work. My time working in a highly abstracted 'clean code' codebase was hell. Reading and understanding straightforward code is easy, compared to having to jump through multiple files, dozens of small functions and seven layers of abstraction just to find out how something works.
@@antongorov5275 I think so, but I will admit I've seen it done badly more often than not. It's better to say that a shared convention makes it easier for others to understand your code, and that OO is a convention. (And scaling a software team *is* a real problem)
@@Rakkoonn strong agree.
"clean code" is a fiction, because it models a reality that doesn't exist.
reality isn't clean, and obfuscating that reality does more harm than good.
I was called a luddite in the late 90s & early 2000s because I thought OOP was crap. I basically quit working tech because I was so frustrated with OOP. 20 years later it seems like it has gotten way more acceptable to criticize OOP thankfully.
Your problem wasn't that you were calling it out, but that you didn't know WHY it was crap. Do you know today or are you just expressing your frustration with the fact that you don't actually understand what the problems with it are?
I don't think it's more acceptable to criticize OOP. What gave you that impression? Perhaps you could convince me a little bit with the rise of Rust's popularity. But I see OOP paradigms everywhere I go. FAANG, smart devices, consumer software, IDEs etc. all by very much into OOP and seem to have no clue how much performance (and complexity reduction) they're giving up. I personally think it stems from there being such a massive demand for software, that developers don't _need_ to create great software. It just needs to be correct enough to profit.
@@Muskar2 Please take a look at just the performance problems that the OOP approach causes on machines that rely on cache memory to fill their CPU pipelines. That's pretty much every machine out there that goes past a 32 bit CPU running at 40MHz. OOP trades form for function and gives you a false sense of writing "good code". It is true, though, that lot of people don't know the first thing about computer science and they don't how their computers actually work and they think that hardcoding documentation into the program structure, which is pretty much the only thing that OOP does well, is the way to go.
@@lepidoptera9337 I'm well aware of the many problems with OOP, especially performance. But I don't think the vast majority of software developers are. That's why I'm asking you why you think so.
@@Muskar2 You said that it wasn't appropriate to criticize OOP. That's not true. Bad solutions can always be criticized, but the criticism has to be fact based rather than emotional.
This video was fun lol
Reposting this as I want to voice it directly: My take is that the dream of Smalltalk ultimately died. OOP as it was implemented failed to deliver on both of its biggest promises: encapsulation and scalability of software. Inheritance is a fundamentally flawed concept that breaks compositionality and reduces the ability to reason about code. Further, OOP is almost certainly the wrong way to express distribued algorithms, and as it happened computing moved to distributed systems (infinite streams, many cores, many machines).
This is why real world OOP systems in the 2020s largely consist of hundreds of lens-like static classes that feel just like the spaghetti code OOP was designed to address. To me, this explains why virtually zero new programming languages are designed within the OOP paradigm. It’s just a waste of effort and time and there are not very many compelling reasons to do it beyond maintaining legacy software. And there’s nothing wrong with maintaining what came before! But we’re talking paradigmatics here.
I argue that, however successful, these flawed implementations from decades ago have fallen out of favor for good reasons.
I'm studying high performance computing and many PDE solvers and distributed implementations are made with OOP paradigm. The fun thing is no one in my class understands what is the actual computation instead we have to simply parrot the code of the professor (which itself is a parroted copy)
What do you mean “lens-like?”
I understand everything else, you are describing the “Class Oriented Programming “ style I discuss in my free course on my channel
Which is not OOP at all
Lots of confusion here
@@ChrisAthanas by lens-like I mean simple getters and setters that don’t use inheritance or other forms of extension; they’re basically data classes. I agree that it doesn’t follow the tenents of OOP or any other paradigm, but this is what I have continued to see over a decade of working with developers who claim OOP as the primary methodology by which they build systems. IMO this helps my argument that it just isn’t a practical solution to real-world software complexity, and it never was.
Maintaining codebases with millions of LoC with rotating team members which take minimal onboarding while not drowing in technical depth is hard to comprehend for a procedually programming game dev who produceses throwaway software every 1-3 years with a lot of crunch-time at the end.
Thank you
Funny, cause I have been working on projects with rotating team members - not millions of LoC, but still subtantially big - and technical debt was pretty much present everywhere. OOP does not prevent any of that, it is just a set of rules, that we promise to follow, but since they are not straightforward and different people have different interpretations of them the end results can still be a mess. OOP might decrease the chance of that, but that is it really.
@@Salantor I worked on an amazing project that showed me that it is possible to maintain low tech debt and strict rules and it wasn't a startup, they were up for 6 years. Best part is that after a while clean code expectations become second nature and you just start thinking that way.
For real.
My first job was on a dispatching system used by several hundred users.
The codebase was upwards of 10 million LoC. All C++. The network layer was in C.
Parts of it were written in Java and sent data to the servers using an ancient object broker protocol.
We were still adding stuff to it.
In game dev most of the software gets reused, it's not thrown away.
I'm pretty sure the point of OOP is to get coders to conform to a teachable standard, so any one CompSci graduate can be fired and replaced with any other without affecting productivity
Not even that is the case. To be productive in an OOP framework requires quite a bit of experience. The real reason is this: all projects are late and have cost overruns. No manager wants to he fired because he didn't use OOP when all of his bosses (none of whom are computer literate) know that OOP guarantees on-time and on-budget delivery. ;-)
The problem solved by OOP or any paradigm is that it promotes a way of thinking that lends itself, more or less, to the solving of various types or problems. I'm a fan of OOP, and I find it to be a commonly useful way to think about my programs.
That only works if you are within a rather tightly restricted class of programs. In general OOP gets in the way. And even within your class you have to pray that the first architect gets it right and that the requirements don't change in a major way, otherwise you will be refactoring this weekend... and the next and the next.
Right on point. Programs are made to solve very specific problems. When you wish to solve multiple problems, you have to rethink your approach.
Hasn't anyone ever wondered what the purpose of a long switch statement is? For example, you're passing in an input and the switch statement decides the output. It would have been a totally different world if instead your program knew what the input already was and passed it to the appropriate place to generate the output you need, and it would also be a totally different world if the program directly generated the output when the input was conceived instead of filtering a raw input to a switch statement or a function pointer to that type of input. You can solve the same problem in a myriad of ways in programming but each one of them carries it's own side effects or set of problems that also require solving.
Yet the OOP hater use structs and functions and function pointers in structs and init_ and destroy_ and it's the same thing.
It's not the same, the entire program structure isn't designed around the taxonomy of those objects.
@@sudsy3 Nothing says that C++ has to do that either.
It's simply better to have the class construct in the language and use it sanely.
nah dude c++ classes are terrible
@@sudsy3 there is like 0 difference between a class and a stuct with function pointers.. an nit unusual thing to see in larger c code bases.
@@marcbotnope1728 You're crazy if you think structs with function pointers are the same as object-oriented taxonomy-based programming.
Programming is one thing; developing another. Hierarchies have an ordering of topology and toponomy, but at this level many more categorization gained relevance. So yeah, the pointer is as relevant as concept as it was on it's invention. Most languages implemented this feature, and you can make use of it in programmatical and functional ways.
OOP meant Smalltalk, that's correct. But with minor work arounds you can pretty much follow any paradigm you want in C++, including proper OOP, as giant class hierarchies are often not a good way to achieve oop anyway. So the benefit of already established languages such as C++ outweighs the cost of creating a new one by far.
OOP existed long before Smalltalk and even Kay said explicitly that the design of Smalltalk does NOT define OOP. Most people aren't even getting the computer science history right on this one.
@@schmetterling4477Going further back than Smalltalk doesn't matter anymore, as Smalltalk pretty much has shown the essence of OOP to others.
@@SnakeEngine Sounds cool but it doesn't.
just make another game, that last one was pretty good 👍
boom! mic drop...
So Object oriented is to programming what string theory is to physics.
That's a good analogy. It's a seemingly good idea in theory, a lot of people sign up for it, but we don't actually know and it might have put us in a bind. But hey, writing code in any way works at the end of the day.
I think at this point we do know that it's bad in both cases
This take is basically wrong - most (knowledgeable) OO programmers don't start with hierarchies - you may indeed end up with some hierarchies in a large collection of types/classes, but most of the classes/types are related through the messages they pass.
I.e. Prefer composition over inheritence.
Classes don't pass messages. They call member functions. The only reason to pass messages is if you are building concurrent systems, in which case... god be with you. You will need his protection. :-)
@@lepidoptera9337 yes, but no. Search oo principals and message passing.
Jonathan’s takes are always very good. I just wish he wasn’t an abusive narcissist.
@@perprerp It's perfectly acceptable to call out some who I've seen attack others and has personally attacked me.
Oh, and of course he did it on a "public forum".
Why don't you worry about your own virtue, because you clearly lack any whatsoever.
@@perprerp Of course negative reinforcement helps people. If your parents had simply hit you as a child every time you threw a tantrum like this, you wouldn't be such an insufferable hypocrite.
I have work to do, but will definitely put you in your place later on.
Which video is the clip from?
Abstracting for the sake of abstracting is bad, but OOP is really not the problem there. You find similar problems in all paradigms if you decide to make a bunch of abstractions.
At the end of the day someone has to come up with a structure. I don’t give a fuck what paradigm is used and how classes are designed.
However it is I’ll adapt because I know that no matter what, the code will have to be run, tested, debugged, fixed and made to work. No amount of design is going to magically make software run as intended. The implementation of functionalities is what truly matters.
OOP is overabstraction. You have to make a class for everything and they have to be completely encapsulated which requires rigid hierarchies.
The reason you think OOP is not the issue is because you are not doing OOP.
@@Vitorruy1 Sounds like you confuse OOP with the hell that is Clean Code. That shit is awful and mostly unnecessary.
As for what you mention about having a class for everything, that's not really the case. Having one class per data structure is nice, but you can just make everything public and readonly if it's not going to change, minimizing boilerplate. That's useful just to know what is expected to exist. You can just use maps for everything and go crazy with unknown data structures and types, but that sucks and is why we don't do that in OOP.
The hierarchies you mention exist in other systems as well. Come back once you've worked in a large team with something other than OOP. You'll have pretty much the same complaints.
@@ifstatementifstatement2704 The structure you mention will exist regardless of paradigm. It just looks different with different paradigms. If your architect is awful, then the structure will be awful to work with.
OOP naturally pushes towards abstraction. That's why all OOP code is abstracted to no end.
OOP should be a design pattern instead of a mandatory way to solve things.
Even then it's a really poor design pattern because data flow and control flow are never even related, not even a little.
That's literally how you learn about it in SICP using Scheme. You make objects using functional constructs. It's pretty cool and made me think about OOP in a different way.
(As for OOP itself: I think it's a very sophisticated tool that sometimes have it's uses, but you better be damn sure you truly need it before you actually use it because it has a significant cost in complexity. And as for inheritance part of OOP: *everyone* thinks that's bad these days anyway, Java guys have been sceptical of it for decades due to seeing how bad it can get.)
@@torb-no If you take inheritance out then OOP is really just a glorified use of structs. Your compiler doesn't care. It compiles everything into pointers (relative addresses) anyway. Your CPU doesn't speak struct and class. :-)
@@lepidoptera9337 "Glorified use od structs" is doing *a lot* of heavy lifting here. By your compiler logic, there is no such thing as functional programming as it's compiled down to programs that fundamentally mutate state (CPU registers, memory, etc). That's kinda silly, in both cases we have abstractions that exist mainly for the benefit of humans. And those abtractions can absolutely be valuable, otherwise we would all be programmig in assembly (which even itself is an abstraction, tho a fairly thin one).
Regardless: OOP is way more than inheritance, but I can understand people failing to get the value of OOP if all you see it is in terms of these horrible inheritance structures. Computer science schools have definetely failed in this regard.
The big problem with all of programming is how to deal with state. That is where so many of our bugs and problems lie. Proceural programming have traditionally stored a lot of state globally, and for small programs that can be fine, but it often becomes a mess. With OOP we solve this problem by storing state in objects which themselves know how to properely deal with this data and only give outside access to certain parts, thereby reducing the surface area of bugs. In a sense you can call this a struct combined with functions with specific access patterns. Hell, with extension functions in languages like Kotlin you literally can use OOP method syntax for what are static functions on objects. If you don't need polymorphism (and you often don't) that can be a reasonable way to program.
Of course, functional programming takes it one step further and just tries to do away with state altogether, which is certainly what a lot of us strive for these days.
Premature abstraction has nothing to do with OOP. It's a bad practice no matter which paradigm you are using.
Yes in schools they teach you to think about a hierarchy first, but I'm fairly sure teachers would screw that up equally for any other paradigm. You can build hierarchies in procedural and functional programming too.
Using TDD I come up with a solution as simple as it gets, and once it runs reliably I start refactoring to a degree that is obvious to me. But I don't go overboard with it. After time passes and I see duplicated code, I may extract some things into a shared unit. I never do it the other way around.
The problem is that OOP is the religion of "architect fast, fail fast, refactor always". It's the great-grand-daddy of bad software practices. Duplicated code is, by the way, of absolutely no concern in a world that has computers with 16+GByte of memory. The few kBytes that your code duplication wastes may trigger your OCD, but they won't make any difference to your memory efficiency.
@@lepidoptera9337 nobody claims code duplication is bad because it takes more memory lmao
@@holonaut Just saying. Inheritance was invented to avoid code duplication when machines had 4-16kBytes of main memory. That reason was soon forgotten and then it became the religion of a failed solution that kept looking for a problem. By the time a failed biologist named Kay starts preaching it the original reasoning behind OOP had long been forgotten. OOP is really a case that should be sent for final analysis to the "history of religions" department. ;-)
@@lepidoptera9337 I don't like inheritance either and avoid it like the plague. There is nothing wrong with reusing a part of functionality via composition. Which is something you can do in any paradigm, but OOP and FP lend themselves to it pretty well.
Also isn't Alan Kay like the most quoted opponent of inheritance?
“OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.”
~ Alan Kay
And I've never heard the idea of OOP was to reduce memory consumption. That is an absurd statement when you can just use functions instead. OOP was a response to shared global mutable state, to which procedural programming was so vulnerable.
Programming paradigms are almost always about taking away power from the programmer. To reduce the ways in which they can shoot themselves in the foot
@@holonaut I agree about inheritance. It's very problematic and not an obvious solution to any serious problem.
I don't know why people think that Kay thought that OOP was messaging. There is a quote of his that relates messaging to the implementation of Smalltalk rather than OOP principles in general. In your quote the kicker is "..to me...". He is uttering an opinion there, at most. I wouldn't use that as a "definition" for anything.
OTOH messaging is one of the most evil and wasteful techniques in CS. It is necessary for concurrent systems... and that is the only place in the universe where it is necessary. Online apps are wasting GBytes of code on trivial problems that can be solved without a network in 8k of assembly language... because they need to pass messages over an insecure and unreliable network instead of just doing what needs to be done with a trivial function call (like modifying a string in a data base with setSurname(personPointer, "Smith")).
"OOP was a response to shared global mutable state, to which procedural programming was so vulnerable."
All state is global. If it isn't global, then it's not state but just a local scratch variable. All state is also mutable... so the user can modify it. What else would it be good for if nobody can modify it? Immutable state is called "a book". We store it in libraries and even then it's not completely immutable... but we have to print a new edition to make changes. ;-)
The problem of rational programming IS NOT to be afraid of state. The problem is to keep state minimal and to restrict it to allowed states at all times. There are different techniques to achieve that goal (like state machines!) but procedural/functional programming paradigm wars are NOT a solution to that problem.
Hmmmmm.
And how my team should understand 10M+ linese of code without OOP? How somebody should find a place where things broke and so on?
OOP helps for people to understand what its mean in term of problem we are solving, give us simple and easy to use abstraction layer.
Without OOP we should do same things, but with unnecessary complexity.
For example - we are reading data from bunch of devices. Devices can be different, protocols and interfaces can be different, device can return same data in different format. How we are should take it all together without OOP? We should build ugly framework around and teach every new programmer how to work with it monster, and be a very carefully for any changes and adding new feature, because if some of programmer pass wrong void* - all our program just crash at runtime and for finding this bug we should build another ugly monster with bunch of abstractions and so on and so on.
With OOP in C++/Java/C# style - all this stuff is checked by compiler and we are just solving problem around business and not building our own framework like its done in Linux/GTK and other complex C language project.
Sorry for my bad english
How does OOP help them understand 10M LOC? It's impossible to understand 10M LOC - especially if atomized with dozens of layers of black boxes. There's a difference between "understanding" and "correct enough to profit". And I think one of the best tests are: do you have any idea what the theoretical maximum performance your application(s) could run, if it/they utilized the hardware's capabilities. It should be very easy to reason about, even for very large codebases.
@@Muskar2
OOP forces you to break your code into modules and layers. After that, you can add tests and make sure your code does what it should.
Have you worked with any large C code base? Global variables for switching application states. Access to any part of the application to any other (IT IS EASIER than doing it right, every programmer after dive into project start doing that, cause - why not). A simple representation of the data that doesn't let you know what you're looking at without traverse all calls of the function (maybe for big brain programmers are obviously, but for me `OP_RESULT HANDLE_TASKS(BYTE *devices, UINT32 devices_count, INT32 *tasks, UINT32 tasks_count)` - magic until i figure out why device is just a BYTE, why task is INT32).
I worked with embedded C code in the early 2000s. And it was terrible. Because every new project, even similar ones, must be started from the very beginning. Write another task scheduler, write a bunch of code to read data from sensors, write another file datastore, write a bunch of code to send telemetry to servers, write memory diagnostic tools; write your own loggers, tools for working with peripherals, another level of data security required by government organizations; for the millionth time solving problems with time, time zones, representation of text for different regions.
And the transition from C to C++ made it possible to force developers to at least break it all into modules and add an abstraction layer over the hardware. Allowed us not to throw away the work of previous projects each time, but to reuse the code. And to build a full-fledged modular platform for almost any device.
And about application performance. The C code was not significantly more performant than the C++ code. But there was an opportunity to support, develop and distribute work between teams.
@@stanislavsh6582 I agree that global variables aren't suitable for production code. I have only been exposed to 100k codebases in C (about a third of it generated through metaprogramming), with very small teams, but I can see how things can become a mess in larger teams if there isn't proper culture-screening.
Apart from having to write everything from scratch in new companies, I would also say that C isn't very good at making it clear what good code looks like. If the standard library that was written by developers with 30+ years of experience of building great applications and APIs, then it'd be a very different story. That's one of the reasons I'm looking forward to JAI-lang becoming public.
Another reason is that C has outdated concepts in it and lacks a lot of modern features. Like length-prefixed strings, modern arrays (fixed, views and resizable), static polymorphism, much better metaprogramming, basic memory management structs (pools, ring buffers, scratch pads) etc.
C's strength is that it can do everything the hardware can do, and is very close to how the hardware and compiler reasons - so you have great power and control. You don't have many guard rails though, and the standard conventions aren't great.
I strongly disagree that code reuse is inherently a good thing. I fell into that trap for the first decade of my career. Code should fit the problem it solves, and code reuse is a tool that should be considered carefully. You can reuse a great API, but then it needs to provide granularity that goes from automation and powerful singular statements, and all the way to controlling every tiny thing you need to.
If you instead reuse something where the generalization makes compromises that gets rid of vital context in order to be reusable, handling scenarios that are never realistic - to guard against hypothetical future problems - and start creating a dependency graph of such generalized modules, then you're headed toward bloated software that end up like Windows 11 that has volume mixers from several previous versions and the latest ones are extremely sluggish to use while the oldest ones are fairly snappy.
I do agree that C isn't likely to be a great language to have large teams in, unless you have a great culture that has fairly tight rules. But that's not a problem with procedural code in general - it's a problem with legacy languages. I think the problem is that procedural languages haven't been evolved very much - before Odin-lang, Jai-lang and Rust.
So I should always just start hacking away haphazardly for any new project paying no mind to the overall architectural structure of the code base, because that would be solving a problem that is irrelevant to whatever problem the project is meant to solve.
And only when the project is "functional" and the code base amassed a shitton of technical debt should I go back and consider restructuring things to be more readable and maintainable. Sounds reasonable.
Look I watch JB for the steaming hot takes like anyone else but this is just pissing me off because he will curse modern software for being dysfunctional in various ways due to poor programming habits, and then in the same breath talk down design patterns that we came up with to combat buggy software. I'm not even a supporter of OOP i just hate how contradictory this take is.
Well said guy.
Classes and OOP got nothing to do with technical debt.
I assume you are being sarcastic that this is reasonable, so I'll disagree. If you know the problem domain well, sure you can architect in advance. If you do not, then doing so is just making your program harder to change. When you don't understand the domain clearly, I think it is in fact better to first solve the problem, and then step back and see what kind of mess you've made and make a decision about where to go from there. Sometimes you can simply rewrite it now that you have experience and a bunch of nice abstractions will jump out at you.
OOP is too vague a term to argue about. It means different things to different people, and different things to different programming languages and problem domains.
You've got it exactly the wrong way around: If you just assume OOP by default, you can't pay mind to the overall architectural structure of the code base.
Dynamic dispatch is so rarely the best way to do polymorphism it's absurd that OOP, as the term is generally used today, got as ubiquitous as it did.
If your code is written reasonably well, it is easy to extract parts of it into new classes and functions, if/when you need to do so (when it solves a real problem in your code, such as code repetition for example). If you preemptively create classes and interfaces for literally everything OOP-style, you may just be adding extra work and complexity for no reason.
Maybe you know exactly what you need and that happens to be lots of OOP-style classes, but currently the average programmer who thinks OOP is a good way to design code tends to overdo it by a lot, to their own detriment.
If abstraction and object orientation is so bad why don't you write in assembly.
This is the problem with software engineering rockstars, they don't get the idea, misuse it, then smear it with bunch of nonsense.
That's a really good point to make. I am beside myself that so many developers denounce abstraction. You want me to go out there and rub some sticks together until something shows up on the screen? I'll whip up an abstraction, no problem. Wait... You want me to do that every time?
Why in the hell would you want to solve similar problems over and over again in potentially different ways just because you might not account for something? Even if you failed in that respect, you still have the option of making a change or worst case, solving it for that edge case. It makes no sense to me.
Also, if people stopped avoiding it like the plague they might actually get better at it.
That's a strawman, but I'll assume that you're still actually asking. Abstractions aren't inherently bad. But they also have a cost. And a common problem with abstractions is when they get in the way of understanding the problem, rather than making it easier. A common misuse of abstractions is thinking that when you make an interface boundary, you can now treat it as a black box. But doing so will only make it harder to reason about - especially when the black boxes multiply to several levels. It's never a good sign when looking into the abstraction is overwhelming to understand. Not to mention, much of OOP's bad parts are about inheritance, v-tables and atomizing everything that doesn't need to be.
@@Muskar2 "a common problem with abstractions is when they get in the way of understanding the problem"
I don't know how meaningful that is, because doing it badly doesn't say much about its value. I'd agree with the use of inheritance as a problem, but that's because inheritance is a stack of black boxes obscuring contracts.
I think abuse and poor design is the big problem, not oop itself. Good oop is good. Bad oop is bad. There is a pretty big gap to cross between the two without a lot of resources that actually help build the intuition for it, along with a lot of bad resources.
@@TruthAndLoyalty To me, "good OOP is good, bad OOP is bad" is a common truism that doesn't add anything. No tool or strategy should be used where it isn't appropriate - that goes without saying.
Procedural code also has objects. OOP doesn't have a clear definition. So you might as well be saying that good OOP is the same things you'd do in a strongly typed, procedural language with compile-time polymorphism.
In my experience, OOP usually means inheritance, garbage-collected (performance careless), constructors & destructors, mapping programs after mental models, and focus on data as masses of individual encapsulated elements, in stark contrast to batches of data transformations designed to solve specific problems.
And at the very minimum OOP means methods (functions attached to objects) and encapsulation.
What is good OOP to you?
@@Muskar2 Do You need to understand what is happening in the gearbox to drive a car? Understanding gear shifts is enough, also universal gearbox interface allows cars to be produced with both manual and automatic configurations while having minimal impact on the rests of the components (like engine type for example). Am i wrong?
Also data orientation does not invalidate object orientation. Both of those are tools you need to learn to understand when to use appropriate one.
All Java devs
ALL
Abstract Factory Factory anyone?
Why do programmers get so irrational when the topic of OOP is brought up?
Because most programmers either never took a CS class or they forgot all about it.
I like OOP and it can be quite good. But if misused, it becomes really nasty.
Using classes is not OOP. If you follow the OOP guidelines by the letter your code is guaranteed to get worse.
Same is true for any other pure paradigm in nontrivial environment.
associating behavior with classes was the brilliant improvement that OOP brought to the programming world. All of the other stuff: polymorphism, class inheritance, GC... that's the stuff that broke things.
That's nothing more than program documentation, though.
@@schmetterling4477 I'd call it more organization but, yeah, that's why it didn't break anything. If you want to write reliable code, you need to write as closely to the hardware's understanding of logic, rather than expecting the hardware to think abstractly like you.
@@venalleader2909 Exactly. What the OOP/FP/"chose your favorite programming paradigm here" spat does is to avoid the real issues in professional programming (like memory organization, state management etc..).
I still think this is a graphics centric view. In audio it's so common to have many things relating to control rate signals and many to audio rate, it's not an impediment to use a class interface for those two. It's you limit it to that level it's not practically different to using flags or function pointers . I get the world modelling objection, but there are areas where the objection is just emotional.
Object-oriented is amazing an it makes our lives easier by providing names and namespaces. Let's not confuse bad design with bad paradigm. Using pointers for ifs, really?
That's one possible implementation of inheritance. Your compiler may or may not use it. There is nothing wrong with that, by the way. Pointers are a necessary evil because it makes a difference in effort if you point to the mountain or if you move the mountain. Even on a fast CPU. He was correct that everything that one can do with OOP can be done in the runtime with if-then-else and case statements. Namespaces can be done with structs. Most of what OOP does is syntactic sugar and one can live without all of it.
@@lepidoptera9337 Every language is mostly about syntactic sugar, isn't it? You can live without OOP and also without structs and case statements. Just use MOV and registers, one can live without that nonsense. Not sure how long though
@@sergeibatiuk3468 That's an important insight. All our CPUs understand are arithmetic, logic and program flow instructions (branches and subroutine calls). They have different addressing modes for data that we abstract into pointers and references. Everybody should keep in mind that no matter what they are writing, it ends up as a stream of those instructions. I had a chance to be TA on an introductory computer science course when I was a student. We actually taught our students to analyze their compiler's assembly output. It's amazing how much one can learn about compilers, languages and CPUs by looking at that. It does, after all, entail the condensed expertise of the compiler designer's knowledge about the architecture and the language.
I have done some symbolic assembly programming in the deep past (without knowing much about assembly, at all) and it was far easier than I imagined. People have this horror of low level programming that is unsupported by evidence. As long as the assembler and linker are doing the address calculations and symbolic names are available for memory locations and jumps, it's almost as easy as C IMHO. The main downside is that optimizing compilers can do a far better job than humans can with regards to optimization, so the techniques is obsolete for that reason alone.
What gets me all the time (maybe my brain is not good at left/right) is endianness and byte-alignment. That's something high level languages don't do well, either. Many are even ignoring the problem by not giving access to memory layout (which is bad for many problems).
You are referring to procedural style sir
@@sergeibatiuk3468 Pointers are not. They are fundamental to achieve reasonable performance. I can live without OOP forever. I can't live without pointers (whether they are explicit or implicit) for even ten minutes. I would suggest you learn some introductory computer science.
The concerns you are addressing aren't related to Object-Oriented Design but to Waterfally-like organizations that ask to think & plan ahead. It is absolutely not tied to Object-Oriented Design whatsoever. It just happened that OOP has been so prevalent that design phase often incurs up-front design.
The same problem can happen for a Structured Program or a Functional Program, it's just not that common to use these paradigms.
And that's why Agile in the first place. If you listen to the proponent of Agile such as Kent Beck or Robert Martin, they're also fond of Object-Oriented Design and are perfectly able to fit OOD into Agile. The idea isn't to waste time on papers and design documents and al. The idea is to sketch a working program (first, make it work) and THEN make it a robust solution (then make it right) if required / if reasonable.
That is a perfectly fine way to do OOD and once again is unrelated to what you say is "the problem" with OO but rather the problem with IT management.
Object oriented programming doesnt mean "pre planning" or this "uml modeling" thing that people do. You'll never "pre plan" code thats any good, I'm not smart enough, you're not smart enough. You absolutely should just start writing code, ideally through TDD in my opinion, and this would conform to his idea here that you need to begin immediately solving problems. TDD just helps with ensuring you're solving tiny problems.
This is a dumb take. Yes, when planning software in OOP you are doing some prework before actually coding, but isn't that, the "paperwork" planning phase, also the case for any other large software project, even with a non-OOP paradigm? Or is he suggesting that teams should just start writing code immediately, without having worked out a coordinated plan and software structure in mind to make everything fit together?
And no, you don't HAVE to adherre strictly to OOP principles, you can write object-oriented code without, for example, writing getters and settterrs for everything. "So even the term object oriented is wrong, it means smalltalk, not C++" Who claims that OOP is a synonyme for C++? OOP is a way to program, it is not tied to any programming language.
The problem with OOP is not that you are asked to do architecture but that OOP makes false assumptions about the structure of your problem (because they are independent of your actual problem). In the real world methods and the data they are acting on are usually not neatly grouped. Dependencies form graphs, not trees. Dependencies also tend to be fluent during the development process. OOP suggests that freezing them very early is a good idea. In reality that's a horrible idea that will lead to endless refactoring.
The creator of C++ called it OOP because of marketing and he didn’t want his language to die
Guess who I’m talking about?
Dear young developers watching this video, please do not listen to this incredibly shallow and silly take from JBlow. Certain problems with will DEFINITELY benefit from OOP abstractions and/or well-chosen design patterns, you can't replace them by just "throwing in a function pointer", as our big brained presenter suggested. There is a reason why OOP became so popular as features and software complexity increased exponentially. Sure you can write functions for everything, but this is a dumb self-limiting, dogmatic approach that will not grant you anything but headaches. Many junior/young devs fall into this kind of dogmatic thinking, that they should never do this, or always do that, etc. Don't think like that, problems are unique, and having all of the tools at your disposal, and understanding them WELL will be your biggest asset.
How is your take any more nuanced or instructive than what Blow is saying? Dogmatically believing that any one toolset is "the correct way" is wrong. That's part of what Blow is saying. And that you shouldn't try to fit a generalized abstraction to real-world problems. Solve the problem at hand. Discover the patterns that you need. Invent patterns. Whatever. But don't start with religious adherence to The Pattern. I don't understand why this is controversial.
@@justinj4394He says "people USED to solve problems in the 80s etc etc" and that we don't solve problems anymore with things like OOP and design patterns, but rather we create problems. Adding those abstractions and patterns for him is just, nothing, it doesn't solve anything. He says "if you go to program in C++ object oriented, you create a hierarchy of objects", which he calls "the framework you've decided on" which doesn't solve any problems". Just referring to OOP as just "a hierarchy of objects" is a gross oversimplification, which he only uses to justify his hard-headed stance. He fails to realize that laying down a thought out framework for your program, whether its founded in OOP or something else, is exactly how most software needs to be written on the vast majority of real projects (not just gamedev). I can't tell you how many times I've had to refactor or clean up after other programmers who were like "just get it to do the thing you want, write a function here and there, solve the problem, see it working". Well, in the real world, you don't get paid to go back and completely refactor your sloppy unmaintainable code, especially if it is in production. You have to make decisions and commit to them, then hope you've made the right ones as your scope and requirements change. I have 20 years of experience as a senior dev / systems architect, in the real world you mostly cripple your timelines, deliverables and create nonsense work with that line of thinking. OOP and design patterns are for solving higher-level problems, not just deciding whether you're gonna use a few classes and virtual methods when implementing your noise generating algorithm. He doesn't draw a clear line between high level architectural design decisions and solving isolated technical problems. This is because he has made a career of staying in the weeds, he knows the nitty gritty quite well, but probably would not do very well working at large bank or another institution where a large number of massive systems need to operate in an orchestrated way.
I agree. I don’t think Blow has ever worked in a large team setting making truly complex software. There is no one magical best paradigm or framework, but if you have a hundred devs working on some giant architecture and you are just winging it “solving real problems” you’re going to end up with a disastrously broken and un maintainable code base
Games like Witness certainly qualify as "truly complex software." Your comment about a project with "a hundred devs" is too big a topic to discuss in TH-cam comments. But it suffices to say that most features in most companies don't have a hundred devs. And when they do, sometimes it's because they've overcomplicated the design with their chosen paradigm. I'm obviously not suggesting that OOP is "wrong." I'm just saying that there aren't any easy answers, either. @@jtms1200
You don't think Jon ever worked on truly complex software? How do you get more complex than video games? Did you ever consider how many complex systems they need? He writes his own engines btw.
edit: Also, he is currently working on his own language.
As always he takes some good idea like "too much abstraction is bad" and runs with it till it becomes ridicilous. OOP is good. It's a very convinient, easy and efficient way to structure your programms. It's a GOOOD layer of abstraction. Of course, you need to understand what you are doing, and don't just blindly use OOP everywhere - do not replace all your "switch" statements with virtual functions - that would be really bad - if you know in advance all your cases, put it into a switch statment. But in many other cases - yes, using virtual functions instead of switch would be good.
Thats the point
A switch statement will cost you 3ns on a modern CPU. Replacing it with a class will cost you weeks of restructuring if you get your classes wrong. It's a no-brainer: switch statements all the way. :-)
It's like the books of religions VS real life... Welcome to the atheistic side of programming! 😅💻
Keep in mind that religions were created to keep people in line, so the atheistic side of programming should be used with caution, ensuring you know what you're doing! ⚠
I completely disagree. The reason why things like OOP were invented was not because people had too much compute power, it was because they had to solve bigger and more complex problems. Things like oop are abstractions that help you handle larger and more complex software problems. I think your whole reasoning is based on false presumptions.
You would be incorrect about that, as well. OOP was invented at a time when machines had very small memory and an optimization was needed that would allow the compiler to reuse code. It was meant as a memory compression technique. It solves a tiny problem (poorly) but does not address how to build large systems, at all. You can clearly see this in the number of failures of OOP projects.
He talks thrash about C++ and don't know that C++ is not a OOPL, Bjarne has a ton of talks where he emphasize that C++ is a multi paradigm programming language... No to mention the fact that most of the code of this guy is written in C++ in NON OOP manner, so how is C++ a OOPL? OMG...
OOP solves a problem, by using a paradigm which makes it easy to share functional blocks of code amongst many people.
I was prepared to hear some intelligent counterarguments, but I found none here.
That is not the problem OOP was trying to solve in the beginning because that problem can be solved much better with libraries. The original goal of OOP was design reuse to lower memory demand for code. It does that really, really poorly while causing all kinds of performance problems and architectural nightmares.
Blow has been working on a simple Sokoban game for like a decade now... Don't take him too seriously
Technically, the Sokoban game is more or less a tech demo for a programming language that he is still making.
10 years for a programming language is a bit much.
C was released in '72 and K&R C was released 6 years later.
I don't really follow him, so it might come down to selection bias or sathever, but I feel like lately his takes have been becoming almost a parody of his previous takes
along with a new programming language and compiler plus the braid remake right?
@@jc_dogen right, right. making your own language and compiler is the most sensible thing to do when you want to develop a Sokoban clone. because c++ is terrible, c is terrible, rust is terrible, oop is terrible, game engines are terrible... Jai is an interesting language, but we all know it won't replace any other language in any meaningful way. It's closed source, with zero adoption, no community, first announced in like 2011...
@@user-sl6gn1ss8p Yeah, and it's the same with Muratori. It's always fun to hear these procedurally programming solo indies who never worked in a large team spout wannabe hot takes such as "why do we need polymorphism when we have switch statements?" or something along the lines.
Uh my dude has a weird way of phrasing... "object oriented is a belief system' is words I've never heard before. Sort of like building a chair with joinery is a belief system.
What? This argument is too abstracted. OOP solved the problem in my gamedev of being able to define functionality for an entity within that entity. Not using OOP would mean some kind of manager abstraction that checks their state and run the programs on entities. The code would be less structured and easily maintainable and readable if there was some monolith state checker deciding what happens to each entity on tick.
OOP Solves a very clear organisational problem where code can be shared clearly and easily between entities. Clearest and most obvious example is enemies and player characters sharing movement code which is in the object they both extend. How is that shuffling papers around and not solving problems? For sure OOP doesn't solve anything on its own, it's a paradigm, a structure, not code. But using it isn't a problem in and of itself.
There is an argument that being so strict about following OOP principles and not using any other way to solve problems (if they exist.) That's a problem, but that's not a problem with OOP itself, it's a problem with people using it as they are. (I think this is what was trying to be said without being offensive?)
Yes, graphics libraries are the best example for OOP. They are also almost the only example that truly works. In almost any other domain OOP quickly becomes a hassle for hassle's sake.
Guy, you are talking about something here you haven't really understood yet. Object oriented programming is not a dogma, but an opportunity. Not everything in programming can be solved using object orientation, but a reasonable portion of it can. Object oriented programming does not mean class hierarchies by law. Using classes gives structure. Ok, one can say that using a singleton pattern (creating just one instance of a class) can also be solved in different ways, what is completely true, but there is nothing wrong with using classes. Open your mind, and no, you don't act open minded. That also applies for your statement on taking the wrong path as developer when doing web development, what you did in another viedo. I'm 58 years old and chief architect eBusiness in a big German company and I was showing this video to my daugther, who is also doing software development. Her statement was just: Narrow minded bullshit. I do not argue that harsh , but you should really think twice about your position on modern software development, cursing keys principles without understanding the context.
I agree with you. It is not that OOP is the default. It's that problems are solved by breaking them down into smaller pieces, and it is common for those pieces to be able to be structured and manage themselves in classes.
@@alf5197 you can break down problems in pieces using functions only.
What matters is how organised you are. And when in a team, they would need to understand that structure. If teams can adapt to using classes spread across multiple files, they can certainly adapt to using functions in the same file.
@@ifstatementifstatement2704 Sure, let me limit my toolbox to only using standalone functions and then have to manually take/free resources. Oh wait, that's a really lame idea, because it doesn't solve the problem of automatic resource releasing.
I am a 124 year old CEO of japanese medtech corporation. And i have shown this comment to my grandchildren. All, 46 of them in unison said " merde", which means shit in french. I wouldnt be so harsh, but OOP people are too cultist about their absolute solid beliefs.
using classes != OOP.
OOP is 100% a dogma. The "oriented" part of it means classes are the smallest unit of the program. This hybrid and flexible approach you propose is not OOP but something else.
OOP is not Smalltalk. Smalltalk is a programming language. OOP is a programming paradigm. The biggest problem with OOP is the Object-Relational Impediment Mismatch, and that issues is not directly an OOP problem but more of a divergence between the way we model real world objects and the way we store information about them.
Complete nonsense. Most of these Paradigms and "belief structures" were invented way before the 80s. Think about Lisp. Also code from the 80s was horrible. If that stuff worked we would still be coding the same way today.
Facebook did what you said and they learned that the hard way.
I think he's right to imply there is a lot of wastage nowadays, but also I think he's too used to working by himself and with the tiny number of people who can work with him. In places where there are hundreds or even thousands of engineers, rightly or wrongly, they're working in domains of complexity beyond what one person or a small team can manage cognitively. He's very derisive of web development for some reasonably good reasons but also misses that web programmers have to be more aware of certain scaling, security and performance issues than with other styles of programming when you own the whole machine. I do like a good Jonathan Blow rant but there's a bit of baby and bathwater, too
Yeah, Dijkstra was broadly thinking about things like this in the 60s at least, even if these specific paradigms weren’t realized or realizable yet. Even more broadly, mathematicians cared about how problems were solved as well as merely solving them hundreds of years earlier, in some cases even arguably thousands of years earlier.
You can waste time by focusing too much on abstractions and elegance for small and unimportant tasks, but you can also waste time by focusing on them too little when the problem is sprawling and long-term. It’s an inherent trade-off in problem-solving, but I would say that I think it’s much easier to underestimate complexity and long-term effects than the reverse.
@@jmxtoob In more experience, the more complex the project, the least OOP is used. Which is ironic for a philosophy designed around "managing complexity"
"We don't solve REAL problems anymore"
The state of the internet circa 2023 is absolutely unprecedented.
Computers literally couldn't talk to eachother reliably prior to the mid 2000s.
Windows machines and Linux machines required heavy middleware to send packets of structured data.
Every company had their own way of doing things that was incompatible with everyone else.
The invention of REST and SOAP as transfer protocols literally allowed any computer and any application written in any language to reliably communicate.
This was a huge problem in the software/internet world.
This problem has been solved.
So don't tell me that programmers don't solve "real" problems anymore.
also compare games, software for 3D rendering, simulation, data routing, not to mention all the AI related stuff, etc etc, almost everything is crazy more advanced and way more complex nowadays.
Not saying nothing was lost in the way, and I sure agree a lot of times people can miss the forest for the threes, or take tools for creeds and what not, but this take about not solving real problems is just really weird.
Programmers today patch code together. They get a pre-made file structure, get some pre-made clean code design, import libraries, copy paste code into methods and create a config file.
Worse yet, they download docker images and it’s all good to go.
Where’s the fucking fun in all that?!
@@ifstatementifstatement2704
They really did take the fun out.
The best part of writing a backend back in the day was when it randomly crashed due to buffer overflows. Or when you forgot to correctly handle bad http data from the client and have the program try to process garbage data.
These days a programmer can setup a functioning backend, frontend, and database; host it on any computer that supports docker, and have it be accessible to the entire world within about 3 hours.
No fun at all.
Agreed. Software is used to solve more complex problems than ever, we got a protocol standardized for almost every kind of common problem, distributed systems have become the norm with 99.999% uptime SLAs for big companies, and my man is like "engineers dont engineer anymore". Hard disagree. It's easy to look at shitty chat app XY written in Electron, using 4GBs of RAM and be cynical, but if you do that you also got to look on the other end of the spectrum and see how awesome a lot of the software is that we use day to day.
And what was YOUR contribution to REST's development?
The average programmer is not doing anything remotely close to that.
Object Oriented thinking replaced mathematics, that's why modern programming suck
While the OOP kool-aid is terrible, whether or not you are solving a real problem is independent from how you choose to visualize and tackle it. Whatever makes sense for you mentally as a code layout, provided you arent doing insane things with memory or stuff like that, is not related to whether your program is solving problems or not. You could just as easily write a procedural style program that doesnt solve anything. This is a small-brain take from Jon here imo, he probably was just mad about something else.
Dude, Alan Kay said himself that OOP is NOT Smalltalk. :-)
Source?
@@ChrisAthanas You can't even do a Google search for it? What are you? An intellectually lazy kid in a cold basement? Here, let me give you some attention. :-)
@@ChrisAthanas Alan Kay himself. He said that messaging was an implementation detail of Smalltalk. It was not meant as a definition of OOP. Other than that... OOP is older than Kay's work on it, but you will have to research that yourself. When you do, you will find that it was originally meant as a memory optimization technique.