Jonathan Blow on the Problem with Object Oriented 

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.

OOP in not a programing language btw

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.

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.

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.

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.

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.

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.

You didn't say anything in defense of OOP, though. You are simply begging for attention here. ;-)

I like OOP. What I hate is when some asshole tells me I designed my classes wrong, acting like their way is the one and only way.

@@ifstatementifstatement2704 The fact that you have to use a class... 😬

exactly how i feel about this guy lol, i wonder if he spends more time talking about shit than actually getting shit done

@@tekim16755 i can see how that perspective is easy to gain if you only watch the lukewarm take clips on youtube. but in reality his streams are 80% programming, and 20% answering questions from chat and teaching his ideas about how to be a good programmer. a lot of his advice is actually *really good* for 'getting shit done', and i mean after all, wouldn't you believe someone who is making a language, game engine and game all at the same time?

​@@tekim16755If you get more shit done than Jonathan Blow, I would like to see your work.

You can talk once you’ve made a few millions selling a game.

how dare you insult the only sensible programmer in existence

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

@@IDontReadReplies42069 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.

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

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.

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.

> ...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.

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.

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.

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.

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.

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.

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 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

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.

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.

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.

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

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.

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.

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.

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. ;-)

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.

There is meaning in life which is subjective, and varies from person to person, and is ephemeral. What may seem important at one time will be replaced by something else and different people have different conflicting life goals as they are motivated by different ideas of what is meaningful to them in life, some of which can be confused with being the definitive meaning of life, which is dangerous as that becomes an entrenched belief which when found to be different to other people's strongly held beliefs can lead to intolerance of their life choices. On a philosophical level you would actually need to ask what is the objective meaning of life, but alas it is impossible to pose this question as no one can be in an unbiased position outside of life, and the whole universe of discourse, to be properly objective and provide THE ANSWER having considered absolutely everything. Even if it were possible to be situated outside of the universe of discourse you would by definition no longer be included within it, so it would not really be the entire universe of discourse. You need to be a part of it for it to maintain your relationships to things as the whole is greater than the sum of its parts because of these interrelationships, but then when you are stuck in it you can't be outside, looking in, being all contemplative about what the definitive meaning of life is. Then you have the alienation problem, which is even if it were somehow possible to place a clone of yourself outside of this universe of discourse whilst you remained inside of it so it didn't get diminished through the absence of your interrelationships, THE ANSWER would likely be not embraced by those who were inside the universe of discourse even if it were provably true. Their personal motivated beliefs would shun THE ANSWER and THE ANSWER would likely not be of much practical help, or provide any profound insights as to obtain it involved this objective process of being detached from things. However, it could be argued quite convincingly that philosophy has not helped anyone and it is a waste of thought. What is your meaning in life? I like trees.

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.

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.

No he’s directly referring to the OOP paradigm pushed by C++ fan boys

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

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.

Where do you work?

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.

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.

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.

Its been pretty awful for last 25 years

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

Yes if everyone understands the metaphors used and does not overextend them Which is all very unlikely

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.

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.

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.

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?

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 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.

ALL Abstract Factory Factory anyone?

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.

"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".

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.

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.

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.

Sutherland?

@@jacobzimmerman3492 exactly

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.

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.

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.

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.

@@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.

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.

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 RU-vid 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.

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.

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.

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.

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. :-)

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"

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.

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.