You dont know OOP 

Yeah, just like capitalism, communism, science, and religion.

Perhaps it has; but only in some remote closed commune, requiring unexpected levels of commitment... The legend of SmallTalk.

Actually, I hear SmallTalk is awesome. It's typically used in its own special fully-modifiable programming environment.

With an actor framework like proto actor you have actor objects that can send signals to each other. Feels like the original definition

No the problem is new programmers are not taught what is the architectural reason/goal for OOP. I have seen people still use OOP as if a tool for reusable code. Knowing what should and should not be reused is the first lesson in knowing why OOP even came about. If people knew why the reason would become obvious.. But mostly OOP is described in obscure definitions of encapsulation/ design patterns. OOP is simply a mechanism to aid in achieving the reason for its conventionalization.

You forgot to mention the kinds of birds that can’t fly: kiwi, penguin, ostrich, and dead

@@airkami on top of birds what can't fly, how about an abstraction that accounts for birds that only fly three feet, like chickens? I mean they don't really fly-fly, but they can get off the ground, right? It gets absurd after a while because to create the abstraction "correctly" means you have foresight to account for everything in existence, or everything that can happen in advance. I dare say that even in biology that can't happen as we make discoveries. We need to account for the unknown somehow? Dunno, just asking.

16:21

@@firen777 not all hero's have capes

which means you're not one of the hero@@firen777

"not all heroes have capes" does not mean "no heroes have capes" @@pinkzero281

​@@pinkzero281quite literally everyone here is a hero exept you.

what if we are talking about a duck toy?

@@davidlaraezm duck toy != a duck ;)

That's why you should figure out and organise your data structure before actually implementing it in code, huh

​@@helgenlane I don't know if that was deliberate, but you just summarized why inheritance hierarchies always end up sucking ass in real projects. In most projects, nobody can predict what the appropriate OOP-correct data structure will be because it changes over the course of the project, and adjusting those inheritance hierarchies to fit after thousands of lines of code have been written using them can be awful. That's less of an issue with a model that relies more on composition and traits/interfaces, keeps things more flexible even when stuff changes.

I think most people get too caught up in one way being the right way, rather than being able to know when to use one or the other.

​@@thederpykrafterikr. But where's the fun in that? Even with strict design patterns, knowing when to break the rules is critical. In clojure, there's side effects. Even though it's functional. Globals and Singletons are bad, but sometimes they are the best solution. Why? Because in the real world we deal with these problems. Purity is impossible. The science is knowing the correct thing to do. The art is knowing when to do the incorrect thing.

I will create an object with no real world significance with a load of methods with no persistent state, while totally deriding functional programmers. I will also crate an object with all the data in it, which I will call either O or wOrLD and pass he bloody thing everywhere.

@@TheLucanicLord that sounds painful 😂😂 I call it Context

@@thederpykrafterYES! This! These are tools to help you complete different tasks. Don't be too wedded to one paradigm or another. Learn as much as you can about all of them, and use the correct "tool" for the job(s).

Not only does it almost never get used, the "taking control" almost always requires adaptation in the client code anyway, at least long term, or you will just slowly create spaghetti. (taking control almost always means increasing the amount of responsibilities the class has)

I've used setters sparringly, but I do use getters a lot, especially for things that Prime showed.. If my class has lists, and I want to get the total from those lists I consider that those lists are properties themselves, length of those lists are in extension also properties of those properties, so a "public int TotalRecords {get { return list1.Count + list2.Count;}}" makes perfect sense. This is still a "method" with additional contextual information making it clear as day to anyone what this Property contains and that it's read only. There's literally no purpose for something like this be it's own function. I believe that functions/methods should contain some kind of operation on the data that isn't exclusively reading, while getters are perfect for those situations. Another use case is when writing object models for parsing json. Client maybe has cardinal directions as words ("up","down","left","right"), but for coding purposes it'd be more helpful to have this as an enum, so public Directions CardinalDirection {get { switch...case..."up": return Directions.Up;}}. With this approach my object importing is a lot simpler and I have immediate access to properties I need in the format I need them.

i dont entirely agree with that. sometimes, and for simple things, getters and setters are an east interface to connect two components when one has a very simple value that is only used in order to update anohter component, and also needed for other states. not everywhere, but useful. for example, a Unit's HP

This is why objects which are likely to require this type of control should use getters/setters but most should not. If your base class requires this type of control, use them. If it does not, don't. Then if needed, create special cases in the derived. Which will likely only be used in the special case derived, likely implying it should be private anyways. Which means the special case may well be hidden within the specialized derived implementation. Which brings us full circle that for the vast majority of cases, getter/setters should be avoided unless it's a requirement of the base. Contrary to one of the of gallery comments, composition does not avoid some of these complexity or issues in any way. It simply changes the surface area where it does. I'm honestly shocked so many people lack such a fundamental background on OOP yet are willing to rally against it.

I really like getters in C#. In other languages, usually I find necessary to write methods like len() to access read-only fields which is a little annoying.

it does not say anything about data. It only states, that a base thing defines an assumption and that every child thing of that base thing must follow that assumption. Collections are a great example. Every collection is iterable, but pretty much all of them have different internal implementations. But, again, they all hold an assumption: a collection is a thing, that represents sets of things, might be empty, and you can access thins in the set one by one. It might be a continuous block of memory, a linked list of block of memory, a hash map, a file, a network socket, even a generative corotine, that spits stuff when asked.

Liskov was high on drugs There is no such thing as a bird. There are things with feathers, things that can fly, and things that tweet Traits/interfaces trump strict object definitions And duck typing with compile time checks trumps traits Java < Go < Rust < Zig

​@@steveoc64I disagree with that last part. Explicitly mentioned interfaces are better. Then again, I'm also against the "typeclass" mechanism, where the compiler finds the right implementation. Even *that* is too implicit for me.

"In other words, all subclasses must contain all data from their superclass." can you explain why??

@@steveoc64duck typing with compile time checks: Python 🐍 with pre-commit strict type checking. 😂😂😂

Exactly! It is a design principle that is valid where ever functional variance can be implemented. It also applies to non-OO languages like c when they provide dynamical behavioral variance.

Are you saying that the Liskov substitution principle is equivalent to pure functions?

@@etodemerzel2627 No. Pure functions do qualify, but Liskov's does not prohibit side effects, only that those side effects adhere to the interface. The example was of idempotence (which does not require purity), but another example could be an implementation that terminates the application; unless the interface permits that, such an implementation could exhibit undefined behavior (e.g. files left behind, or perhaps the termination function itself has been overwritten in memory, so instead of termination, some other behavior is triggered [not likely in modern languages, but Liskov's applies to assembly too, where self modification isn't that uncommon historically]). The principle is about the expectations / specifications of the interface, and reaches further than just the type information we can declare in modern languages.

wouldn't a watcher do the same thing?

Their real benefit shines when using reflection features. That's the main reason of their existence instead of a mere method. They have no reason to exist in languages devoided of reflection capabilities.

@@defeqel6537 It would

@@kirkanos771 I call them vampire languages

@@jacksonlevine9236 ironically, they are less vampiric when not having those features. As the main purpose of those libraries is to vampirize the code at runtime.

Me: Smalltalk.

Found the scala dev

@@gagagero Chad

@@colemanroberts1102 Kotlin, but Scala is fun too. (Actually a java dev though professionally. Java+Lombok+Manifold can get quite close to Kotlin though)

Crazy how long the discourse between paradigms has been going on when it's so obvious that 1. it's almost always domain/implementation dependent and 2. a combination of everything is almost always the best. Procedural by default with OOP concepts for managing data/custom data types and FP concepts for managing logic and control flow, and 1-2(max) layers of declarative functions wherever is practical with the rest prioritizing an imperative style. Extension traits and composition over inheritance every time for the OOP side and you're golden. Just need a good, *un-bloated* language with a best-in-class type-system (never used but I only hear great things about Hindley-Milner) that isn't trying to be a one-trick for once and devpression would plummet.

meh. In college, I never wrote any code to model AST nodes. After college, I found that a class hierarchy was the most natural way to do it I could find. Is it the best? I don't know. But it seems to work better for me than anything else I've seen. Skill issue? Maybe.

My college taught c++

"Mutable objects with message passing." Thank you for coming to my SmallTalk. (FP bro take btw)

The main keyword here being "hope"

If the system you are modeling contains hierarchical relationships (most do), then you are not being faithful to this definition by avoiding inheritance for the sake of avoiding inheritance.

@@user-gq2bv6dm9s Actually, nothing prevents you from building different objects with their own methods and fields, without inheritance. Taxonomy does not exist in the real world, and eagle, tit, and thrush are not inherited from birds, but unique things that have their own feathering, beak, and wings and they fly and feed in their own way. This is if we are extra-meticulous to the words in the definition. If not - we can rely on common sense and abstract out some stuff (aka methods) so far this does not interfere with us building the system.

@@user-gq2bv6dm9s But in general, I cited this definition (from the MIT 6.001 SiCP) as an example of a fairly complete, but at the same time absolutely understandable definition of OOP, which is not overloaded with unnecessary details and restrictions. Like those that “if there are no classes, then it’s not OOP”, or “if there’s no encapsulation, then it’s not OOP” and the like. The OOP can be implemented in pure C, and it will quite be "Object Oriented" Programming, it simply will not fall under some definitions that are widely used as dogmas or axioms - although for some reason no one ever says when and why they became dogmas and axioms.

CLOS oop*

@@Oi-mj6dv What do you mean?

LSP is about more than just the interface, it's about behavior too. e.g. a subclass suddenly calling exit(-1), throwing an exception, etc. It's also about parts of the interface that we usually don't have explicit types for, e.g. if the interface specifies that a function returns integer values between 1 and 10, then a subclass might return values between 2 and 9, but not between 2 and 11. We usually don't have have a specific Int1_10 -type, but rather just int / i32 / etc, but the constraint still applies. But yeah, Prime is aware of the SOLID principles, but does not seem to understand them

The problem I have with the LSP is that the only way to satisfy it for any nontrivial situation is to not use inheritance at all. Any nontrivial use of inheritance will break properties provable about the parent class, _that's why we use it._ But I agree with your overall claim.

@@isodoubIet I have used inheritance extensively in my codebases over the years and don't find that to be true. I start with a base class representing some over-arching general entity in my domain, like an Item class in an RPG, then subclass multiple levels as necessary, like Weapon / Consumable, and have functions that take in any x of type Item, meaning that both Weapons and Consumables are passable as per the LSP. Could you elaborate on an example?

​@@user-gq2bv6dm9sI agree and I don't really know what that guy is talking about. But there are some situations when inheritance leads to weird solutions when an object must have properties that belong to two different types. Example: a car can have value and weight of type Item and hitpoints of type Entity. Which forces us to create carItem and carEntity which are later referenced by car object. It's not such a big issue, but can lead to confusing code, I guess.

​@@user-gq2bv6dm9sI agree and I don't really know what that guy is talking about. But there are some situations when inheritance leads to weird solutions when an object must have properties that belong to two different types. Example: a car can have value and weight of type Item and hitpoints of type Entity. Which forces us to create carItem and carEntity which are later referenced by car object. It's not such a big issue, but can lead to confusing code, I guess.

Like my coffee like my women 👩🏿

@@Jabberwockybird Ground coarsely and dipped in boiling water?

@@Jabberwockybird roasted from greens using a portable heat gun and a frying pan, then ground and drawn through a glass syphon ? Yeah Boi

I'd say cycle off caffeine for a few days every couple of weeks. That way you don't get addicted, and it works more effectively.

@@andybrice2711 100 mg of caffeine, i.e., around just under 250 mL (1 cup) is all ya need in a single day. The hard part is keeping it limited to a single cup.

Yeah, the syntax argument is silly. You can also write Object Oriented code in Odin as well, it just doesn't have any specific syntax for it.

What do you name a function that takes two things? Car_road_drive? Road_car_drive? Both? The power of typing "car." and getting a list of functions that are available is specifically what he referring to.

@@amoskevitz first thing (argument) is treated as object on wich methods are called on other languages

Based take.

ccp mentioned

That sounds like poor planning. 99% of the time it's predictable.

C++ is kind of trying to phase out inheritance. Its still there, but programmers have been coding complex problems for the last 20 years and we know inheritance is bad (for non-gui stuff).

@@complexity5545 yeah the langauge proposal lead by bjarne stroustrup if I remember correctly, he wanted it to land in C++0x/11 but it didn't happen because of radical change in language. I am glad its here though, I absolutely hated the previous errors lead by templated code (its still here but concepts. are better)

To be blunt, that isn't an OOP issue but a skill issue. You are using inheritance wrong if you run into such a situation. It is a sign that you need to rethink how you are doing things.

I'm confused virtual methods are the ones which are able to be overwritten in the inheritance so why are you run into problems with it ?

The biggest problem with OOP is that it is usually taught wrong. If they teach you inheritance as one of the major things to know, they are doing you a disservice. I agree with most things in this video. If you need to hold data and pass data around: use records (structs). Think about making the fields readonly. If you need to connect more distant parts of your code: use Interfaces that define behavior. If you have a thing that has internal state and some exposed behavior: use an object with public methods and private fields. Objects can implement one or more interfaces. Interfaces can extend other interfaces. Base classes and virtual methods are almost never used. Only in some cases and only within a single module. Never make public Base Classes. Use Interfaces. -- The way C++ "invented" OOP in the beginning was a big hack to make message passing work relatively fast with the technology of the time. That way of programming stuck around for to long. Now C++ is much better, but habits die hard.

@@evancombs5159No. sometimes it’s best for the „code to do what the code needs to do“. OOP often feels like translating simple things into a completely different and very static way.

Strictly speaking you are right but C# simplify and hides getter and setter and reduce it to 1 liner so you need only change {get;set;} to {get;}. Actually encapsulation only makes sense when others work on your code or at least works as bridge like a public API or sever -client communication.

personally, a great example of getters and setters. is one, you want read only access from the outside only. but internally allow it to change for getters and for setters, maybe the data being inserted alterted must meet some requirements that cant be statically typed checked. so you have the setter do the checking there

You should not use inheritance to model everything because not everything in real life is hierarchical. Some things are compositional, and you should use composition to model them. But many things in real life are hierarchical, and it is awkward to avoid using inheritance in those scenarios.

manually rebuilding inheritance tree over and over with ad hoc nodes that make no sense

@@user-gq2bv6dm9s Exactly. Some domains inherently lean into inheritance. Some into composition. Some into neither. The failure isn't OOP or composition or functional or whatever. It's the designer. The right tool is always the right tool. The trick is knowing when to use the right tool.

Awesome perspective

This reality which a lot of software engineers like you @uumlau paint is a compelling one. However, it's due to the abuse of inheritance and not inheritance itself. I recently believe that there's nothing wrong with inheritance as a tool for code reuse. Yet, there's everything wrong with how inheritance is used and implemented in most codebases around the world. Inheritance hierarchies should be built bottom-to-top and not top-to-bottom. All of the problems and issues people experience with inheritance has to do with software engineers building the hierarchies from top-to-bottom. Issues like tight coupling, deep levels of inherited classes. Most examples of inheritance innocently suggest you should create the parent class(es) first. This is wrong! When using inheritance create your sub class(es) first and build the hierarchy from the bottom (subclass) to the top (parent class). For instance, why do i need to create a Shape class before i create a Circle class OR Why do i need to create a Bird class before i create an Ostrich class ? Why ? There's no reason. Even the Java Standard Library got this wrong! And now for years and decades, we have carried on like this. Doing the wrong thing and expecting things to be fine and when they're not fine, we blame to tool. We blame inheritance for all the bad things that we encounter. When we should blame our ways and methods of using inheritance. Most of the nagging issues around Inheritance disappear when we build from bottom-to-top. We even discover that most of our parent classes become Abstract classes as opposed to concrete classes when we use inheritance properly. I know this because i have applied it to my work and seen better results. Read more here (in my article): isocroft.medium.com/the-growing-spate-of-ill-subjectivity-and-presentism-about-software-engineering-practices-c74c6bf34cad

why?

@@ayoubelhioui2205Because it violates encapsulation. Whenever my users want me to show more than an empty screen, I tell them that it is not possible because I cannot expose the internal state of my objects to them. There are many bad getters and setters and there are many good getters and setters and there are many bad developers and only a few good developers.

​@@ayoubelhioui2205 because if you manipulate those objects from a services for example you are just doing procedural code.

I see you know your clean architecture well

@@RoyRope As my team lead said 8 years ago, I get paid to think, and in order to think you need to know things well.

i actually like Kotlin's getter and setter for all object property assignment and referencing but I think there has to be a better syntax to whatever Kotlin is delivering

Tbf, Composition should replace it as a Pillar. Then again, the four pillars most people consider OOP, well not all are…exclusive to OOP. Namely Encapsulation or Polymorphism.

True Its more (actually, all) about interface (contract) inheritance, not about actual code inheritance

I agree. But to give context: in the early days of OO like the 1980s and 90s, interfaces were mostly classes and not defined as an abstraction of its own. So, there were different methodology types of inheritance: type inheritance, interface inheritance and actually interface implementation. Bc the latter was only deriving from an interface and implement the behavior. Also, in the beginning type inheritance was much more praised. With experience "good" OO principles were defined. This is where LSP and Gang of Four come from. Nevertheless, inheritance is a pillar of oop. It is only not to mistakenly used where a has-a relationship is the better option. And that is often the case. A guiding principle is to think of if the relationship is static or dynamic.

I agree too. I already did another reply like this, but my point was, when you leave inheritance away, OOP no longer conflicts with functional programming too. Somebody mentioned that OOP is actually more opposite too procedural than to imperative. This is at least correct for the concept of methods. Languages like Rust still use methods, which add behaviour, logic to data types, effectively turning those into objects. Polymorphism in functional programming languages is achieved via type variants, discrimated unions, like the enums in Rust. Generics are also used. And extension methods like C# has also count here, because these are often applied to interfaces, and are even used as a system of higher order functions known as LINQ.

​@@twenty-fifth420There are cases where inheritance is the superior option. I just don't trust myself or others to know when that is the case, because if it isn't then you're going to hate life.

I hate this in C# too. I just don’t get the point of properties. It really confuses beginners in programming.

You'll understand too once you've reached Lisp enlightenment.

@@freesoftwareextremist8119 I have and knowing that closures are a poor man's objects & objects are a poor man's closures, SBCL is one of my best tools in my toolbox alongside NeoVim :)

​@freesoftwareextremist8119 ALL HAIL THE CLOS

I guess it works until you have to duct tape the object graph. While it's pretty shallow it's all sunshine and rainbows.

What if I wanted to have something that's both a ListBox and an EditBox?

Two levels deep is manageable. Ten levels though... I guess people are just burned out on way too big inheritance chains so they decided to just throw the entire concept out the window.

What if you have a control that needs to behave like both a listbox and a scrollbar?

one does not need inheritance for that. in low-level languages like C, just cast a pointer of several types to a common type, that has same field offsets and sizes as the common part. it's also possible to do composition or exclusive unions.

It's probably because they try to clean their functions and make them as pure as possible.

Yes and unicorns are the best horses… btw Linus would like to have an f word with you

Erlang is an object oriented language

I found a code sample from the olden days. It was chipped into my stone tablet. Encapsulation and information hiding is for low trust societies. C programmers have no need for such things. We can also hold the entire program in our heads, so we don't need no stinkin' type safety either. It's void pointers all the way down baby. typedef struct { SCREEN_OBJECT_T so; int item_count, item_selected, top_item, display_count; void** sub_list; void (_far* DisplayItem)(); void (_far* OnChange)(); void (_far * OnScroll)(); } LISTBOX_T;

This is the way.

if everything is getters and setters you have too many. if nothing has getters and setters; you have a struct with functions. the big thing is "if it needs to be validated it should have a setter" "if the member should never be written to externally it should have a getter" Getters and Setters are just special function overrides for the =operator on the member.

There 2 ways you can write in OOP state and stateless . In one you get only operation results as object never manipulate the object itself and you are per default thread-safe but you have the cost of memory allocation like in FP. In the other you run often in getter/setter scenarios which is better for speed and memory optimization but also you have sometimes not all information all at once in this case it is from FP perspective like a closure. In general OOP is just making a list of your functions and variables under a name which doesn't oppose FP . Its more like the question of if you like your stuff messy or ordered but yes there is also stuff where OOP doesn't help like when you working internal data streams where everything is just logic . There FP is more helping hand when you are able to write in it.

Glorified buckets of data is where is at

so real

Not a game dev but we do the same for industrial automation and R&D. We use inheritance to handle most of the nitty gritty stuff, so that we only worry about project specifics. This also means that of someone goes off rails and builds something without documentation we at least know where to start reading and we can reconstruct the spec.

How is this different to passing an implementation of a "game loop interface" to a "game runner"? (As opposed to using inheritance) Not to say that that's an argument against inheritance (at least by itself) but one of the biggest issues with OOP is not being able to consider other options than inheritance.

@@SimonBuchanNz you use inheritance when you want to implement something in the parent class, if you only have to define a "type" just use an interface.

@@fludeo1307 I literally don't understand what you mean. That inheritance means you can call parent class methods? Sure, or you can pass in "this" to the interface, or you can not use a class and use free functions for common behavior, or whatever other features your language supports (eg Rust extension traits, Java/C# interface method defaults, ...)

​@@SimonBuchanNz inheritance means you literally inherit behavior, data, and structure. if you pass "this" to the interface you still have to implement the method on the "child class", so you have the same code everywhere. Implementing the method in the parent class would save you writing the same method over and over.

Yeah - it can be abused. We've all seen code that abuses OOP principles more as a cock-measuring contest "ooh... Look how leet my OOP skills are" that result in a confusing and over-complex mess.

You wouldn’t make a new trait that requires other traits. You would write functions that expect some type that implements exactly what you need to use in that function

Hmm I wonder why code is easier to write from scratch then refactor when you made it hard to refactor 🤔

@@arch126 To me, re-factoring non-trivial code requires getting into the mind of the person that wrote their code and understanding their style. I have been successful over the years in doing that - sometimes you know which colleague wrote a piece of code. However, it's often just too damn difficult, or too damn time-consuming. So it gets junked and re-written. I'm not saying it's the correct thing to do - I'm just saying that it happens.

I have seen multiple thumbnails/clips/titles from him dismissing OOP, only to find that he does not even know what liskov substitution is... Not a cool use of his influence in the programming space.

The thing with communism is that no one is able to do it correctly. With Liskov substitution principle, a fucking word calculator is able to come up with idea that works.

Same goes for capitalism.

​@@Rockyzach88No, capitalism doesn't work even when you *do* do it right. See: current state of the world.

In theory, communism works. In theory. - Homer Simpson

Yeah I mean look at all these modern communist inventions like electricity, digital computers, combustion engines, HVAC. Just imagine if the world was capitalist, we'd all be starving in a Holodomor @@NXTangl