@Trevis Schiffer OOP advocates make similar claims as socialists do whenever someone explains the failures of either system. OOP works, you just have to plan better and do it right.
6:34 Yes, for example in Minecraft. Armour stands were at some point decided to inherit the "mob" class (which normally deals with sheep, zombies, dragons, etc. and not items, XP orbs, arrows, etc.), because they share a bunch of properties (gravity, flushed by water, get destroyed when attacked enough, can "wear" armour, …), so pretty much every time something new gets added that does something to all mobs, it almost always has a few bugs with armour stand in the first snapshot, which then need to get special-cased out in the armour stand class later. For example when a new enemy gets added that attacks everything, then it also attacks armour stands.
That's just a wrong use of inheritance, i.e. bad design. You don't use inheritance because types of objects have similar data or functions and you want to share code, but when you want to apply the Liskov substitution principle. Obviously an armour stand is something quite different than a mob type and should never be used as a substitute for such, so it shouldn't inherit from that class either.
@@IkeFoxbrush Isn't a "bad use of inheritance" exactly what leads to inheritance related bugs? If you declare inheritance the norm for type definitions you're maximizing the risk of some inheritance being more trouble than help.
@@volbla By the same line of reasoning all programming leads to programming related bugs. So if we stop programming do we solve all software problems? I don't think thats's a particularly useful argument. I also don't see inheritance as the norm for type definitions. It's one of many tools in a software developer's toolbox and should be used with measure. Even in OOP it's hardly needed and often overused.
@@IkeFoxbrush _"Even in OOP it's hardly needed and often overused."_ I think that's exactly the point that both I, FaRo and Brian are trying to make. Some schools of thought (or workplaces, like the Minecraft development) overuse inheritance because it's useful in theory. In other words, they consider it the norm when defining new types. In practice that leads to some nasty bugs, such as armor stands getting attacked by monsters. In my eyes "Inheritance is overused" is the same statement as "There is a culture that normalizes inheritance." The problem isn't that it exists. Of course it can be useful, just like any other tool. The problem was all along that it's overused. That's what leads to a bigger risk of mistakes.
"Speculative generalization" is a good phrase. I was looking for a phrase that is analogous to "premature optimization" in terms of premature generalizations that I've seen many, many programmers do (especially the ones who think themselves as very "smart"), and it's just as prevalent in the programming world as premature-optimization, and your description of "speculative generalization" is exactly what I was thinking. It should be taken with the same amount of skepticism and perhaps derision as the premature optimization whenever one sees it, since the speculative/premature generalization makes the code less maintainable, and (somewhat ironically but also predictably) makes the code a lot harder to be generalized down the road according to the ACTUAL requirements. It should be taught to everybody as one of the "anti-patterns".
I looked at "premature optimization" to be mistaken for "misguided high level design" for a long time (because of a quote I heard from a Henley talk about how you "do everything top-down except the first time"), but yeah that works too.
donald knuth's admonition against "premature optimization" is widely misquoted and misunderstood. Its better to give people the tools to understand something, then give them general rules to follow.
3 года назад+11
The most extreme case of speculative generalisation would be to replace the entire product with an interpreter and let the end user write the actual code. :D
With 40+ years of programming I feel safe to say that objects (as a datatype) are "good". They serve a purpose; a solution to certain problems. Object 'orientation' however is just silly. It's like saying there is 'variable programming' vs 'array oriented programming'. The whole debate of pp vs oop revolves around a false dilemma in my opinion.
That is the "OOP is just a tool"-argument. But the tool is probably suboptimal. OOP 'objects' does not refer to modeling real objects or a collection of data. Encapsulating state and logic together is a central idea of OOP, which is supposed to modularize the code and achieve massive scalability. Seems like an awkward idea to me that creates a host of problems you could avoid by not doing that. You can achieve the same thing (modularization) by using modules and not coupling state and logic. This can look similar to OOP, you can still do 'speaker.increase_volume(10)', that's just a matter of syntactic sugar but I can't find any advantage that coupling state and logic provides, just problems.
@@pik910 but as data types it is useful. Just imagine complex numbers. Isnt it a good idea to couple state and logic (like multiplying to complex numbers). I prefer a*b instead of multiplyComplex(a,b)
@@andik70This is the thing and I totally agree, down the line we’re always ultimately losing some amount of precision, sure, but it’s the cost of time and convenience. Is it more efficient for us to actually code literally more efficiently, or is it more efficient for us to have an easier, faster and more simplistic way to code? OOP being criticised is interesting from a computer science perspective, but to the majority of working programmers it’s nothing but a thought experiment
As a more or less still beginner in programming I'm actually quite happy to see videos like these which seem much more down to reality than the typical talks wandering off to complicated concepts.
As a professional dev I want to echo the other users, you don't have enough knowledge to assess these vids. I would definitely recommend beginners stick to beginner vids until they have the experience to delve into esoteric topics like this.
@@shiuido359Absolutely nothing in this video is beyond the understanding of your average Java programmer, it is not esoteric. The “beginner resources” you talk about all go through these ideas as well, but instead prescribe a “proper” or “best practice” way of doing it, without explaining *why* as in this video.
it doesn't matter what Alan Kay says, the meaning of OOP has changed now. Meanings change as their usage changes, and the modern OO languages are generally accepted to be "OOP".
@@ysink As does the meaning of "great performance relative to the hardware". Feels like we're leaving more performance on the table than we realized. Definitely explains why a hardware upgrade doesn't feel as "significant" as it used to be 20-30 years ago. Take the drive for minimal size/max hardware utilization from the 1970s (back when Smalltalk was more in demand) to the early 1990s and bring it to today's hardware (with consideration for different u-code) and you'll be amazed with the results.
The farther away you get from the hardware, the more performance you're pretty much guaranteed to leave behind. More than that though, i feels like programmers neither care nor try anymore. Just copy and pray-st from SO.
@@SimGunther Part of the problem with hardware upgrades not feeling as significant as they used to is because they are actually not as significant as they used to be. In the 80's processor speed would literally double from one year to the next. I'm not joking, you would literally go from a 33mhz processor to a 66mhz processor. That's freaking huge, and very very noticeable. Today the yearly increase in raw processor speed is something like 5-15%. Moore's Law was originally coined around this yearly doubling in processor speed. As the doubling slowed down it got stretched to 18 months and beyond, and then the definition altered to a system's total capability rather than its processor speed. Also involved here is the processor stopped being the bottleneck for the perception of performance in most cases. Ever since the 90's its hard drive speed and ram quantity/speed that have dictated the "feel" of a computer. You can look at arguments on old computer forums debating which drives were the fastest and how you should format them to get the most performance out of them - because even a small change there gave a noticeable performance boost. That's why SSD's were such a game changer when they came out - they were an order of magnitude faster than any spinning disk on the market, and that dramatically loosened the bottleneck that was hard drive speed. They are still more significant for general performance than processor speed. That means a computer with a 10 year old processor but a modern SSD and plenty of RAM isn't going to feel significantly different than a modern system until you start doing some processor intensive work, which is not something most people will regularly do. You can think of it as though modern computers can lift heavier weights than they used to but they can't walk any faster. Well, most people don't go around carrying heavy weights all the time, they are just walking, so you don't notice it. Modern software, on the other hand, does take advantage of the fact that processors can lift more weights by adding more and more features. It doesn't feel any faster, but you're doing a lot more work without you even knowing it.
@@jeffwells641 Otherwise a well-explaining comment, but unfortunately I have to disagree with your two last sentences. Modern software have very little or no added functionality, way too often even reduced. But the weight has indeed been grown even hundredsfold, mostly purely due to poor professionality of SW development, and carelessness of developers, as it is nowadays too easy to resort on "just buy new devices, they are cheap".
Just write code that does what you want it to do; stop obsessing over what type of code it is or what "philosophies" it adheres to. Make the machine do the least work possible to safely change the data the way you need it to securely, fitting the code into the right category of design should be done in retrospect if at all.
3 года назад+32
9:23 Oh yes, I had to work in such a codebase for a while… A method "doThing" called a method "doTheThing", which called "doThatThing", which called "reallyDoThing"… and then it often eventually just lead to a library method, of which the source code was not available.
And you if need something more you better create a data pipeline that goes through all the layers instead of getting the data directly, otherwise it's not """"""clean""""""" code.
By the time this man made this video, react was still mostly OOP. Now, most of that part is deprecated in favor of modularization and functional programming. Not only that, but this is more and more becoming the norm amongst widely used frameworks. In other words, this man was a visionary many years ago despite many people calling him crazy
I remember when the video came out, everybody was furious calling him names saying he is a n00b that never worked on a real system before, now everybody either agrees that OOP is bad or they say it's only good in specific situations (which is not really OOP since now the system uses objects but it's not _oriented_ by them).
React was always modeled on functional programming ideas. The fact that they used the class syntax doesn't make it OOP. In fact the switch to only function components and hooks has made the framework incredibly prone to spaghetti, ie stateful and effectful code in every part of the system creating hard to debug problems. The quality of code in codebases I've worked in has steadily decreased since I started working with react in 2014.
@@rumble1925yeah idk what the op is talking about. React has been about composition since day 1. And I agree React has been getting worse, it’s a spaghetti hooks western
Great video! You make some good points about the useful parts of OOP. Unfortunately, many people take OOP to the extreme and make things way too complicated. That is why I usually try not to use OOP unless necessary and don't go overboard with it.
This video was released a few hours ago, so I’m assuming everyone who’s commenting actively follows the channel... so what’s the confusion? People are complaining that no code was shown or that Brian is flip-flopping, but if you’ve watched his videos... he’s explained this before, and given many code examples. Brian’s problem with OO has always been abstraction for abstraction’s sake. He’s demonstrated how imperative code is more straightforward and gives a clearer picture of the system rather than the individual part, and he’s argued that context is important to software-that a developer should be expected to understand the system and not just the arbitrary chunk of logic. This video just expands on these ideas. Watch his other vids if you’re still confused; it’s there; it’s good stuff.
"He’s demonstrated how imperative code is more straightforward and gives a clearer picture of the system rather than the individual part" Which is fine when you're designing a system from square one. However, when you're maintaining and/or extending it, most of your effort is spent rearranging and/or reusing the parts, in which case properly-done OOP is going to save you big time.
Aram Fingal not in my experience. I’ve seen systems that were certainly properly arranged OOP, but they were so over-engineered that they might as well have been spaghetti code. They were prime examples of exactly what Brian’s described in the original video - abstraction for abstraction’s sake, confusing ServiceFactoryInterfaceVerbNoun names, and the actual logic buried behind layers of object-passing nonsense. I know the first video made a lot of people angry but he was bang on with it, in my opinion. Not saying we’ll ever have to give up OOP, because hahaha good luck with that, but I hope people think differently about how they structure their OO code.
@@claireryan7644 "abstraction for abstraction’s sake, confusing ServiceFactoryInterfaceVerbNoun names, and the actual logic buried behind layers of object-passing nonsense" That's not properly-done OOP. Yes, I've dealt with fresh college grads' code where half the lines consisted of one-line methods and the associated Javadoc, Java inquisitors whose sole purpose in life is to condemn deviations from the orthodoxy without producing any code themselves, etc. The fact that some people take the paradigm to a ridiculous extent does not invalidate the paradigm. And a lot of the advice in that original video was horrible. Have fun profiling code where every function is 1000 lines long with only comments separating the different tasks.
Aram Fingal relax, man, I’m just telling you my experience. I’m a senior dev and I have seen a lot of really terrible systems. Yeah, this is an extreme example, but the problem is that it’s not rare and they’re not built by college grads who don’t know any better. They’re built by devs who think they’re doing it right. OOP run amok is a problem and that’s why I think Brian makes some good points. You don’t have to follow his advice to the letter - I don’t - but it did make me think more about how to structure my code. Honestly, I’ve had to debug giant enterprise OOP systems and procedural thousand line functions, and I find both fun? I mean, I love my job, it’d be weird if I didn’t.
9:15 I have always felt this way about OOP, but I can never tell whether it's my inability to understand the code or the code's inability to be understandable.
It can be very readable. It just gets abused by people that like to write complex convoluted code as some sort of "hey look at me" cock measuring contest.
OO modularizes speculatively. Honestly I couldn't have said it better myself. I'm a Go developer and I recently started a job with a lot of Java developers. It's been hard having to go through these code bases that are overly abstract for the sake of abstract. Leading to simple things being done in complex ways. Go and to a lesser extent Rust are really going to save this industry. Go emphasis on simplicity has made my designs far more focused and minimal. And Ilve these videos that patiently deconstruct the dogma of OOP. As a former Java developer it even took me years to unlearn my brainwashing of OOP. I wish there were more people out here talking about this stuff. I also think young developers need to year these ideas.
I won't say to a lesser extent. Both Rust and Go have the module system down pretty good, but for me it was Rust that made me realize what I really needed in C++ out of the classes, and what was unneeded, simply because higher-level languages have had module system for quite some time and Rust proved there isn't anything about this idea that restricts it to high-level code.
I am a beginner programmer and I'm crazy, some people say OOP is good and others say it's bad, I do not enough knowledge to distinguish and analyze by my own what should I do. Btw I study python and use pygame and django
..You know, im glad that Lua was my first language. Procedural coding is how i code normally, coding OOP in even C++ is very, very strange. Breaks it all to pieces and really, REALLY hard to understand what im reading. Procedurally im usually writing in one function, because im usually not doing anything bigger than a few hundred lines... yet. Still dont understand the point of making unnessary functions, why have 17 lines when you can use 6 instead.
I really like OOP but only because I finally understood that I should not over-modularize things. If I have to download, parse and export a file, I should put all this in 1 method if I always have to call these 3 steps all at once. There is no need to separate them just (as you said it yourself) for the sake of abstract. I always start coding procedurally, then when I need to use a part of the code several times I put it in a function, then when I need to use several functions that are part of a same "group" I create a class *or* a main function, depending on the problem I need to solve. Putting everything in classes and separate methods just because "that's what OOP is about" is really stupid. You can do very dumb things with Go or Rust too. The problem is not really the language or the paradigm, it's who uses it.
I used to do speculative modularization. Nowadays is anything but speculative. Lets say you have to display a page of avocados so the user can select the avocado it prefers to add it to a cart. So, classes: PageOfAvocados, Avocado, Cart. There is nothing speculative with that. Feature requirements and how they categorize and break down naturally dictate all your classes. If a feature is way too complex than your clients won't understand it either. A noob like I was, back in the past would go something like: PageOfAvocados, SelectedAvocados, Avocado, Filter, CartController, Cart, FruitSuper, AvocadoSelectController,....
I think anyone worth their salt who's coded for more than a couple weeks in a dynamic language celebrated for OO, like C#, Java, Ruby, etc begins to pick up procedural coding habits out of necessity whether they realize it or not. Even if they think their doing OOP. I tend to think OOP is pretty useful for dealing with dependancy, probably as a bias because it's what I cut my teeth on before going back to learn K&R C. But I also agree with about 95% of what you've said in these videos. In all honesty OOP and it's gurus just have bad theory and a Messianic complex, and anyone who follows their conventions will eventually get sick breaking themselves on the rocks of endless encapsulation and debugging for the stupid class interactions and inheritance they write for themselves, and just say "fuck this noise." And look to static classes and static methods called from main for their salvation because it easier to have one throat to choke when something breaks.
in fact, every GOOD swdev books points against too much inheritance, against multiple inheritance, favoring rather interfaces and logical composition with separate top-down layers and common-sense approach, these days... but too much people, even "teachers" are ABUSING objects for everything/always, ideally agile, on standups :-/
@@7alken It's telling that even OOP gurus finally admitted that the old solution (composition) is way better than their fancy philosophical construct (inheritance). It didn't used to be this way. They used to tell you to add some third class to manage the interactions between classes on different nodes of the hierarchy, adding even more complexity to an already complex system. Now they try to cover their tracks and pretend they never spoused this madness, that using composition doesn't deviate from OOP's original vision, and that's the "right way" of doing OOP. Redefining the concept to keep it alive.
Thanks. Good follow up up to the previous video (which I've only just watched). After years of being a slave to OOD, I have evolved to a similar technique. Pushing as much logic as possible to a central core of pure functions, which are fed by (unpure) apis written in a more OO style. Moving from C# to F# has helped tremendously with this.
15 years in. There has never really been a time where speculation turned out in my favour. Everytime the boss comes around with a new idea which my speculation did not predict. As such my glorious framework coudln't accomdate this "rapid iterating". wasted time, and had to be redsigned a lot, didn't prevent bugs anyway. Nowadays. I just make the code as bare-bones as possible. Cleanup where neccesary.
When you brought up the separation between state and logic modules, it immediately reminded me of pure functions vs the IO monad in Haskell. I think that's one of the reasons functional programming has such a good reputation. It enforces a separation between logic and state management while encouraging a coding style that keeps the latter to a minimum.
Huh. I thought functional programming has such a bad reputation for being unintuitive and hard to learn, basically because it isn't imperative. I myself like functional programming (I'm a math major anyway) but I totally understand why my computer science friends dislike it, it's very different and you couldn't really think in terms of loops and iterations with steps anymore, unlike imperative which always lets you choose between iteration and recursion, etc
Your videos are very delightful and useful. They teach properties, problems and philosophies rather than merely recipes(also they go straight to the point).
This is my understanding of what was presented along with questions. Am I misunderstanding any of these concepts? State Modules: Understanding: Stores state of the program, avoid merging state with various logic units to help managing state across many features while also providing a "simple" interface to obtain said state. Question: Say we have an inventory and common functionality is to add or remove items from the inventory. Since this functionality only modifies the state it belongs to, inventory, and nothing else, I feel it would be okay in this case to merge state and logic into one module? Logic Modules: Understanding: Essentially pure functions that recieves state and outputs a 'copied' transformed state. These should avoid directly modifying program state and instead defer that role to whatever called it. By this logic, could this be considered a form of pipe and filter mechanism? Question: How would the actual state updating take place, a different kind of module that essentially links the two? "Controller Modules" To address the previous question you essentially have another form of module that orchestrates these interactions. Is this completely off base? For example, say I have the inventory again and some mechanism to pick up an item to be added to the inventory. 1 - The controller recieves a pick up request 2 - The controller goes to state management to obtain Inventory state from a state module 3 - The controller goes to a Logic Module to transform the pick up item Id to the actual item to be stored in the inventory 4 - The controller gets an "Item to be stored" from 3 5 - The controller updates Inventory (using the provided transformations in the Inventory state module, else a logic module) 6 - The controller requests an Inventory state save by passing it to a "Serializer" Logic module 7 - The controller goes to whatever manages the database and passes the serialized inventory for saving Step 6 is where I can see a bit of mess. Would it be better to have all "pure" state transformations contained within the same state module such as "Inventory", or split it up into "Inventory" and "InventoryLogic"?
I programmed for 3 years with OOP in mind and could never do it perfectly. Not even decently, i always wasted time on thinking about abstractions, there goes 3 years wasting my time on OOP, how ever when i tried to write algorithms like sorting algorithm without thinking about objects i was always faster
a to b, get working "prototype" then you can start doing "refactoring" or more like starting from a again (you fully understand the complexity beyond the problem), only with the idea of how it could be encapsulated and I'm sure you will see much better code without huge thinking, I admit I have kinda problem with OOP too :D
Why would you try to hammer a square peg into a round hole. OOP is a tool that has a specific use, if you try to use it for everything its going to seem bad. If you use it for its intended use, it will be useful. You don't need objects to write a simple sort and doing so is bad and you should feel bad.
I'm loving this video series. I was taught OOP in college, but I quickly grew resentful of things like inheritance and over-complicated encapsulation. But I've had a hard time defining and naming which kind of programming style I actually do advocate. This series has helped me a lot with that.
It's really refreshing to see someone explain why OOP is bad and how OOP could be good (in a more recent video than this one), because I kept saying for at least half a decade that OOP is not a good programming paradigm in the way it is being taught, used, and advertised, but I couldn't quite externalize the exact problems it has. I had a hard time properly understanding what "state" and "logic" really meant, in essence. Until he called them "data" and "actions", which is when it clicked, for me. The reason is because OOP made me confuse things, because an object inherently by design had both data and actions, and the data and actions are tightly coupled.
I don't code much, but I've listened to most of Brian's viedeo out of just the pleasure of hearing him elaborate his opinions. Very well exposed, good luck with your future projects!
The state vs. logic separation is bullshit. Both build from same primitives and separation does not have a function. Private/public is also bullshit because their duality serves no technical purpose. Hiding things vs. letting something vary (exist typing) has huge differences. OOP conflates ideas such as these together arbitrarily. OOP fails to convey the idea that state and process are same thing. OOP enforces too early breaking into submodules that make no sense. It's a net-negative grabbag of crappy language design ideas that will haunt people for decaces.
I found the idea of splitting into state and logic modules quite similar to what data-oriented design proposes. Although the idea there is more about collecting things in large arrays so they can be process efficiently together. Improved modularity and better handling of cross-cutting concerns is a nice benefit though.
Man that ending picture of Alice is exactly how I feel when I look at some legacy code. And the Chesire cat is the comments of the lead engineer who quit the job 3 years ago.
In C code design in our big work projects, we call a C file (.c + .h pair) a “class”, which effectively acts as a static class, much like your concept of a module.
It's the concept of modules which is important, to break up a large project into manageable parts. A class is usually a poor solution to gain namespacing/module behaviour.
OK, programmers seem to be obsessed with the way they organize their source code, without ever giving a thought to the obvious: every capable compiler will completely flatten whatever elaborate code organization you came up with for the purposes of your "team" (aka group of people who can't stand each other and who don't talk to each other except when the entire building is on fire). What you would have to think about, instead, is the runtime organization and dynamic execution of your code, which has little to do with how you define interfaces, datatypes etc.. That is mostly a function of the actual control code that you put in.
I think your state/logic modules need an example. Otherwise this 9 minute video very clearly formulates what i was always feeling about modularization and OO but never could succinctly formulate. Thank you for that.
@@YYYValentine He's probably talking about either Object-Oriented Programming is Embarrassing: 4 Short Examples or Object-Oriented Programming is Garbage: 3800 SLOC Example. I think the 3800 SLOC video is the one where he really goes into re-organizing the code and splitting out the logic from the state.
@@VivekYadav-ds8ozhow do I know what is a real world go/rust project? The NES emulator written in go which is shown in the OOP is Garbage video seems to me like being a real world go project but I guess its badly written. Else it would not be in this video.
Hi! Thanks for the interesting video. FORTRAN 90 language has a very nice module programing style. I worked with some computational tools written in FORTRAN 90 and everything was a module and had the public and private interfaces. In all honesty, it was very very easy to follow the code and understand the codes. I totally agree with the module oriented programming. It is really nice and efficient.
This video I found thought provoking. Without counter arguments, a clean distinction between state and logic sounds nice. What I both disagree and agree with is preemptive creation of abstractions. At least the way it was presented, it sounds like start coding and worry about design later. Design is about abstractions. If you have a good design, then creation the abstractions just an exercise of writing code. I do not agree with trial and error programming. It has the fundamental flaw that your resulting code seems to work, but you never put enough time into design(creating abstractions) to know if the end result is ideal. I work with this type of code all of the time. It's passing tests, it passed QA, it's been running live in prod for decades and no one is complaining, therefore it must be "correct". Nope. Many dozens of people have read the code, but few find the logic flaws that masquerade as working code, but silently corrupting data in novel ways that few could even fathom. Correctness of code requires design and abstractions are just codified reflection of the design. Abstractions are required for any correct code, regardless if it's implemented as an abstraction in the code.
Design is about fitting the problems to solve, abstraction is a tool in that it can reduce complexity / provide guarantees and increase efficiency (if done right). But the wrong, too many, or even missing critical abstractions all contribute to problems. The wrong and too many are the most devastating however, so avoid abstractions that serve no purpose in the near future. With respect to trial and error being bad and needing design first, that is just being evasive IMO. Designs requires trial and error iterations as well and there is no logic in thinking that the process needs to be fully separated from creating code. Nothing is perfect right away and lots of trial and error is how people learn and grow. The best working designs have lots of conscious iterations performed on them, each to stress it in a different way and are not grounded in a rigid methodology. Its a mental process foremost, not something that can be encapsulated in "tests" all that well, make sketches, verify assertions and solve the puzzle. And this is why there is no set recipe, only talent and experience factor in and its also why its delusional the industry tries to commodity the work as if its a packaging factory. A development process is like creating a sculpture from nothing, with the only differences that there are objective results to be met and a rich toolbox you can learn and use. There are techniques that help, defensive programming for one and seeking out the simpler kind of solutions first. As for long "working" code that silently corrupts data, that likely has nothing to do with how its made and more with the experience level and requirements at the time of making. If a design would have been made first, it would not have been any better as a persons capacity and experience is the same. Most don't know what they do not know, but don't get me started on that. Today's typical developers look like monkeys to me now. Still, some of what I see I used to have as well, in the end, its that all important experience over time. If there was a recipe we could all follow for perfect results, that would be convenient, but there is not.
@@TheEVEInspiration I would say thinking about the problem throughly can probably reduce the amount of iterations. I guess this is the main point behind "design first". It can therefore reduce development time. When only limited time is available (which always is), it can also increase quality. However, I think it's more important that the developer is actually willing to try different approaches. This might also include that the developer might have to refactor lage portions of the code he has already written.
I have enjoyed this series. I agree with many of the strong points in earlier videos, and completely with the presentation of those points in this video. I laughed out loud when you said UML was fucking useless in the last video. I'm a systems engineer and it sounds like you would believe the number of times I find a modeler head down in their model, which has grown into an enormous unwieldy beast, obsessing over notation and symbology. But it takes them quite some digging to remember why they're modeling in the first place.
Even when I write in Java, I tend to only write procedurally unless I want to represent a noun. In that case, I write a class - or multiple classes in a hierarchy - that contain the components of that noun. For example, a button would have a position, a size, and a displaying state. This is neater than programming in C, which tends to turn into confusing spaghetti code because of headers and source files. However, there are no "verb" classes in my code. This makes sense, and is probably one of the biggest criticisms of yours leveled onto OO. The truth is, the problem with OO is that people misuse it and make things confusing. It's not good or bad. It's like any other paradigm, it has its uses. Some things it makes sense for, others it doesn't, but until people stop using it like ketchup on food, it'll have a bad reputation.
What we need is programs that are centred around "types". I've used scare quotes, because I'm anticipating someone is going to tell me that what I'm about to describe is not, properly speaking, a type in the same way that an int or a float is. What I mean here by a "type" is a set of state-carrying variables, each of which is itself a "type" or is a genuine primitive type such as a float or int which does not resemble a set, which is how the word is normally used. For a lack of a better word, let's proceed. The idea behind OOP is to bundle mutable state with methods for mutating that state - these methods providing the "interface" to that state. This requires the external caller of a method to know more than he really should have to. The caller generally knows, at least partially, what kind of mutation of state they want to achieve, or at least, what class of mutations. And the caller generally does not care HOW this mutation is achieved, so long as the mutation is predictable. So, really, the caller should not have to know which method they are calling or what a object's methods do. They should only have to provide a representation of the state they want to achieve, and the object should figure out how to move from its current state to a state in the target class. So instead of "public methods", we should have public variables - public not in the sense that they can be mutated by external code directly ( i.e. without submitting a mutation request to the object ) but that the object's user is expected to know that those variables exist in order to be able to tender state-mutation requests properly. And this expectation is usually made of an object's user in practice ANYWAY, since the caller of some state-mutating method only calls the method *because* they ultimately intend to mutate some state, somewhere ( possibly not directly in the object in question ). An "object" should also have attached to it a set of rules about how it is allowed to move through state-space. Some mutations may be forbidden. For example, if you have a type supporting some non-reversible operation, and a boolean to mark whether that operation has been applied, that value should always initialize to False and you should never be allowed to mutate the boolean variable from True back to False; which is to say, all requests for that effect should be denied by the object. This produces a change in the meaning of "object", because methods are not a part of the object, only typed variables and their mutation rules are. It's a little closer to how Smalltalk objects interact via "messages", but here the method name can never be contained in the message, and the message always takes the form of a class of type values that you want to the object to move into. So if the methods are not actually a part of the object, should they belong to the object? I don't see any necessity for this. You can follow exactly the prescription Brian makes here, and separate state-mutating variables from logic. Here logic is represented by the "objects" (again, scare-quotes signify that we're abusing terminology) and state-management can be separated out into simple procedures, which is an inversion of the normal approach.
I recommend functional programming. You achieve everything you need without abstraction for abstractions sake. Peter Norvig (director of research at Google) demonstrates that 16 out of the 23 patterns in Design Patterns are simplified or eliminated (via direct language support) in Lisp or Dylan.
Design patterns are bandaids for the deficiencies of OOP. There's no question about that. The main reason why a couple of the design patterns even exist is because functions aren't first class members. If we lived in some ideal fantasy land where writing in a functional programming language was maintainable for large codebases, then yes. Writing within a purely functional paradigm would be ideal. But we don't live in that fantasy land.
@@csmusic6505 Haskell is awful... no i'm just kidding... I know it's me that's the problem and not the language... but I'll be damned if trying to learn it wasn't the worst decision I ever made. Put me off of learning programming for like a year. C++ was a breeze to learn compared to it and that says something because C++ is dense. *edit* F it. I'ma f****** do it again! Dusting off that text book and figuring out where I left off. I feel like I've finally had long enough to overcome by PTSD from last time I tried this.
@@cranknlesdesires I probably put another 30-50 hours in before i got burnt out again. But I learned a lot more this time. Probably one more go at it like that and ill be a genuine novice.
@@ethashamuddinmohammed1255 Given that Haskell is purely functional and pretty much everything is immutable, all code deals with logic by default. In this sense, you'll be dealing mostly with "how do I make functions that can be chained together in order to come up with a deterministic result". Operations relying on state on the other hand e.g. IO, or operations that in general, produce a "side effect", are abstracted generally through Monads, which iirc are just data types that wrap around values, but with a "side effect" attached when you want to "get" those values. Monads can also be sequenced together to produce a desirable result, while also maintaining the side effects e.g. obtaining a random integer from a user-defined range can be expressed through "the side effect of asking the user for input is crucial to produce the side effect of getting a random integer"
@@ethashamuddinmohammed1255 It's a bit difficult to talk about Haskell without going through the theoretical stuff since it heavily relies on those theories to accomplish what they do. Here's a short FizzBuzz solution in Haskell. wiki.haskell.org/Fizzbuzz `fizz` is a function that takes an integer and returns the appropriate response string for that integer. This is part of the logic module, since it's not really able to access external state nor does it have any explicit internal state. You have to explicitly pass it the value that you want. `main` is the entry point `IO monad`. Since you can consider the `IO monads` that serve as the abstraction for IO, as part of the state module, it can go ahead and reach out to the outside world to print information, while also being able to use functions in the logic module. tl;dr: Logic modules -> pure functions; State modules -> monads and other abstractions
@@ethashamuddinmohammed1255 The main reason for monads is 'returning an error' from a function, which wouldn't otherwise be possible without side effects. Let's say you have a:: Int -> Int, b:: Int -> Int and you call b . a, but there is a possibility that a returns an error, so you change the declarations to a:: Int -> Maybe Int, b:: Maybe Int -> Maybe Int, where Maybe is an example of a monad that either has a value of Int or is an 'error' - a value named Nothing - and it comes prepackaged with Haskell. Turns out this is convenient in general anytime you need to replicate exiting a function chain and even elsewhere. Maybe monad and the IO monad are the most used examples of a monad.
Truth be told the most important thing is the KISS (Keep It Simple Stupid) principle nothing is more important than that. When it comes down to it the only thing you truly want is to understand the code from others as fast as possible without thinking too much about it. So if others read your code and understand it as fast as possible then you achieved KISS if not then you didn't. The programming paradigms like OOP, procedural and so on are theoretically only trying to help you achieve KISS. And how can you achieve KISS in a complex program? You need to use an enormous amount of time in the planning of the said program there is no good way around that. Well at least this is my personal opionion :)
The issue is less how simply you archive a goal, but the sheer number of them. OOP philosophy encourages high abstraction, high encapsulation, high constrain .... it gives you much more goals than just delivering the feature requiring you to juggle a billion of made-up concerns which leads to complexity even with KISS.
I think this is a great refinement to the orignal video, as someone who would label themselves a OOP programmer, its the way I was 'raised' so to speak, I found myself resoundingly agreeing with this entire video. Its all about moderation, abstraction and ecapsualtion are absolutely useful concepts but can definitely be taken too far. I would like to think that no single paradigm is best, and that the best programmers are those that have a solid grasp of the basics of all paradigms and that the best languages/frameworks are the ones that allow us to use a healthy mix of all those concepts. I would like to think that modern programming, for the most part, is multi-paradigm
Your comparisson of imperative programming with OO does not make sense to people with a CS/OO background. You misunderstood the principles of OO, like encapsulation, inheritance, generics and functional programming (=programming with callbacks), design patterns, RAII, immutability, and how those principles would help with reducing code, design and algorithmic complexity (like minimizing cyclomatic and cognitive complexity), ensures thread-safe code and minimizes code-duplication. You seem to be stuck into the C/imperative thinking (try to re-invent the wheel yourself) and you use that to translate it to making it fitt into classes, like your invented "state modules and logic modules" But OO is not about C programming trying to fit into classes. A lot of people make that mistake though, as the comments make clear, so nobody to blame. An example in C which I see a lot: supose a method called makeSound(), taking in a parameter that represents a pet, in which it could execute a switch-case or if-then-else and checking for the input parameter type. In C that would be a O(N) operation, in a OO language you would represent that differently with polymorphism which would be a O(1) operation (or better yet: generics, which changes the branching from run-time to compile time and still be O(1)). An other example: how to implement loose coupling in C, where you would have 2 "modules" depending on each other. In principle, in C one could use function-pointers as callbacks to solve that. But reality C programmers don't think high-level and don't know about when to use it, so what I see is that people just use "singleton"-like spagetti constructs. In an OO language, one would use the observer-pattern one way or the other (or event-driven programming like lambda's). An other example is how state-machines are implemented by typically imperative/C programmers: if-then-elses and spagetti all over the place and O(N) solutions! In an OO language one would use something like the state-pattern or derivatives and have O(1) execution. It would by definiton a lower cyclomatic complexity than the imperative method
To me, the first thing I imagined when you talked about splitting logic and function modules was actually functional programming. At a first glance the distinction between state and logic seems to map to the difference in Haskell between functions in the IO monad and any other function.
I had a hard time properly understanding what "state" and "logic" really meant, in essence. Until he called them "data" and "actions", which is when it clicked, for me. The reason is because OOP made me confuse things, because an object inherently by design had both data and actions, and the data and actions are tightly coupled. It's really refreshing to see someone explain why OOP is bad and how OOP could be good (in a more recent video than this one), because I kept saying for at least half a decade that OOP is not a good programming paradigm in the way it is being taught, used, and advertised, but I couldn't quite externalize the exact problems it has.
His argument that OOP splits stuff not when it gets to big but preemptively I feel is slightly off. With OOP stuff is split based on context. Not that there isn't a problem with this ofcourse as it truelly depends on how indepth you want to define the context. As an example lets take the classic car example. How far will you go. You can seperate it into the body, the engine, the drive shaft, gearbox, tires, etc. But lets look at the tires (mainly cause they are simple and im not a car person). You can define these as 1 single object which defines its properties based on a couple of variables and provides some calculations methods. Should be fine for anything other then indepth realistic physics simulation. However if you really want to split the atom and get to the quarks you can say, "well yes but the tire has the bokts and then the tire, and the thing that the tire is arround, and then the thing that makes the tire look nice" (I told you not a car person). You could split all these things up into smaller sub classes and further abstract everything out. However at this part you have to look at about 6 classes just to get the entire picture while when written as one it can be completely representend in one class. However on the other side if you dont abstract the car you end up with a file thats thousands of lines long and that makes it difficult to just look at 1 part of it.
This exactly. The problem with writing one module that contains 1000s of lines of code to cover everything for the tire is when reusing that module elsewhere, every car gets the exact same tire assembly, unless the copy of the module is changed internally, which now introduces more problems with code maintenance because several modules will be very similar with slight changes. The problem is not with OOP; the problem is with people creating spaghetti code whether using OOP, Procedural programming, or any other code paradigm.
@@jajwarehouse1 yes if you have a massive class with several different ways of behaving, means you have a lot if statements and it becomes hard to follow one path. On the otherside if you abstract too much you have too many sub clases and it becomes difficult to see the entire logic as all the parts are in different places and you almost need to have 7 classes open in different windows.
OOP creates the need for a bunch of shitty design patterns that are just not needed if another paradigm is favored. Yes that other paradigm will require different abstractions that do constitute in a way design patterns themselves but its just not the same.
A great complement to your "OOP sucks" videos! So may I summarise the argument here as that (a) a well designed and appropriate level of modularity is an essential strategy to control and comprehend all complex computational systems, (b) concentrating on artfully defining good stable data types and abstractions (ie *what* is being shared between modules) is usually far more important in writing modular code than concentrating on defining module interfaces (ie. what the modules actually *do* to the data), and that (c) most of the problems with object oriented programming that you were referring to in your earlier videos were related to OOAD's propensity of taking patterns which may sometimes be useful to control complexity at high levels of scale, and rigidly (dogmatically) applying them in situations where they unnecessarily *add* complexity. Or, more poetically perhaps: coding complex systems is an art, and modularity is its paintbrush...
I believe you are against abstraction and prefer concrete code and don't like reusable code as it can be re-used incorrectly all your arguments just point to bad design, implementation or incompatibilities brought about by the constant need for software changes nothing to do with OOP.
Although I don't agree with everything you say, I'm quite intrigued with your monologues. I'd love to see a debate between you and Huw Collingborne, the Smalltalk guy. Not an argument, just a pro/con discussion about OOP following proper debate rules. Your opinions tend to be polar opposites, even concerning which came first, the object-oriented hen or the procedural egg. It could be quite the event, especially if you did it live. You'd have all us nerds on the edges of our seats. 🙃
100% agreed. What irritates me about OOD is that is feasable by it's proponents to predict future cases and all possible scenarios and this is IMO pure arrogance. When you start using keywords like "public" and "private" is like you are saying that you know what somebody should access/call and what not in every possible scenarios present and future and since nobody is omniscient many people will be pissed of by your choices of limitating access to some parts of the code.
Exactly this. One man's idea of pure design is the next man's roadblock when changing the design. In many cases source code cannot be modified, so you are at the complete mercy of the designer. Countless times I've had to *rewrite* existing code just so I could gain access to hidden data I needed. Simplicity should not be confused with stupification and distrust.
This is something I had always had to argue with my team lead, what to keep private and what to keep public. I mean in your own microservice what is even the point of public and private variables? May be my knowledge is limited and my experience is less, enforcing a certain "this is the way" is too damn arrogant.
It's not always impossible to know what users should and shouldn't be doing. You should assume they'll be following best practices for using your code.
I don’t think you got the inheritance part clear, it may encourage people to use inheritance just to “reuse data member declarations” forgetting all about LiskovSP. Let’s first separate public inheritance (the most common one, like Java) from private inheritance (what you exemplified with go). To put simply, public inheritance inherit data AND the interface, private inheritance inherit data WITHOUT changing the interface. Using the public when you actually needed the private is a mistake that many OO code does. If the language doesn’t support an equivalent private one (go embedding, private mixins or traits, etc), just use composition instead.
I absolutely agree with this video! I have seen proprietary frameworks (in Java) with crazy chains of abstract classes and inheritance and NotImplementedExceptions to know that you cannot push OOP too much. And yes, you still need “some” OOP ideas to split things up when they are “too big”. Just like many comments below said, don’t let yourself stuck in a certain paradigm.
This is what have been serving me well: 1. A requirement usually can be split into a small number of sub cases, and this is where I think OOP would help a lot: let a component handle a sub case. 2. Within a component, use procedural programming, as it’s likely a list of actions you have to go through while keeping tab of your current state. 3. When an action is too big, then I write pure functions to deal with them. This also likely makes code in 2 looks like just going through a short and sweet bucket list
you can code good oop code and good functional style code... sadly 99% of coders dont know shit on how to cleanly code in any of them.. this is from 20years true experience in 7 languages including 4 multiparadigm one.. extensions method and generics can work very well with OOP for generic programming.. functional programming can often become unreadable.. even senior do it wrong.. you dont need to always use only inheritance in OO.. you can use composition etc.. and most inheritance is at the bottom of the layers and it's perfectly fine to use it there. Of course you need some extensions mechanisms like extensions methods in the language too.. dont listen to this guy who never really coded.. it's never one paradigm vs the other.. its one multiparadigm language versus the other.. language tackles problems as a whole.. this is why they should be compare as a whole... only idiots who never understood coding preach otherwise..
Hey Brian, I have to disagree with your assessment of OOP vs Procedural, I’ve found that you can often modularize by accretion in OOP by splitting as class gets too big. However I think this may be a result of me adopting a hybrid approach of not following pure OOP design principles. Pure OOP usually ends up with people spending more time philosophically debating over objects rather than solving problems (as you described in your previous OOP is bad video) I think there needs to be some balance in terms of how we program, pure OOP or pure Functional or pure procedural programming tend to be either damn near impossible or unwieldy. I find that there’s often a sweet spot somewhere in between and every project has a different spot. The real art in programming is finding that sweet spot. A good programming language gives you the freedom to explore in search of that spot, and for all its flaws, I find that JavaScript seems to be one of the few languages that gives you something close to that freedom. Are there any other language that are like this that aren’t a hot mess?
I would like to say C++ but it's pretty much a hot mess. I mostly program in Java and I like to say that, despite it being pretty much completely OOP, if used correctly you can design your programs well, it's gonna be much cleaner than programs in C are most times. Code from bad programmers or beginners though is often horrible. Creating objects for every darn thing, sometimes there's loops where you could just re-use an obejct for calculations and instead they create a new one every time. Just to name an example. Sometimes I wish to have strucs t/ own data types besides objects in Java to make this even less of a problem, but I guess that defeats its purpose and is perhaps even not easily made possible. I've been eyeing C++ a lot because of this, but as I wrote in the beginning it seems mostly like a complete mess of missing or weird standards to me, so I'm reluctant to switch over for more than microprocessor programming. Besides my current projects being in Java and me likign to be able to reuse them of course.
Kotlin is my favorite language at the moment. It is very flexible to different programming paradigms and it is pleasure to write because the syntactic noise such semicolons and unnecessary brackets has been minimized.
Interesting video series. A lot of it is over my head but I'm beginning to grasp the differences between styles and what's dogma vs what's reality. When I compare what people say about programming against the quality of programs, I see abstraction as a stopgap for lack of competence or willpower, kind of like owning a car makes it less likely for people to walk or ride a bike even in situations where it would make sense. Maybe this is a result of the industry pushing for results prior to things being ready, and people have to take shortcuts as a result. In the video game industry, I think of a game like Pokemon Blue/Red vs games of today. Games today can sometimes barely get past the damn title screen without some sort of bug, while people can literally build a working chatroom inside of the original Pokemon games and those suckers will just plow through every bug like they aren't even there. Bugs became features that sometimes made the game more fun and replayable, while today things often just break. If we're really abstracting and segregating or whatever the dogma is, I would think several pieces of the machine can break before the full program goes down, but most often that isn't the case. The main question I ask is this: How much extra stuff should I have to learn/read for the sake of making my program more readable? I started my programming journey with Python, and when I try to read other people's programs, I often see imports for stuff even I could do, as a rookie, with a few lines of code. Instead, they import an entire module to accomplish a simple thing, which tells me they aren't actively considering the necessity of what they're doing, they're just pressing buttons in the right order to make the machine go, because that's what they were taught by other people who were taught the same thing by the last guy.
The two main problems with OOP are that it asks you to move run-time decisions into compile time, which requires endless re-factoring if you made the wrong design choice and/or the requirements change. The second one is that it forces you to make poor data layout decisions that are based on form over function. That can literally destroy performance in a few lines of purist code.
I would love to see a video about you make an application with oo, and with your concept, to see it in practice. I am very optimistic about your way of doing it.
Let’s call state modules “structs” and logic modules “interfaces”. And I think there should be a read only scope, such that you don’t need getter functions. You’d basically get what you want in C if there was a special type of struct that only contained function pointers.
A struct with a function pointer is basically just OO design, without the OO security blanket that takes care of making sure the function pointers just point to the correct method... There is a place for abstraction, just not most of the time that people use it.
@@asdfdfggfd just because something is an object doesn't mean you have an OOP design. Author doesn't think that objects are bad, he thinks that OOP is bad because it forces too complicated levels of abstraction that makes things hard to underestand and requires much more effort to write and mantain.
@@asdfdfggfdstructs with function pointers are a procedural design and always were a procedural design. OOP is defined by polymorphism and inheritance. You'll never see a struct with a function pointers in an object-oriented codebase.
I think the paradigm used should adapt to the problem at hand. So I kinda disagree with this, because there have been times when OO has served me beautifully, and times when it has not. I think your idea would suffer from that as well. From where I stand, I seems like it's ultimately situational. Any language which enforces a specific paradigm is also a language that restricts certain use, and makes performance compromises for style. Basically just use C++.
Im trying to get into OOP and the picture you put of the empty box is how my head feels. In theory I very much get it and it's implied usefullness. But when i sit down and try it out my head feels so stretched and empty and a mess. I don't know where the hell the start but at the same time I do know where to start. But im in a state of overthinking it for what, im wasting time.
One of the most obnoxious things to me about C++ is how every time I need to use libraries and parts of the language I'm all not that familiar with, I end up having to jump all over the documentation at each line I code in order to write something I would be able to implement in plain C in 10 minutes, and as a bonus the initial code will often contain tons of runtime bugs because I wrongly assumed at some point a method's behavior based on its name or by analogy with similar classes. Alternatively, the language and libraries will accept code using a combination of advanced features, only to realize later on that the program is doing something else because some feature is not supported. Yesterday for instance I discovered the hard way that STL containers so not support polymorphic pointers. or rather any polymorphic pointer stored in the container will lose any association with the derived class. This kind of problems not only make programming a lot less fun, but also make you wonder what's the point of attempting so many features and such complex structure, if they later break down for so many non-trivial cases.
That you take a lot of time to understand the libraries of C++ is probably just because you're used to programming in C and know its libraries. I mean I have mostly no clue about libraries in C++ myself, but it's safely not harder to basic or even advanced stuff than in C. Could be wrong though. C++, as a language itself, is pretty much a mess, I can agree with that. Sometimes I have the feeling that there's 10 ways of doing the same thing and that 7 of those have no reason to exist.
@Zamundaaa My main issue is not whether I have learned the libraries enough or not, but rather that there are so many of them, and yet they are often not reliable enough. After many years of programming, I have come to the conclusion that there is some irreducible complexity intrinsic to every task, and that you can ignore it or delegate it to some library at your own peril. The moment, for instance, you introduce a new C++ algorithm class to substitute characters in a string, something that can be done in ONE line of code, is the moment you are polluting the language with useless garbage, while increasing the size of the documentation for no good reason. Now I suddenly have to look up what are the fail states of this new class-function, because there is no way I will remember them off the top of my head next time I'll have to use them, or how does it parse or deal with C-like terminated strings, return and linefeed characters, etc. You basicaly traded one line of code for one documentation lookup, which takes at least 10-100 times longer to find, read and understand.
@@KilgoreTroutAsf yeah I can definitely understand that. Rather have a good library than a thousand bad ones. That's also a reason why I redo most minor stuff myself, at least in my own personal projects. Even with Java, where most stuff (that I came across) is done pretty well in the standard library. I got my own "Utils" project with some stuff missing from the standard library or where I don't need the full default implementation but rather a specific thing. It's pretty useful. Not necessarily too practical when you write software for others though.
Some really good ideas here, I've been thinking about similar things too. It feels like OOP is kind of a halfway house, some of the principles like polymorphism are great and some like inheritance can be positively bad, I've seen class hierarchies 10 levels deep, there's no way that is good design
@@n8style I'm sure you'd tell me encapsulation is the third. Slap whoever taught you that. You can have OOP without them. I can give you examples of OOP languages without them.
@@khatdubell not sure what you think OOP is but am certainly curious about these OOP languages that apparently don't have any of the 3. If you mean you can write code that doesn't take advantage of the 3 in an OOP language that offers them then I'll be pointing and laughing just so you know lol
@@n8style No, i mean there are languages, widely accepted as OOP languages that don't have those features. Simula, the grandaddy of them all didn't have any encapsulation i believe. Visual Basic, if memory serves, doesn't have any inheritance. There are a large amount of OOP languages out there, i'm not gonna go through an exhaustive list. The point stands, there are many languages that are considered OOP that don't have what everyone considers to be absolute to the existence of OOP. Its jus that modern OOP implement these things because they are, in general, good things and it doesn't make sense to exclude them. How they came to be considered pillars, i have no idea. They're just good features every paradigm should use if they can.
You fundamental premise is pure functions and templates. I have the following points/questions: You generally discount inter process communication. (Granted OOP does.) Objects are all about shared dependencies and are to be consumed fundamentally. (This was the point of datatypes.) Lot of combinational logic in theory, is this not impractical? State modules are hell, they have never really been managed in OOP. (Something you have little interest in doing.) Division of labor was why monolithic was shunned. (Poor planning in design and tasking is common in agile.) Lot of people became a fan of iteration and see objects as patches. Inheritance is bad practice and speculation in processor hates it. (Templates did not work beyond static and is also dangerous. CPUs hate space and 32/64 bit (4GB vs 16EB) have issue with it. When consider loops it gets so much worse.) It conflates protocols as data. (IPC is bad, in many cases.) Support cost is larger than hardware cost for most of the history of OOP. (We moved to client side because of this.) Integration and optimization is generally discounted under OOP by design. (This same problem was observed in procedural code.) Small code is reusable code. (This allowed APIs to exist. Procedures technically did this before, however in many case fell on the OS. Limiting cross platforms.) Monolithic and singleton is going to lead to cost and premature optimization. (However this is a weak argument in general.) Lot of people forget about the support cost. Its huge and it scales very badly. They tried to lower the performance to increase the performance. They only have so much productivity.
This idea is pretty similar to Redux and React, All the state is kept in stores, all the changes in state are applied by logic functions called reducers and action creators. and react just displays the UI based on the state
As a well meant advice: I'd recommend steering away from getting into react if you haven't used it much and/or have to work on a larger / complex project. I've started working on a decently big project using react about 2 years ago. The idea behind it really is great performance-wise, but the way it requires you to declare state dependencies is terrible. It's depending on the developer to notify it of any possible change to dependencies of the visuals of the current element, which then invokes the reaction functions that had said dependency registered. If you provide an non-primitive as dependency, it won't detect changes to it's properties, so you might be scratching your head for a while asking yourself why the UI doesn't reflect the values you see in the debugger. With the callback shenanigans you'll see the current values in the debugger, but React didn't apply them to the DOM, as the object reference hasn't changed. If you try to update the state inside a reaction method, you'll get a runtime-error, basically stating 'you can't do that'. In a situation where you only can determine that you need to update the state within in that method, you'll have to force a re-render, as you have to update the state outside of the reaction method first so the reaction callback can see the change. You basically add a react reference object with the only purpose being to trigger a redraw. If that somehow triggers a loop, you'll get another runtime-error. The way it handles the state will not allow you to easily debug it, with current values represented in the developer tools effectively always being out-of-date, so they created a complete react DOM explorer as a browser extension. Because it bloats up it's own virtual DOM so much, it's pretty hard to navigate, and it requires you to manually click on every state variable of an object to retrieve it's current value. The state variables don't even have names, because it doesn't provide a means for that. All state variables are simply saved in an array, where the order of occurrence determines their index. This also means that you're not allowed to increase or decrease the amount of state variables for an element. it may see easily resolvable by just 'planning ahead', but development doesn't work that way, unless you have unlimited resources, and therefore can take your time to plan beforehand, read the complete documentation, experiment, etc. I probably spent a lot more time debugging react-related issues instead of moving forward with programming. I'm a programmer at heart, so i personally didn't mind it that much, but if my goal is programming speed, i'd rather use a mundane environment.
Not a programmer but I keep on wondering. What is the difference between a class and a library? They are both black boxes you use, that you don't care how they do what they do, just that they do what you want them to do. Isn't the idea behind OOP to make such black boxes to organize your code in a clear way? How large these boxes actually are and how many functions are within and how many levels down you go depends on your choice when designing. If they don't fulfill their purpose of clarifying the code and obfuscate it with empty class diarrhea then change your design paradigms. As far as I know, there is nothing stopping you from having no more than 3 layers of abstraction which should prevent writing classes for the sake of code obfuscation (and should keep you within 3-4 mouse clicks away from any part of the code).
_What is the difference between a class and a library?_ A class is the blueprint for an object and describes attributes (What properties does an object/class have?) and methods (What can the object/class do?). e.g.: a car class. A library is a collection routines ususally to tackle a specific problem. e.g.: a library for trigonometry. _They are both black boxes [...]. How large these boxes actually are [...] depends on your choice when designing._ Yes.
The way I think of it is OOP is an expert friendly paradigm, and most people just aren't experts, so they'll end up using the power they get destructively by mistake (a.k.a. shooting themselves in the foot.) You inevitably need to decide how to group logic and data, which is a combinatorial problem, and most of the combinations are just bad. People who aren't strong conceptual thinkers (which is quite a rare trait) will inevitably stumble on some arbitrary design which by chance is almost always bad. Sometimes it's high coupling, which is reasonably easy to deal with (analogous to the accretion problem in the video), and sometimes it's low cohesion, which IMO is the real killer. One responsibility smeared across too many actors. However. I do see expert friendly being equated with "bad" a lot. There seems to be some arrogance tied to that: "I tried it, and I wasn't immediately great at it, so it must be bad." Then starts the rationalization game of finding arguments for why it is categorically bad, but that often just comes out as a not-thorough-enough explanation.
It's all dependent on your use case. These are all focused on enterprise and server programming from the looks of it. Get into games, and one'll see that a focus on state will reign supreme.
5 лет назад+4
Games do have a lot more state, indeed. That's where this approach of minimizing state and isolating state changes and logic becomes even more useful. The use case is "you have state and need to do complex things based on that state, while keeping everything neatly organized". Mike Acton, the guy who promoted Data Oriented Design, comes from the triple A games development industry, and is currently the technical lead of the Unity game engine, where he designed the Burst compiler based on this idea of grouping state changes together, separate from the actual objects. In the sense of complex programs that have a lot of state but still need to be fast, games are very much like enterprise and server programming. There is a book about how this idea is currently applied in high-end games: www.dataorienteddesign.com/dodbook/node2.html I have seen people claim that even if OOP is not suited for regular applications, it is really good for GUI and game programming. The opposite is the case. The more state you have, and the more complex the mechanics, the more important it is to minimize accidental state and keep it away from the actual business logic, to be able to organize everything effectively.
I'm happy that this validates how I've been coding a c lately. I'm in the process of re-writing an old piece of code and I'm pretty much following these conventions. But I got all of this just reading about opaque types and handles.
Thank you! I just watched your OOP series, and really enjoyed it! I strugled with the problems you mentioned, and reached a similar conclusion. If I got it right... Let data be data! Let functions be functions! C++ allowed me to do that, and I often find myself writing: - state-only classes, with no methods (=data modules) - stateless classes, with only static pure functions* (=logic modules) Of course, grouped in proper namespaces, translation units etc. and without abusing, i.e. use normal classes whenever it makes sense. *stateless clases or namespaces depending on where I write that and who is reviewing Sounds like C style. It is not. :)
Its fairly clear to me that people arguing whether OOP, functional etc. are better, are really arguing about whether a hammer is better than a screwdriver or a bunch of glue. The right tool for the job makes sense. GUI design using objects is a no-brainer. Mathematical modelling lends itself to functional far better.
I am 3 years late but maybe it still reaches someone: I find it hard to take actionable items out of this video. Are there books or examples which I can read to stitch everything together?
I had to wrangle a pile of "legacy" code recently and they must have had some dice with generic nouns and adjectives on it, and for every identifier they rolled it a few times. it was madness. couldn't tell head from tail on that beast. had to FIRST rename everything to foo/bar/baz, literally, so these things wouldn't sound so similar. once the misleading words were defanged, only THEN I could start seeing the structure that was there, and rename once more, to something that actually made sense..
Since I worked with ffmpeg i love oop and it's model. The library that I'm using allows me to configure hundreds of fields and arrays for ffmpeg to work correctly. I have no idea what fields do what and which fields affect which. So I'm blindly setting fields and hope for the best. A simple encapsulated Api would help me a lot here.
What do you think abot Entity Component System and Composition Over Inheritance? It seems like ECS is a good representation of what you say, with entities and components being "state modules" and "systems" being "logic" modules.
ECS is a situation where you distribute an array (open product) of entities (open sums) into an open product (an array of components) of open sums (enumerations of components), much like how you can distribute addition over multiplication. You can reconstitute your entities by looking at the entity ID component. This is the most principled under FP where you can talk about a collection of existential/sparse types which may or may not have a component.
This kinda feels like what purely functional programming encourages. It requires you to opt-in into state and so you cannot accidentally mix up state and logic! (simply because execution and time aren't built into the language - you import that from the standard library if you need it and then model it explicitly) And since the way FP does polymorphism (generics, interfaces) is inherently more precise then these taxonomies of classes that OO proposes, your abstractions are usually clear-cut, obey concrete rules and are just way more predictable in behavior. Finally, since in pure FP everything is an expression, everything composes without an issue. (also, boilerplate can be just abstracted away!)
This video exactly matches my experiences. I've never worked on a project where the initial concepts remained intact through the end. Often, the initial concepts weren't just heavily modified, they were actually _wrong,_ and we had to recreate them from scratch after we're experienced getting some parts actually running, sometimes more than once. If our initial assumptions were always right, 95% of our jobs would disappear. OOP purports to be easily restructured, but in real world large projects, it's not, exactly because of the initial _speculation_ OOP requires as Brian noted. I've seen OOP projects end up with _all_ the upper-level modules to be nothing but layers of misleadingly-named empty shells over other such empty shells, with nothing but spaghetti-like mess of templates/classes at the bottom each doing random fractions of what should be integral project operations. Once projects become both large and mature, prescribing OOP for everything transitions from a life-preserver to an anchor. OOP vs. procedural isn't good vs. evil. Yes, pure procedural is like building a house by starting with the outside walls, and leaving everything inside to be decided by later by individual workers with whatever skill and materials they have at the moment. But pure OOP is like building all the walls you might need in the house all at the start, before the buyer for the house is known. Neither way is very good., but a considered combination of these works well. As Brian stated, do OOP where you know a module will remain long-term, because its dividing lines are predetermined in some way, such as separate departmental responsibilities, utilizing different hardware, external regulations, public APIs, separate external customers, etc. Programming requires experience, intelligence, and skill, not some simplistic dogma that cares nothing for your real world evolving situations. OOP isn't a religion to be adhered to by blind faith, it's a useful tool. Use it where it's useful, not presuppose that everything will be a nail for your one-and-only OOP hammer.
Huh, that's interesting, because there's one part of a library that I have where there's code that does some dangerous stuff if it's not handled properly, so I made an abstraction on top of it so I don't have to worry about handling those special cases when I need to use the underlying functions elsewhere.
This appears to all be written from personal experience (this and the previous video). My experience has been completely different, with bad experiences with functional and procedural code and some good and bad experiences with OOP. There's great deal of language like "usually", "sometimes", "often" without any clear cut examples or comparisons. I would like to know some samples Mr. Will is basing his assumptions and opinions on.
That wasn't real OOP. Real OOP has never been tried.
This made me laugh, well done!
Made me laugh as well. Going to use that I think.
haha
@Trevis Schiffer OOP advocates make similar claims as socialists do whenever someone explains the failures of either system. OOP works, you just have to plan better and do it right.
Denmark?
6:34 Yes, for example in Minecraft. Armour stands were at some point decided to inherit the "mob" class (which normally deals with sheep, zombies, dragons, etc. and not items, XP orbs, arrows, etc.), because they share a bunch of properties (gravity, flushed by water, get destroyed when attacked enough, can "wear" armour, …), so pretty much every time something new gets added that does something to all mobs, it almost always has a few bugs with armour stand in the first snapshot, which then need to get special-cased out in the armour stand class later. For example when a new enemy gets added that attacks everything, then it also attacks armour stands.
That's just a wrong use of inheritance, i.e. bad design. You don't use inheritance because types of objects have similar data or functions and you want to share code, but when you want to apply the Liskov substitution principle. Obviously an armour stand is something quite different than a mob type and should never be used as a substitute for such, so it shouldn't inherit from that class either.
@@IkeFoxbrush agree, the minecraft example is not good
@@IkeFoxbrush Isn't a "bad use of inheritance" exactly what leads to inheritance related bugs? If you declare inheritance the norm for type definitions you're maximizing the risk of some inheritance being more trouble than help.
@@volbla By the same line of reasoning all programming leads to programming related bugs. So if we stop programming do we solve all software problems? I don't think thats's a particularly useful argument. I also don't see inheritance as the norm for type definitions. It's one of many tools in a software developer's toolbox and should be used with measure. Even in OOP it's hardly needed and often overused.
@@IkeFoxbrush _"Even in OOP it's hardly needed and often overused."_
I think that's exactly the point that both I, FaRo and Brian are trying to make. Some schools of thought (or workplaces, like the Minecraft development) overuse inheritance because it's useful in theory. In other words, they consider it the norm when defining new types. In practice that leads to some nasty bugs, such as armor stands getting attacked by monsters.
In my eyes "Inheritance is overused" is the same statement as "There is a culture that normalizes inheritance." The problem isn't that it exists. Of course it can be useful, just like any other tool. The problem was all along that it's overused. That's what leads to a bigger risk of mistakes.
"Speculative generalization" is a good phrase. I was looking for a phrase that is analogous to "premature optimization" in terms of premature generalizations that I've seen many, many programmers do (especially the ones who think themselves as very "smart"), and it's just as prevalent in the programming world as premature-optimization, and your description of "speculative generalization" is exactly what I was thinking. It should be taken with the same amount of skepticism and perhaps derision as the premature optimization whenever one sees it, since the speculative/premature generalization makes the code less maintainable, and (somewhat ironically but also predictably) makes the code a lot harder to be generalized down the road according to the ACTUAL requirements. It should be taught to everybody as one of the "anti-patterns".
I looked at "premature optimization" to be mistaken for "misguided high level design" for a long time (because of a quote I heard from a Henley talk about how you "do everything top-down except the first time"), but yeah that works too.
“Prefactoring” :)
donald knuth's admonition against "premature optimization" is widely misquoted and misunderstood.
Its better to give people the tools to understand something, then give them general rules to follow.
The most extreme case of speculative generalisation would be to replace the entire product with an interpreter and let the end user write the actual code. :D
But.... What ARE the actual requirements?
Glad to see an update. Watched "OOP is Bad" several times. Excellent advice.
With 40+ years of programming I feel safe to say that objects (as a datatype) are "good". They serve a purpose; a solution to certain problems. Object 'orientation' however is just silly. It's like saying there is 'variable programming' vs 'array oriented programming'. The whole debate of pp vs oop revolves around a false dilemma in my opinion.
This is how I've seen it
That is the "OOP is just a tool"-argument. But the tool is probably suboptimal.
OOP 'objects' does not refer to modeling real objects or a collection of data. Encapsulating state and logic together is a central idea of OOP, which is supposed to modularize the code and achieve massive scalability. Seems like an awkward idea to me that creates a host of problems you could avoid by not doing that.
You can achieve the same thing (modularization) by using modules and not coupling state and logic. This can look similar to OOP, you can still do 'speaker.increase_volume(10)', that's just a matter of syntactic sugar but I can't find any advantage that coupling state and logic provides, just problems.
Array oriented programming languages are a thing actually, though rather irrelevant.
@@pik910 but as data types it is useful. Just imagine complex numbers. Isnt it a good idea to couple state and logic (like multiplying to complex numbers). I prefer a*b instead of multiplyComplex(a,b)
@@andik70This is the thing and I totally agree, down the line we’re always ultimately losing some amount of precision, sure, but it’s the cost of time and convenience. Is it more efficient for us to actually code literally more efficiently, or is it more efficient for us to have an easier, faster and more simplistic way to code? OOP being criticised is interesting from a computer science perspective, but to the majority of working programmers it’s nothing but a thought experiment
As a more or less still beginner in programming I'm actually quite happy to see videos like these which seem much more down to reality than the typical talks wandering off to complicated concepts.
I love how it's all about the kind of day-to-day concerns working programmers think about
The problem with theories is that you can build abstraction upon abstraction until infinity.. and it's not useful at all.
As a professional developer of nearing two decades I suggest you listen to someone that isn't talking absolute nonsense instead.
As a professional dev I want to echo the other users, you don't have enough knowledge to assess these vids. I would definitely recommend beginners stick to beginner vids until they have the experience to delve into esoteric topics like this.
@@shiuido359Absolutely nothing in this video is beyond the understanding of your average Java programmer, it is not esoteric. The “beginner resources” you talk about all go through these ideas as well, but instead prescribe a “proper” or “best practice” way of doing it, without explaining *why* as in this video.
"This is not the OOP I had in mind"
- Alan Kay, 1997 OOPSLA in reference to Java/C++
it doesn't matter what Alan Kay says, the meaning of OOP has changed now. Meanings change as their usage changes, and the modern OO languages are generally accepted to be "OOP".
@@ysink As does the meaning of "great performance relative to the hardware". Feels like we're leaving more performance on the table than we realized. Definitely explains why a hardware upgrade doesn't feel as "significant" as it used to be 20-30 years ago. Take the drive for minimal size/max hardware utilization from the 1970s (back when Smalltalk was more in demand) to the early 1990s and bring it to today's hardware (with consideration for different u-code) and you'll be amazed with the results.
The farther away you get from the hardware, the more performance you're pretty much guaranteed to leave behind.
More than that though, i feels like programmers neither care nor try anymore.
Just copy and pray-st from SO.
@@SimGunther Part of the problem with hardware upgrades not feeling as significant as they used to is because they are actually not as significant as they used to be. In the 80's processor speed would literally double from one year to the next. I'm not joking, you would literally go from a 33mhz processor to a 66mhz processor. That's freaking huge, and very very noticeable.
Today the yearly increase in raw processor speed is something like 5-15%. Moore's Law was originally coined around this yearly doubling in processor speed. As the doubling slowed down it got stretched to 18 months and beyond, and then the definition altered to a system's total capability rather than its processor speed.
Also involved here is the processor stopped being the bottleneck for the perception of performance in most cases. Ever since the 90's its hard drive speed and ram quantity/speed that have dictated the "feel" of a computer. You can look at arguments on old computer forums debating which drives were the fastest and how you should format them to get the most performance out of them - because even a small change there gave a noticeable performance boost. That's why SSD's were such a game changer when they came out - they were an order of magnitude faster than any spinning disk on the market, and that dramatically loosened the bottleneck that was hard drive speed. They are still more significant for general performance than processor speed.
That means a computer with a 10 year old processor but a modern SSD and plenty of RAM isn't going to feel significantly different than a modern system until you start doing some processor intensive work, which is not something most people will regularly do. You can think of it as though modern computers can lift heavier weights than they used to but they can't walk any faster. Well, most people don't go around carrying heavy weights all the time, they are just walking, so you don't notice it. Modern software, on the other hand, does take advantage of the fact that processors can lift more weights by adding more and more features. It doesn't feel any faster, but you're doing a lot more work without you even knowing it.
@@jeffwells641 Otherwise a well-explaining comment, but unfortunately I have to disagree with your two last sentences.
Modern software have very little or no added functionality, way too often even reduced. But the weight has indeed been grown even hundredsfold, mostly purely due to poor professionality of SW development, and carelessness of developers, as it is nowadays too easy to resort on "just buy new devices, they are cheap".
Best narratives on OOP and procedural programming. Brian gets it and can explain it!
Just write code that does what you want it to do; stop obsessing over what type of code it is or what "philosophies" it adheres to. Make the machine do the least work possible to safely change the data the way you need it to securely, fitting the code into the right category of design should be done in retrospect if at all.
9:23 Oh yes, I had to work in such a codebase for a while… A method "doThing" called a method "doTheThing", which called "doThatThing", which called "reallyDoThing"… and then it often eventually just lead to a library method, of which the source code was not available.
And you if need something more you better create a data pipeline that goes through all the layers instead of getting the data directly, otherwise it's not """"""clean""""""" code.
By the time this man made this video, react was still mostly OOP. Now, most of that part is deprecated in favor of modularization and functional programming. Not only that, but this is more and more becoming the norm amongst widely used frameworks. In other words, this man was a visionary many years ago despite many people calling him crazy
I remember when the video came out, everybody was furious calling him names saying he is a n00b that never worked on a real system before, now everybody either agrees that OOP is bad or they say it's only good in specific situations (which is not really OOP since now the system uses objects but it's not _oriented_ by them).
React was always modeled on functional programming ideas. The fact that they used the class syntax doesn't make it OOP. In fact the switch to only function components and hooks has made the framework incredibly prone to spaghetti, ie stateful and effectful code in every part of the system creating hard to debug problems. The quality of code in codebases I've worked in has steadily decreased since I started working with react in 2014.
@@rumble1925yeah idk what the op is talking about. React has been about composition since day 1. And I agree React has been getting worse, it’s a spaghetti hooks western
Great video! You make some good points about the useful parts of OOP. Unfortunately, many people take OOP to the extreme and make things way too complicated. That is why I usually try not to use OOP unless necessary and don't go overboard with it.
This video was released a few hours ago, so I’m assuming everyone who’s commenting actively follows the channel... so what’s the confusion? People are complaining that no code was shown or that Brian is flip-flopping, but if you’ve watched his videos... he’s explained this before, and given many code examples. Brian’s problem with OO has always been abstraction for abstraction’s sake. He’s demonstrated how imperative code is more straightforward and gives a clearer picture of the system rather than the individual part, and he’s argued that context is important to software-that a developer should be expected to understand the system and not just the arbitrary chunk of logic. This video just expands on these ideas. Watch his other vids if you’re still confused; it’s there; it’s good stuff.
The confusion is that some people that did a tutorial on PHP are very opinionated and will ruin any sensible discussion about programming theory.
"He’s demonstrated how imperative code is more straightforward and gives a clearer picture of the system rather than the individual part" Which is fine when you're designing a system from square one. However, when you're maintaining and/or extending it, most of your effort is spent rearranging and/or reusing the parts, in which case properly-done OOP is going to save you big time.
Aram Fingal not in my experience. I’ve seen systems that were certainly properly arranged OOP, but they were so over-engineered that they might as well have been spaghetti code. They were prime examples of exactly what Brian’s described in the original video - abstraction for abstraction’s sake, confusing ServiceFactoryInterfaceVerbNoun names, and the actual logic buried behind layers of object-passing nonsense.
I know the first video made a lot of people angry but he was bang on with it, in my opinion. Not saying we’ll ever have to give up OOP, because hahaha good luck with that, but I hope people think differently about how they structure their OO code.
@@claireryan7644 "abstraction for abstraction’s sake, confusing ServiceFactoryInterfaceVerbNoun names, and the actual logic buried behind layers of object-passing nonsense" That's not properly-done OOP. Yes, I've dealt with fresh college grads' code where half the lines consisted of one-line methods and the associated Javadoc, Java inquisitors whose sole purpose in life is to condemn deviations from the orthodoxy without producing any code themselves, etc. The fact that some people take the paradigm to a ridiculous extent does not invalidate the paradigm. And a lot of the advice in that original video was horrible. Have fun profiling code where every function is 1000 lines long with only comments separating the different tasks.
Aram Fingal relax, man, I’m just telling you my experience. I’m a senior dev and I have seen a lot of really terrible systems. Yeah, this is an extreme example, but the problem is that it’s not rare and they’re not built by college grads who don’t know any better. They’re built by devs who think they’re doing it right. OOP run amok is a problem and that’s why I think Brian makes some good points. You don’t have to follow his advice to the letter - I don’t - but it did make me think more about how to structure my code.
Honestly, I’ve had to debug giant enterprise OOP systems and procedural thousand line functions, and I find both fun? I mean, I love my job, it’d be weird if I didn’t.
9:15
I have always felt this way about OOP, but I can never tell whether it's my inability to understand the code or the code's inability to be understandable.
its your fault
It can be very readable. It just gets abused by people that like to write complex convoluted code as some sort of "hey look at me" cock measuring contest.
@@Ryan-xq3kl Ok boomer lmao
hahaha. People "think" they can grasp that level of abstractions, but most brains can only grasp those that can be visualized. Sucks. I know. 😅
OO modularizes speculatively. Honestly I couldn't have said it better myself. I'm a Go developer and I recently started a job with a lot of Java developers. It's been hard having to go through these code bases that are overly abstract for the sake of abstract. Leading to simple things being done in complex ways.
Go and to a lesser extent Rust are really going to save this industry. Go emphasis on simplicity has made my designs far more focused and minimal. And Ilve these videos that patiently deconstruct the dogma of OOP.
As a former Java developer it even took me years to unlearn my brainwashing of OOP. I wish there were more people out here talking about this stuff. I also think young developers need to year these ideas.
I won't say to a lesser extent. Both Rust and Go have the module system down pretty good, but for me it was Rust that made me realize what I really needed in C++ out of the classes, and what was unneeded, simply because higher-level languages have had module system for quite some time and Rust proved there isn't anything about this idea that restricts it to high-level code.
I am a beginner programmer and I'm crazy, some people say OOP is good and others say it's bad, I do not enough knowledge to distinguish and analyze by my own what should I do. Btw I study python and use pygame and django
..You know, im glad that Lua was my first language. Procedural coding is how i code normally, coding OOP in even C++ is very, very strange. Breaks it all to pieces and really, REALLY hard to understand what im reading.
Procedurally im usually writing in one function, because im usually not doing anything bigger than a few hundred lines... yet. Still dont understand the point of making unnessary functions, why have 17 lines when you can use 6 instead.
I really like OOP but only because I finally understood that I should not over-modularize things. If I have to download, parse and export a file, I should put all this in 1 method if I always have to call these 3 steps all at once. There is no need to separate them just (as you said it yourself) for the sake of abstract. I always start coding procedurally, then when I need to use a part of the code several times I put it in a function, then when I need to use several functions that are part of a same "group" I create a class *or* a main function, depending on the problem I need to solve. Putting everything in classes and separate methods just because "that's what OOP is about" is really stupid. You can do very dumb things with Go or Rust too. The problem is not really the language or the paradigm, it's who uses it.
I used to do speculative modularization. Nowadays is anything but speculative.
Lets say you have to display a page of avocados so the user can select the avocado it prefers to add it to a cart. So, classes: PageOfAvocados, Avocado, Cart. There is nothing speculative with that. Feature requirements and how they categorize and break down naturally dictate all your classes. If a feature is way too complex than your clients won't understand it either.
A noob like I was, back in the past would go something like: PageOfAvocados, SelectedAvocados, Avocado, Filter, CartController, Cart, FruitSuper, AvocadoSelectController,....
I think anyone worth their salt who's coded for more than a couple weeks in a dynamic language celebrated for OO, like C#, Java, Ruby, etc begins to pick up procedural coding habits out of necessity whether they realize it or not. Even if they think their doing OOP. I tend to think OOP is pretty useful for dealing with dependancy, probably as a bias because it's what I cut my teeth on before going back to learn K&R C. But I also agree with about 95% of what you've said in these videos. In all honesty OOP and it's gurus just have bad theory and a Messianic complex, and anyone who follows their conventions will eventually get sick breaking themselves on the rocks of endless encapsulation and debugging for the stupid class interactions and inheritance they write for themselves, and just say "fuck this noise." And look to static classes and static methods called from main for their salvation because it easier to have one throat to choke when something breaks.
in fact, every GOOD swdev books points against too much inheritance, against multiple inheritance, favoring rather interfaces and logical composition with separate top-down layers and common-sense approach, these days... but too much people, even "teachers" are ABUSING objects for everything/always, ideally agile, on standups :-/
@@7alken It's telling that even OOP gurus finally admitted that the old solution (composition) is way better than their fancy philosophical construct (inheritance).
It didn't used to be this way.
They used to tell you to add some third class to manage the interactions between classes on different nodes of the hierarchy, adding even more complexity to an already complex system.
Now they try to cover their tracks and pretend they never spoused this madness, that using composition doesn't deviate from OOP's original vision, and that's the "right way" of doing OOP.
Redefining the concept to keep it alive.
@@Vitorruy1 any very strict rules are nazi, except the roads
It's almost like C was always the best language and C++ was syntactic sugar to work around bad programmers.
Except in the real world C++ is good and all modern innovations that have higher performance than Cnile crap are written in C++ for a reason.
Thanks. Good follow up up to the previous video (which I've only just watched). After years of being a slave to OOD, I have evolved to a similar technique. Pushing as much logic as possible to a central core of pure functions, which are fed by (unpure) apis written in a more OO style. Moving from C# to F# has helped tremendously with this.
Nicely stated, especially about need vs. speculation :)
15 years in. There has never really been a time where speculation turned out in my favour. Everytime the boss comes around with a new idea which my speculation did not predict. As such my glorious framework coudln't accomdate this "rapid iterating". wasted time, and had to be redsigned a lot, didn't prevent bugs anyway. Nowadays. I just make the code as bare-bones as possible. Cleanup where neccesary.
When you brought up the separation between state and logic modules, it immediately reminded me of pure functions vs the IO monad in Haskell. I think that's one of the reasons functional programming has such a good reputation. It enforces a separation between logic and state management while encouraging a coding style that keeps the latter to a minimum.
Huh. I thought functional programming has such a bad reputation for being unintuitive and hard to learn, basically because it isn't imperative. I myself like functional programming (I'm a math major anyway) but I totally understand why my computer science friends dislike it, it's very different and you couldn't really think in terms of loops and iterations with steps anymore, unlike imperative which always lets you choose between iteration and recursion, etc
Your videos are very delightful and useful. They teach properties, problems and philosophies rather than merely recipes(also they go straight to the point).
This is my understanding of what was presented along with questions. Am I misunderstanding any of these concepts?
State Modules:
Understanding:
Stores state of the program, avoid merging state with various logic units to help managing state across many features while also providing a "simple" interface to obtain said state.
Question:
Say we have an inventory and common functionality is to add or remove items from the inventory. Since this functionality only modifies the state it belongs to, inventory, and nothing else, I feel it would be okay in this case to merge state and logic into one module?
Logic Modules:
Understanding:
Essentially pure functions that recieves state and outputs a 'copied' transformed state. These should avoid directly modifying program state and instead defer that role to whatever called it. By this logic, could this be considered a form of pipe and filter mechanism?
Question:
How would the actual state updating take place, a different kind of module that essentially links the two?
"Controller Modules"
To address the previous question you essentially have another form of module that orchestrates these interactions. Is this completely off base?
For example, say I have the inventory again and some mechanism to pick up an item to be added to the inventory.
1 - The controller recieves a pick up request
2 - The controller goes to state management to obtain Inventory state from a state module
3 - The controller goes to a Logic Module to transform the pick up item Id to the actual item to be stored in the inventory
4 - The controller gets an "Item to be stored" from 3
5 - The controller updates Inventory (using the provided transformations in the Inventory state module, else a logic module)
6 - The controller requests an Inventory state save by passing it to a "Serializer" Logic module
7 - The controller goes to whatever manages the database and passes the serialized inventory for saving
Step 6 is where I can see a bit of mess. Would it be better to have all "pure" state transformations contained within the same state module such as "Inventory", or split it up into "Inventory" and "InventoryLogic"?
I programmed for 3 years with OOP in mind and could never do it perfectly. Not even decently, i always wasted time on thinking about abstractions, there goes 3 years wasting my time on OOP, how ever when i tried to write algorithms like sorting algorithm without thinking about objects i was always faster
a to b, get working "prototype" then you can start doing "refactoring" or more like starting from a again (you fully understand the complexity beyond the problem), only with the idea of how it could be encapsulated and I'm sure you will see much better code without huge thinking, I admit I have kinda problem with OOP too :D
Why would you try to hammer a square peg into a round hole.
OOP is a tool that has a specific use, if you try to use it for everything its going to seem bad.
If you use it for its intended use, it will be useful.
You don't need objects to write a simple sort and doing so is bad and you should feel bad.
I'm loving this video series. I was taught OOP in college, but I quickly grew resentful of things like inheritance and over-complicated encapsulation. But I've had a hard time defining and naming which kind of programming style I actually do advocate. This series has helped me a lot with that.
It's really refreshing to see someone explain why OOP is bad and how OOP could be good (in a more recent video than this one), because I kept saying for at least half a decade that OOP is not a good programming paradigm in the way it is being taught, used, and advertised, but I couldn't quite externalize the exact problems it has.
I had a hard time properly understanding what "state" and "logic" really meant, in essence. Until he called them "data" and "actions", which is when it clicked, for me. The reason is because OOP made me confuse things, because an object inherently by design had both data and actions, and the data and actions are tightly coupled.
I had a problem. So I thought to use Java. Now I have a ProblemFactory.
Look into functional programming.
@@seriouscat2231 Lol, got me with this one :D
I don't code much, but I've listened to most of Brian's viedeo out of just the pleasure of hearing him elaborate his opinions. Very well exposed, good luck with your future projects!
The state vs. logic separation is bullshit. Both build from same primitives and separation does not have a function. Private/public is also bullshit because their duality serves no technical purpose. Hiding things vs. letting something vary (exist typing) has huge differences. OOP conflates ideas such as these together arbitrarily. OOP fails to convey the idea that state and process are same thing. OOP enforces too early breaking into submodules that make no sense. It's a net-negative grabbag of crappy language design ideas that will haunt people for decaces.
I found the idea of splitting into state and logic modules quite similar to what data-oriented design proposes. Although the idea there is more about collecting things in large arrays so they can be process efficiently together. Improved modularity and better handling of cross-cutting concerns is a nice benefit though.
Man that ending picture of Alice is exactly how I feel when I look at some legacy code. And the Chesire cat is the comments of the lead engineer who quit the job 3 years ago.
This video, among other inspirations, has led me to start developing a BASIC-like language that I think fits this ideal for programming.
In C code design in our big work projects, we call a C file (.c + .h pair) a “class”, which effectively acts as a static class, much like your concept of a module.
That's a little confusing given that C already uses the word "object" to mean "some entity stored in memory".
It's the concept of modules which is important, to break up a large project into manageable parts. A class is usually a poor solution to gain namespacing/module behaviour.
I do the same division for C programs. And it was inspired in the concepts of packages from Ada, which are similar to static classes from OOP.
OK, programmers seem to be obsessed with the way they organize their source code, without ever giving a thought to the obvious: every capable compiler will completely flatten whatever elaborate code organization you came up with for the purposes of your "team" (aka group of people who can't stand each other and who don't talk to each other except when the entire building is on fire). What you would have to think about, instead, is the runtime organization and dynamic execution of your code, which has little to do with how you define interfaces, datatypes etc.. That is mostly a function of the actual control code that you put in.
I'm happy to see a voice of sanity in sea of "fad followers". Thanks for the time and effort to make this series!
I think your state/logic modules need an example. Otherwise this 9 minute video very clearly formulates what i was always feeling about modularization and OO but never could succinctly formulate. Thank you for that.
Maybe you know by now, but the guy has a bunch of different videos on the subject, one concerning a larger example.
@@storerestore Which one is it?
@@YYYValentine He's probably talking about either Object-Oriented Programming is Embarrassing: 4 Short Examples or Object-Oriented Programming is Garbage: 3800 SLOC Example. I think the 3800 SLOC video is the one where he really goes into re-organizing the code and splitting out the logic from the state.
Look no farther than practical examples of real world Go and Rust code.
@@VivekYadav-ds8ozhow do I know what is a real world go/rust project? The NES emulator written in go which is shown in the OOP is Garbage video seems to me like being a real world go project but I guess its badly written. Else it would not be in this video.
Hi! Thanks for the interesting video. FORTRAN 90 language has a very nice module programing style. I worked with some computational tools written in FORTRAN 90 and everything was a module and had the public and private interfaces. In all honesty, it was very very easy to follow the code and understand the codes. I totally agree with the module oriented programming. It is really nice and efficient.
This video I found thought provoking. Without counter arguments, a clean distinction between state and logic sounds nice. What I both disagree and agree with is preemptive creation of abstractions. At least the way it was presented, it sounds like start coding and worry about design later. Design is about abstractions. If you have a good design, then creation the abstractions just an exercise of writing code.
I do not agree with trial and error programming. It has the fundamental flaw that your resulting code seems to work, but you never put enough time into design(creating abstractions) to know if the end result is ideal. I work with this type of code all of the time. It's passing tests, it passed QA, it's been running live in prod for decades and no one is complaining, therefore it must be "correct". Nope. Many dozens of people have read the code, but few find the logic flaws that masquerade as working code, but silently corrupting data in novel ways that few could even fathom.
Correctness of code requires design and abstractions are just codified reflection of the design. Abstractions are required for any correct code, regardless if it's implemented as an abstraction in the code.
Design is about fitting the problems to solve, abstraction is a tool in that it can reduce complexity / provide guarantees and increase efficiency (if done right).
But the wrong, too many, or even missing critical abstractions all contribute to problems.
The wrong and too many are the most devastating however, so avoid abstractions that serve no purpose in the near future.
With respect to trial and error being bad and needing design first, that is just being evasive IMO. Designs requires trial and error iterations as well and there is no logic in thinking that the process needs to be fully separated from creating code. Nothing is perfect right away and lots of trial and error is how people learn and grow.
The best working designs have lots of conscious iterations performed on them, each to stress it in a different way and are not grounded in a rigid methodology.
Its a mental process foremost, not something that can be encapsulated in "tests" all that well, make sketches, verify assertions and solve the puzzle.
And this is why there is no set recipe, only talent and experience factor in and its also why its delusional the industry tries to commodity the work as if its a packaging factory.
A development process is like creating a sculpture from nothing, with the only differences that there are objective results to be met and a rich toolbox you can learn and use.
There are techniques that help, defensive programming for one and seeking out the simpler kind of solutions first.
As for long "working" code that silently corrupts data, that likely has nothing to do with how its made and more with the experience level and requirements at the time of making. If a design would have been made first, it would not have been any better as a persons capacity and experience is the same. Most don't know what they do not know, but don't get me started on that. Today's typical developers look like monkeys to me now. Still, some of what I see I used to have as well, in the end, its that all important experience over time. If there was a recipe we could all follow for perfect results, that would be convenient, but there is not.
@@TheEVEInspiration I would say thinking about the problem throughly can probably reduce the amount of iterations. I guess this is the main point behind "design first". It can therefore reduce development time. When only limited time is available (which always is), it can also increase quality. However, I think it's more important that the developer is actually willing to try different approaches. This might also include that the developer might have to refactor lage portions of the code he has already written.
I hit like after your comments about interfaces at about 6:00 . Spot on ;
I have enjoyed this series. I agree with many of the strong points in earlier videos, and completely with the presentation of those points in this video.
I laughed out loud when you said UML was fucking useless in the last video. I'm a systems engineer and it sounds like you would believe the number of times I find a modeler head down in their model, which has grown into an enormous unwieldy beast, obsessing over notation and symbology. But it takes them quite some digging to remember why they're modeling in the first place.
Even when I write in Java, I tend to only write procedurally unless I want to represent a noun. In that case, I write a class - or multiple classes in a hierarchy - that contain the components of that noun. For example, a button would have a position, a size, and a displaying state. This is neater than programming in C, which tends to turn into confusing spaghetti code because of headers and source files. However, there are no "verb" classes in my code. This makes sense, and is probably one of the biggest criticisms of yours leveled onto OO. The truth is, the problem with OO is that people misuse it and make things confusing. It's not good or bad. It's like any other paradigm, it has its uses. Some things it makes sense for, others it doesn't, but until people stop using it like ketchup on food, it'll have a bad reputation.
Encapsulation is a meme.
So trying to access a private member is a meme ??!!
"meaning requires context" win.
What we need is programs that are centred around "types". I've used scare quotes, because I'm anticipating someone is going to tell me that what I'm about to describe is not, properly speaking, a type in the same way that an int or a float is. What I mean here by a "type" is a set of state-carrying variables, each of which is itself a "type" or is a genuine primitive type such as a float or int which does not resemble a set, which is how the word is normally used. For a lack of a better word, let's proceed.
The idea behind OOP is to bundle mutable state with methods for mutating that state - these methods providing the "interface" to that state. This requires the external caller of a method to know more than he really should have to. The caller generally knows, at least partially, what kind of mutation of state they want to achieve, or at least, what class of mutations.
And the caller generally does not care HOW this mutation is achieved, so long as the mutation is predictable.
So, really, the caller should not have to know which method they are calling or what a object's methods do. They should only have to provide a representation of the state they want to achieve, and the object should figure out how to move from its current state to a state in the target class.
So instead of "public methods", we should have public variables - public not in the sense that they can be mutated by external code directly ( i.e. without submitting a mutation request to the object ) but that the object's user is expected to know that those variables exist in order to be able to tender state-mutation requests properly. And this expectation is usually made of an object's user in practice ANYWAY, since the caller of some state-mutating method only calls the method *because* they ultimately intend to mutate some state, somewhere ( possibly not directly in the object in question ).
An "object" should also have attached to it a set of rules about how it is allowed to move through state-space. Some mutations may be forbidden. For example, if you have a type supporting some non-reversible operation, and a boolean to mark whether that operation has been applied, that value should always initialize to False and you should never be allowed to mutate the boolean variable from True back to False; which is to say, all requests for that effect should be denied by the object.
This produces a change in the meaning of "object", because methods are not a part of the object, only typed variables and their mutation rules are. It's a little closer to how Smalltalk objects interact via "messages", but here the method name can never be contained in the message, and the message always takes the form of a class of type values that you want to the object to move into.
So if the methods are not actually a part of the object, should they belong to the object?
I don't see any necessity for this. You can follow exactly the prescription Brian makes here, and separate state-mutating variables from logic. Here logic is represented by the "objects" (again, scare-quotes signify that we're abusing terminology) and state-management can be separated out into simple procedures, which is an inversion of the normal approach.
This looks like just normal programming.
I recommend functional programming. You achieve everything you need without abstraction for abstractions sake. Peter Norvig (director of research at Google) demonstrates that 16 out of the 23 patterns in Design Patterns are simplified or eliminated (via direct language support) in Lisp or Dylan.
Design patterns are bandaids for the deficiencies of OOP. There's no question about that. The main reason why a couple of the design patterns even exist is because functions aren't first class members.
If we lived in some ideal fantasy land where writing in a functional programming language was maintainable for large codebases, then yes. Writing within a purely functional paradigm would be ideal. But we don't live in that fantasy land.
just use python whenever applicable - bang
@@someoneelse5005 I would if not for the GIL
Structs encapsulate data. Modules encapsulate code. Objects are instantiable modules.
OO is bad - 44minutes. OO is good, 9:44 minutes.
This approach is used within haskell 1 to 1.
The more I learn the more I realize how amazing Haskell is
@@csmusic6505 Haskell is awful... no i'm just kidding... I know it's me that's the problem and not the language... but I'll be damned if trying to learn it wasn't the worst decision I ever made. Put me off of learning programming for like a year. C++ was a breeze to learn compared to it and that says something because C++ is dense. *edit* F it. I'ma f****** do it again! Dusting off that text book and figuring out where I left off. I feel like I've finally had long enough to overcome by PTSD from last time I tried this.
@@xcvsdxvsx how did you go?
@@cranknlesdesires I probably put another 30-50 hours in before i got burnt out again. But I learned a lot more this time. Probably one more go at it like that and ill be a genuine novice.
@@xcvsdxvsx which textbook did you use? Haskell from first principle (haskellbook.com/) is probably the best beginner book in my opinion.
This sounds like what I do in haskell.
Can you refer to an example? I would like to understand this...
@@ethashamuddinmohammed1255 Given that Haskell is purely functional and pretty much everything is immutable, all code deals with logic by default. In this sense, you'll be dealing mostly with "how do I make functions that can be chained together in order to come up with a deterministic result".
Operations relying on state on the other hand e.g. IO, or operations that in general, produce a "side effect", are abstracted generally through Monads, which iirc are just data types that wrap around values, but with a "side effect" attached when you want to "get" those values. Monads can also be sequenced together to produce a desirable result, while also maintaining the side effects e.g. obtaining a random integer from a user-defined range can be expressed through "the side effect of asking the user for input is crucial to produce the side effect of getting a random integer"
@@cyclonic5206 Another long theoretical reply. I need code.
@@ethashamuddinmohammed1255 It's a bit difficult to talk about Haskell without going through the theoretical stuff since it heavily relies on those theories to accomplish what they do.
Here's a short FizzBuzz solution in Haskell. wiki.haskell.org/Fizzbuzz
`fizz` is a function that takes an integer and returns the appropriate response string for that integer. This is part of the logic module, since it's not really able to access external state nor does it have any explicit internal state. You have to explicitly pass it the value that you want.
`main` is the entry point `IO monad`. Since you can consider the `IO monads` that serve as the abstraction for IO, as part of the state module, it can go ahead and reach out to the outside world to print information, while also being able to use functions in the logic module.
tl;dr: Logic modules -> pure functions; State modules -> monads and other abstractions
@@ethashamuddinmohammed1255 The main reason for monads is 'returning an error' from a function, which wouldn't otherwise be possible without side effects. Let's say you have a:: Int -> Int, b:: Int -> Int and you call b . a, but there is a possibility that a returns an error, so you change the declarations to a:: Int -> Maybe Int, b:: Maybe Int -> Maybe Int, where Maybe is an example of a monad that either has a value of Int or is an 'error' - a value named Nothing - and it comes prepackaged with Haskell. Turns out this is convenient in general anytime you need to replicate exiting a function chain and even elsewhere. Maybe monad and the IO monad are the most used examples of a monad.
1:38 This sounds like some kind of hybrid of pure functional and imperative to me.
Truth be told the most important thing is the KISS (Keep It Simple Stupid) principle nothing is more important than that. When it comes down to it the only thing you truly want is to understand the code from others as fast as possible without thinking too much about it.
So if others read your code and understand it as fast as possible then you achieved KISS if not then you didn't.
The programming paradigms like OOP, procedural and so on are theoretically only trying to help you achieve KISS.
And how can you achieve KISS in a complex program? You need to use an enormous amount of time in the planning of the said program there is no good way around that.
Well at least this is my personal opionion :)
The issue is less how simply you archive a goal, but the sheer number of them. OOP philosophy encourages high abstraction, high encapsulation, high constrain .... it gives you much more goals than just delivering the feature requiring you to juggle a billion of made-up concerns which leads to complexity even with KISS.
I think this is a great refinement to the orignal video, as someone who would label themselves a OOP programmer, its the way I was 'raised' so to speak, I found myself resoundingly agreeing with this entire video. Its all about moderation, abstraction and ecapsualtion are absolutely useful concepts but can definitely be taken too far. I would like to think that no single paradigm is best, and that the best programmers are those that have a solid grasp of the basics of all paradigms and that the best languages/frameworks are the ones that allow us to use a healthy mix of all those concepts. I would like to think that modern programming, for the most part, is multi-paradigm
It would be nice to see what you call logic and state to make it easier to understand what you mean.
Your comparisson of imperative programming with OO does not make sense to people with a CS/OO background. You misunderstood the principles of OO, like encapsulation, inheritance, generics and functional programming (=programming with callbacks), design patterns, RAII, immutability, and how those principles would help with reducing code, design and algorithmic complexity (like minimizing cyclomatic and cognitive complexity), ensures thread-safe code and minimizes code-duplication. You seem to be stuck into the C/imperative thinking (try to re-invent the wheel yourself) and you use that to translate it to making it fitt into classes, like your invented "state modules and logic modules" But OO is not about C programming trying to fit into classes. A lot of people make that mistake though, as the comments make clear, so nobody to blame.
An example in C which I see a lot: supose a method called makeSound(), taking in a parameter that represents a pet, in which it could execute a switch-case or if-then-else and checking for the input parameter type. In C that would be a O(N) operation, in a OO language you would represent that differently with polymorphism which would be a O(1) operation (or better yet: generics, which changes the branching from run-time to compile time and still be O(1)).
An other example: how to implement loose coupling in C, where you would have 2 "modules" depending on each other. In principle, in C one could use function-pointers as callbacks to solve that. But reality C programmers don't think high-level and don't know about when to use it, so what I see is that people just use "singleton"-like spagetti constructs.
In an OO language, one would use the observer-pattern one way or the other (or event-driven programming like lambda's).
An other example is how state-machines are implemented by typically imperative/C programmers: if-then-elses and spagetti all over the place and O(N) solutions!
In an OO language one would use something like the state-pattern or derivatives and have O(1) execution. It would by definiton a lower cyclomatic complexity than the imperative method
To me, the first thing I imagined when you talked about splitting logic and function modules was actually functional programming. At a first glance the distinction between state and logic seems to map to the difference in Haskell between functions in the IO monad and any other function.
I had a hard time properly understanding what "state" and "logic" really meant, in essence. Until he called them "data" and "actions", which is when it clicked, for me. The reason is because OOP made me confuse things, because an object inherently by design had both data and actions, and the data and actions are tightly coupled.
It's really refreshing to see someone explain why OOP is bad and how OOP could be good (in a more recent video than this one), because I kept saying for at least half a decade that OOP is not a good programming paradigm in the way it is being taught, used, and advertised, but I couldn't quite externalize the exact problems it has.
More of these videos, please
What are your thoughts on Entity Component System (ECS)?
His argument that OOP splits stuff not when it gets to big but preemptively I feel is slightly off. With OOP stuff is split based on context. Not that there isn't a problem with this ofcourse as it truelly depends on how indepth you want to define the context. As an example lets take the classic car example. How far will you go. You can seperate it into the body, the engine, the drive shaft, gearbox, tires, etc. But lets look at the tires (mainly cause they are simple and im not a car person). You can define these as 1 single object which defines its properties based on a couple of variables and provides some calculations methods. Should be fine for anything other then indepth realistic physics simulation. However if you really want to split the atom and get to the quarks you can say, "well yes but the tire has the bokts and then the tire, and the thing that the tire is arround, and then the thing that makes the tire look nice" (I told you not a car person). You could split all these things up into smaller sub classes and further abstract everything out. However at this part you have to look at about 6 classes just to get the entire picture while when written as one it can be completely representend in one class. However on the other side if you dont abstract the car you end up with a file thats thousands of lines long and that makes it difficult to just look at 1 part of it.
This exactly. The problem with writing one module that contains 1000s of lines of code to cover everything for the tire is when reusing that module elsewhere, every car gets the exact same tire assembly, unless the copy of the module is changed internally, which now introduces more problems with code maintenance because several modules will be very similar with slight changes. The problem is not with OOP; the problem is with people creating spaghetti code whether using OOP, Procedural programming, or any other code paradigm.
@@jajwarehouse1 yes if you have a massive class with several different ways of behaving, means you have a lot if statements and it becomes hard to follow one path. On the otherside if you abstract too much you have too many sub clases and it becomes difficult to see the entire logic as all the parts are in different places and you almost need to have 7 classes open in different windows.
@@pigboiii It's almost as if the solution to bad code is learning to program better ;)
OOP creates the need for a bunch of shitty design patterns that are just not needed if another paradigm is favored. Yes that other paradigm will require different abstractions that do constitute in a way design patterns themselves but its just not the same.
A great complement to your "OOP sucks" videos! So may I summarise the argument here as that (a) a well designed and appropriate level of modularity is an essential strategy to control and comprehend all complex computational systems, (b) concentrating on artfully defining good stable data types and abstractions (ie *what* is being shared between modules) is usually far more important in writing modular code than concentrating on defining module interfaces (ie. what the modules actually *do* to the data), and that (c) most of the problems with object oriented programming that you were referring to in your earlier videos were related to OOAD's propensity of taking patterns which may sometimes be useful to control complexity at high levels of scale, and rigidly (dogmatically) applying them in situations where they unnecessarily *add* complexity.
Or, more poetically perhaps: coding complex systems is an art, and modularity is its paintbrush...
I believe you are against abstraction and prefer concrete code and don't like reusable code as it can be re-used incorrectly all your arguments just point to bad design, implementation or incompatibilities brought about by the constant need for software changes nothing to do with OOP.
Although I don't agree with everything you say, I'm quite intrigued with your monologues.
I'd love to see a debate between you and Huw Collingborne, the Smalltalk guy. Not an argument, just a pro/con discussion about OOP following proper debate rules. Your opinions tend to be polar opposites, even concerning which came first, the object-oriented hen or the procedural egg. It could be quite the event, especially if you did it live. You'd have all us nerds on the edges of our seats. 🙃
This is getting at the same points as “boundaries” by Gary Bernhardt
What!?!?
I just don't know what to believe anymore :(
Stop believing. Think.
I'd really want to see you collaborate with Johnathan Blow on the language he is working on.
100% agreed. What irritates me about OOD is that is feasable by it's proponents to predict future cases and all possible scenarios and this is IMO pure arrogance. When you start using keywords like "public" and "private" is like you are saying that you know what somebody should access/call and what not in every possible scenarios present and future and since nobody is omniscient many people will be pissed of by your choices of limitating access to some parts of the code.
Exactly this. One man's idea of pure design is the next man's roadblock when changing the design. In many cases source code cannot be modified, so you are at the complete mercy of the designer. Countless times I've had to *rewrite* existing code just so I could gain access to hidden data I needed. Simplicity should not be confused with stupification and distrust.
This is something I had always had to argue with my team lead, what to keep private and what to keep public. I mean in your own microservice what is even the point of public and private variables? May be my knowledge is limited and my experience is less, enforcing a certain "this is the way" is too damn arrogant.
It's not always impossible to know what users should and shouldn't be doing. You should assume they'll be following best practices for using your code.
I don’t think you got the inheritance part clear, it may encourage people to use inheritance just to “reuse data member declarations” forgetting all about LiskovSP. Let’s first separate public inheritance (the most common one, like Java) from private inheritance (what you exemplified with go). To put simply, public inheritance inherit data AND the interface, private inheritance inherit data WITHOUT changing the interface. Using the public when you actually needed the private is a mistake that many OO code does. If the language doesn’t support an equivalent private one (go embedding, private mixins or traits, etc), just use composition instead.
ThePrimeagen sent me, subbed!
This is truly great. Thank you.
I absolutely agree with this video! I have seen proprietary frameworks (in Java) with crazy chains of abstract classes and inheritance and NotImplementedExceptions to know that you cannot push OOP too much.
And yes, you still need “some” OOP ideas to split things up when they are “too big”.
Just like many comments below said, don’t let yourself stuck in a certain paradigm.
This is what have been serving me well:
1. A requirement usually can be split into a small number of sub cases, and this is where I think OOP would help a lot: let a component handle a sub case.
2. Within a component, use procedural programming, as it’s likely a list of actions you have to go through while keeping tab of your current state.
3. When an action is too big, then I write pure functions to deal with them. This also likely makes code in 2 looks like just going through a short and sweet bucket list
you can code good oop code and good functional style code... sadly 99% of coders dont know shit on how to cleanly code in any of them.. this is from 20years true experience in 7 languages including 4 multiparadigm one..
extensions method and generics can work very well with OOP for generic programming.. functional programming can often become unreadable.. even senior do it wrong..
you dont need to always use only inheritance in OO.. you can use composition etc.. and most inheritance is at the bottom of the layers and it's perfectly fine to use it there. Of course you need some extensions mechanisms like extensions methods in the language too..
dont listen to this guy who never really coded..
it's never one paradigm vs the other.. its one multiparadigm language versus the other.. language tackles problems as a whole.. this is why they should be compare as a whole... only idiots who never understood coding preach otherwise..
finally someone that gets it
^
This comment should have the most votes.
Hey Brian, I have to disagree with your assessment of OOP vs Procedural, I’ve found that you can often modularize by accretion in OOP by splitting as class gets too big.
However I think this may be a result of me adopting a hybrid approach of not following pure OOP design principles. Pure OOP usually ends up with people spending more time philosophically debating over objects rather than solving problems (as you described in your previous OOP is bad video)
I think there needs to be some balance in terms of how we program, pure OOP or pure Functional or pure procedural programming tend to be either damn near impossible or unwieldy. I find that there’s often a sweet spot somewhere in between and every project has a different spot. The real art in programming is finding that sweet spot.
A good programming language gives you the freedom to explore in search of that spot, and for all its flaws, I find that JavaScript seems to be one of the few languages that gives you something close to that freedom. Are there any other language that are like this that aren’t a hot mess?
I would like to say C++ but it's pretty much a hot mess. I mostly program in Java and I like to say that, despite it being pretty much completely OOP, if used correctly you can design your programs well, it's gonna be much cleaner than programs in C are most times. Code from bad programmers or beginners though is often horrible. Creating objects for every darn thing, sometimes there's loops where you could just re-use an obejct for calculations and instead they create a new one every time. Just to name an example. Sometimes I wish to have strucs t/ own data types besides objects in Java to make this even less of a problem, but I guess that defeats its purpose and is perhaps even not easily made possible. I've been eyeing C++ a lot because of this, but as I wrote in the beginning it seems mostly like a complete mess of missing or weird standards to me, so I'm reluctant to switch over for more than microprocessor programming. Besides my current projects being in Java and me likign to be able to reuse them of course.
Kotlin is my favorite language at the moment. It is very flexible to different programming paradigms and it is pleasure to write because the syntactic noise such semicolons and unnecessary brackets has been minimized.
In addition to Kotlin, which has been mentioned, Rust is another good one that gives you the freedom you mention.
Interesting video series. A lot of it is over my head but I'm beginning to grasp the differences between styles and what's dogma vs what's reality. When I compare what people say about programming against the quality of programs, I see abstraction as a stopgap for lack of competence or willpower, kind of like owning a car makes it less likely for people to walk or ride a bike even in situations where it would make sense. Maybe this is a result of the industry pushing for results prior to things being ready, and people have to take shortcuts as a result.
In the video game industry, I think of a game like Pokemon Blue/Red vs games of today. Games today can sometimes barely get past the damn title screen without some sort of bug, while people can literally build a working chatroom inside of the original Pokemon games and those suckers will just plow through every bug like they aren't even there. Bugs became features that sometimes made the game more fun and replayable, while today things often just break. If we're really abstracting and segregating or whatever the dogma is, I would think several pieces of the machine can break before the full program goes down, but most often that isn't the case.
The main question I ask is this: How much extra stuff should I have to learn/read for the sake of making my program more readable? I started my programming journey with Python, and when I try to read other people's programs, I often see imports for stuff even I could do, as a rookie, with a few lines of code. Instead, they import an entire module to accomplish a simple thing, which tells me they aren't actively considering the necessity of what they're doing, they're just pressing buttons in the right order to make the machine go, because that's what they were taught by other people who were taught the same thing by the last guy.
The two main problems with OOP are that it asks you to move run-time decisions into compile time, which requires endless re-factoring if you made the wrong design choice and/or the requirements change. The second one is that it forces you to make poor data layout decisions that are based on form over function. That can literally destroy performance in a few lines of purist code.
Computer science needs analytic metaphysics.
I would love to see a video about you make an application with oo, and with your concept, to see it in practice. I am very optimistic about your way of doing it.
Let’s call state modules “structs” and logic modules “interfaces”. And I think there should be a read only scope, such that you don’t need getter functions.
You’d basically get what you want in C if there was a special type of struct that only contained function pointers.
A struct with a function pointer is basically just OO design, without the OO security blanket that takes care of making sure the function pointers just point to the correct method...
There is a place for abstraction, just not most of the time that people use it.
@@asdfdfggfd just because something is an object doesn't mean you have an OOP design. Author doesn't think that objects are bad, he thinks that OOP is bad because it forces too complicated levels of abstraction that makes things hard to underestand and requires much more effort to write and mantain.
@@asdfdfggfdstructs with function pointers are a procedural design and always were a procedural design. OOP is defined by polymorphism and inheritance. You'll never see a struct with a function pointers in an object-oriented codebase.
I think the paradigm used should adapt to the problem at hand. So I kinda disagree with this, because there have been times when OO has served me beautifully, and times when it has not. I think your idea would suffer from that as well. From where I stand, I seems like it's ultimately situational. Any language which enforces a specific paradigm is also a language that restricts certain use, and makes performance compromises for style.
Basically just use C++.
Im trying to get into OOP and the picture you put of the empty box is how my head feels. In theory I very much get it and it's implied usefullness. But when i sit down and try it out my head feels so stretched and empty and a mess. I don't know where the hell the start but at the same time I do know where to start. But im in a state of overthinking it for what, im wasting time.
One of the most obnoxious things to me about C++ is how every time I need to use libraries and parts of the language I'm all not that familiar with, I end up having to jump all over the documentation at each line I code in order to write something I would be able to implement in plain C in 10 minutes, and as a bonus the initial code will often contain tons of runtime bugs because I wrongly assumed at some point a method's behavior based on its name or by analogy with similar classes. Alternatively, the language and libraries will accept code using a combination of advanced features, only to realize later on that the program is doing something else because some feature is not supported.
Yesterday for instance I discovered the hard way that STL containers so not support polymorphic pointers. or rather any polymorphic pointer stored in the container will lose any association with the derived class.
This kind of problems not only make programming a lot less fun, but also make you wonder what's the point of attempting so many features and such complex structure, if they later break down for so many non-trivial cases.
That you take a lot of time to understand the libraries of C++ is probably just because you're used to programming in C and know its libraries. I mean I have mostly no clue about libraries in C++ myself, but it's safely not harder to basic or even advanced stuff than in C. Could be wrong though.
C++, as a language itself, is pretty much a mess, I can agree with that. Sometimes I have the feeling that there's 10 ways of doing the same thing and that 7 of those have no reason to exist.
@Zamundaaa
My main issue is not whether I have learned the libraries enough or not, but rather that there are so many of them, and yet they are often not reliable enough.
After many years of programming, I have come to the conclusion that there is some irreducible complexity intrinsic to every task, and that you can ignore it or delegate it to some library at your own peril.
The moment, for instance, you introduce a new C++ algorithm class to substitute characters in a string, something that can be done in ONE line of code, is the moment you are polluting the language with useless garbage, while increasing the size of the documentation for no good reason. Now I suddenly have to look up what are the fail states of this new class-function, because there is no way I will remember them off the top of my head next time I'll have to use them, or how does it parse or deal with C-like terminated strings, return and linefeed characters, etc.
You basicaly traded one line of code for one documentation lookup, which takes at least 10-100 times longer to find, read and understand.
@@KilgoreTroutAsf yeah I can definitely understand that. Rather have a good library than a thousand bad ones. That's also a reason why I redo most minor stuff myself, at least in my own personal projects. Even with Java, where most stuff (that I came across) is done pretty well in the standard library. I got my own "Utils" project with some stuff missing from the standard library or where I don't need the full default implementation but rather a specific thing. It's pretty useful. Not necessarily too practical when you write software for others though.
Some really good ideas here, I've been thinking about similar things too. It feels like OOP is kind of a halfway house, some of the principles like polymorphism are great and some like inheritance can be positively bad, I've seen class hierarchies 10 levels deep, there's no way that is good design
Neither of those concepts are inherent to OOP
@@khatdubell They're literally 2 of the 3 pillars of OOP
@@n8style I'm sure you'd tell me encapsulation is the third.
Slap whoever taught you that.
You can have OOP without them.
I can give you examples of OOP languages without them.
@@khatdubell not sure what you think OOP is but am certainly curious about these OOP languages that apparently don't have any of the 3. If you mean you can write code that doesn't take advantage of the 3 in an OOP language that offers them then I'll be pointing and laughing just so you know lol
@@n8style No, i mean there are languages, widely accepted as OOP languages that don't have those features.
Simula, the grandaddy of them all didn't have any encapsulation i believe.
Visual Basic, if memory serves, doesn't have any inheritance.
There are a large amount of OOP languages out there, i'm not gonna go through an exhaustive list.
The point stands, there are many languages that are considered OOP that don't have what everyone considers to be absolute to the existence of OOP.
Its jus that modern OOP implement these things because they are, in general, good things and it doesn't make sense to exclude them.
How they came to be considered pillars, i have no idea. They're just good features every paradigm should use if they can.
You fundamental premise is pure functions and templates. I have the following points/questions:
You generally discount inter process communication. (Granted OOP does.)
Objects are all about shared dependencies and are to be consumed fundamentally. (This was the point of datatypes.)
Lot of combinational logic in theory, is this not impractical?
State modules are hell, they have never really been managed in OOP. (Something you have little interest in doing.)
Division of labor was why monolithic was shunned. (Poor planning in design and tasking is common in agile.)
Lot of people became a fan of iteration and see objects as patches.
Inheritance is bad practice and speculation in processor hates it. (Templates did not work beyond static and is also dangerous. CPUs hate space and 32/64 bit (4GB vs 16EB) have issue with it. When consider loops it gets so much worse.)
It conflates protocols as data. (IPC is bad, in many cases.)
Support cost is larger than hardware cost for most of the history of OOP. (We moved to client side because of this.)
Integration and optimization is generally discounted under OOP by design. (This same problem was observed in procedural code.)
Small code is reusable code. (This allowed APIs to exist. Procedures technically did this before, however in many case fell on the OS. Limiting cross platforms.)
Monolithic and singleton is going to lead to cost and premature optimization. (However this is a weak argument in general.)
Lot of people forget about the support cost. Its huge and it scales very badly. They tried to lower the performance to increase the performance. They only have so much productivity.
This idea is pretty similar to Redux and React, All the state is kept in stores, all the changes in state are applied by logic functions called reducers and action creators. and react just displays the UI based on the state
As a well meant advice: I'd recommend steering away from getting into react if you haven't used it much and/or have to work on a larger / complex project.
I've started working on a decently big project using react about 2 years ago. The idea behind it really is great performance-wise, but the way it requires you to declare state dependencies is terrible. It's depending on the developer to notify it of any possible change to dependencies of the visuals of the current element, which then invokes the reaction functions that had said dependency registered. If you provide an non-primitive as dependency, it won't detect changes to it's properties, so you might be scratching your head for a while asking yourself why the UI doesn't reflect the values you see in the debugger. With the callback shenanigans you'll see the current values in the debugger, but React didn't apply them to the DOM, as the object reference hasn't changed.
If you try to update the state inside a reaction method, you'll get a runtime-error, basically stating 'you can't do that'. In a situation where you only can determine that you need to update the state within in that method, you'll have to force a re-render, as you have to update the state outside of the reaction method first so the reaction callback can see the change. You basically add a react reference object with the only purpose being to trigger a redraw.
If that somehow triggers a loop, you'll get another runtime-error.
The way it handles the state will not allow you to easily debug it, with current values represented in the developer tools effectively always being out-of-date, so they created a complete react DOM explorer as a browser extension. Because it bloats up it's own virtual DOM so much, it's pretty hard to navigate, and it requires you to manually click on every state variable of an object to retrieve it's current value. The state variables don't even have names, because it doesn't provide a means for that. All state variables are simply saved in an array, where the order of occurrence determines their index. This also means that you're not allowed to increase or decrease the amount of state variables for an element.
it may see easily resolvable by just 'planning ahead', but development doesn't work that way, unless you have unlimited resources, and therefore can take your time to plan beforehand, read the complete documentation, experiment, etc.
I probably spent a lot more time debugging react-related issues instead of moving forward with programming.
I'm a programmer at heart, so i personally didn't mind it that much, but if my goal is programming speed, i'd rather use a mundane environment.
This gives me hope
Not a programmer but I keep on wondering. What is the difference between a class and a library? They are both black boxes you use, that you don't care how they do what they do, just that they do what you want them to do. Isn't the idea behind OOP to make such black boxes to organize your code in a clear way? How large these boxes actually are and how many functions are within and how many levels down you go depends on your choice when designing. If they don't fulfill their purpose of clarifying the code and obfuscate it with empty class diarrhea then change your design paradigms. As far as I know, there is nothing stopping you from having no more than 3 layers of abstraction which should prevent writing classes for the sake of code obfuscation (and should keep you within 3-4 mouse clicks away from any part of the code).
_What is the difference between a class and a library?_
A class is the blueprint for an object and describes attributes (What properties does an object/class have?) and methods (What can the object/class do?). e.g.: a car class. A library is a collection routines ususally to tackle a specific problem. e.g.: a library for trigonometry.
_They are both black boxes [...]. How large these boxes actually are [...] depends on your choice when designing._
Yes.
Class: blueprint to spawn objects.
Library: classes that you compile into .lib so other people can use them without having to write them.
The way I think of it is OOP is an expert friendly paradigm, and most people just aren't experts, so they'll end up using the power they get destructively by mistake (a.k.a. shooting themselves in the foot.) You inevitably need to decide how to group logic and data, which is a combinatorial problem, and most of the combinations are just bad. People who aren't strong conceptual thinkers (which is quite a rare trait) will inevitably stumble on some arbitrary design which by chance is almost always bad. Sometimes it's high coupling, which is reasonably easy to deal with (analogous to the accretion problem in the video), and sometimes it's low cohesion, which IMO is the real killer. One responsibility smeared across too many actors.
However. I do see expert friendly being equated with "bad" a lot. There seems to be some arrogance tied to that: "I tried it, and I wasn't immediately great at it, so it must be bad." Then starts the rationalization game of finding arguments for why it is categorically bad, but that often just comes out as a not-thorough-enough explanation.
Cache misses aren't expert friendly, even though OOP virtually guarantees them.
It's all dependent on your use case. These are all focused on enterprise and server programming from the looks of it. Get into games, and one'll see that a focus on state will reign supreme.
Games do have a lot more state, indeed. That's where this approach of minimizing state and isolating state changes and logic becomes even more useful. The use case is "you have state and need to do complex things based on that state, while keeping everything neatly organized".
Mike Acton, the guy who promoted Data Oriented Design, comes from the triple A games development industry, and is currently the technical lead of the Unity game engine, where he designed the Burst compiler based on this idea of grouping state changes together, separate from the actual objects. In the sense of complex programs that have a lot of state but still need to be fast, games are very much like enterprise and server programming. There is a book about how this idea is currently applied in high-end games: www.dataorienteddesign.com/dodbook/node2.html
I have seen people claim that even if OOP is not suited for regular applications, it is really good for GUI and game programming. The opposite is the case. The more state you have, and the more complex the mechanics, the more important it is to minimize accidental state and keep it away from the actual business logic, to be able to organize everything effectively.
Look at Brian's other videos. He specializes in games.
I'm happy that this validates how I've been coding a c lately. I'm in the process of re-writing an old piece of code and I'm pretty much following these conventions. But I got all of this just reading about opaque types and handles.
Who else is watching this in 1889BC?
Thank you! I just watched your OOP series, and really enjoyed it!
I strugled with the problems you mentioned, and reached a similar conclusion. If I got it right...
Let data be data!
Let functions be functions!
C++ allowed me to do that, and I often find myself writing:
- state-only classes, with no methods (=data modules)
- stateless classes, with only static pure functions* (=logic modules)
Of course, grouped in proper namespaces, translation units etc. and without abusing, i.e. use normal classes whenever it makes sense.
*stateless clases or namespaces depending on where I write that and who is reviewing
Sounds like C style. It is not. :)
Its fairly clear to me that people arguing whether OOP, functional etc. are better, are really arguing about whether a hammer is better than a screwdriver or a bunch of glue. The right tool for the job makes sense. GUI design using objects is a no-brainer. Mathematical modelling lends itself to functional far better.
I am 3 years late but maybe it still reaches someone: I find it hard to take actionable items out of this video. Are there books or examples which I can read to stitch everything together?
I had to wrangle a pile of "legacy" code recently and they must have had some dice with generic nouns and adjectives on it, and for every identifier they rolled it a few times. it was madness. couldn't tell head from tail on that beast. had to FIRST rename everything to foo/bar/baz, literally, so these things wouldn't sound so similar. once the misleading words were defanged, only THEN I could start seeing the structure that was there, and rename once more, to something that actually made sense..
Since I worked with ffmpeg i love oop and it's model.
The library that I'm using allows me to configure hundreds of fields and arrays for ffmpeg to work correctly. I have no idea what fields do what and which fields affect which. So I'm blindly setting fields and hope for the best.
A simple encapsulated Api would help me a lot here.
Object orientation doesn't save you from poorly written standards. If anything it allows architects to write even worse ones.
Interesting observations. I tend to agree.
What do you think abot Entity Component System and Composition Over Inheritance? It seems like ECS is a good representation of what you say, with entities and components being "state modules" and "systems" being "logic" modules.
where it makes sense, as always, so not everywhere ))
ECS is a situation where you distribute an array (open product) of entities (open sums) into an open product (an array of components) of open sums (enumerations of components), much like how you can distribute addition over multiplication. You can reconstitute your entities by looking at the entity ID component.
This is the most principled under FP where you can talk about a collection of existential/sparse types which may or may not have a component.
Object orientated programming is alot of over abstracted bollocks.
This kinda feels like what purely functional programming encourages. It requires you to opt-in into state and so you cannot accidentally mix up state and logic!
(simply because execution and time aren't built into the language - you import that from the standard library if you need it and then model it explicitly)
And since the way FP does polymorphism (generics, interfaces) is inherently more precise then these taxonomies of classes that OO proposes, your abstractions are usually clear-cut, obey concrete rules and are just way more predictable in behavior.
Finally, since in pure FP everything is an expression, everything composes without an issue.
(also, boilerplate can be just abstracted away!)
This video exactly matches my experiences.
I've never worked on a project where the initial concepts remained intact through the end. Often, the initial concepts weren't just heavily modified, they were actually _wrong,_ and we had to recreate them from scratch after we're experienced getting some parts actually running, sometimes more than once. If our initial assumptions were always right, 95% of our jobs would disappear.
OOP purports to be easily restructured, but in real world large projects, it's not, exactly because of the initial _speculation_ OOP requires as Brian noted. I've seen OOP projects end up with _all_ the upper-level modules to be nothing but layers of misleadingly-named empty shells over other such empty shells, with nothing but spaghetti-like mess of templates/classes at the bottom each doing random fractions of what should be integral project operations. Once projects become both large and mature, prescribing OOP for everything transitions from a life-preserver to an anchor.
OOP vs. procedural isn't good vs. evil. Yes, pure procedural is like building a house by starting with the outside walls, and leaving everything inside to be decided by later by individual workers with whatever skill and materials they have at the moment. But pure OOP is like building all the walls you might need in the house all at the start, before the buyer for the house is known. Neither way is very good., but a considered combination of these works well. As Brian stated, do OOP where you know a module will remain long-term, because its dividing lines are predetermined in some way, such as separate departmental responsibilities, utilizing different hardware, external regulations, public APIs, separate external customers, etc.
Programming requires experience, intelligence, and skill, not some simplistic dogma that cares nothing for your real world evolving situations. OOP isn't a religion to be adhered to by blind faith, it's a useful tool. Use it where it's useful, not presuppose that everything will be a nail for your one-and-only OOP hammer.
The philosophy about interfaces and data types presented in the end seems similar to the philosophy best supported by Rust
Huh, that's interesting, because there's one part of a library that I have where there's code that does some dangerous stuff if it's not handled properly, so I made an abstraction on top of it so I don't have to worry about handling those special cases when I need to use the underlying functions elsewhere.
This appears to all be written from personal experience (this and the previous video). My experience has been completely different, with bad experiences with functional and procedural code and some good and bad experiences with OOP. There's great deal of language like "usually", "sometimes", "often" without any clear cut examples or comparisons. I would like to know some samples Mr. Will is basing his assumptions and opinions on.
I think it's over-engineered "enterprise"Java