Object-Oriented Programming is Good*

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.

The separation of state and logic is pretty much monads and functions in FP. It seems to me like any disertation of good "OO" just always devolves into FP. But the issue with procedural you dont address is that you often end up with anemic code - large reuses of value objects that cause widespread typing dependencies. Thats where FP solves the issue with widespread polymorphism.

Sounds great but if you're writing for platforms like iOS or Android you're choice is made for you.

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

Uhh thats cool and all but we asked how you felt about Oops all berries! Captain crunch cereal sir ...

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.

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.

Unfortunately, the first video didn't do a good enough job of defining what makes OOP code OOP and separating the language constructs from the paradigm philosophies. The recipe in this one speaks for itself though. An excellent take.

ThePrimeagen sent me, subbed!

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.

My first OOP was AutoCAD's AutoLisp.

Now I live in various microcontroller Assembly. Languages, like Atmel, Intel 8051, and remarkably RCA 1802 COSMAC.

C# looks like Java looks like Ruby looks like Yo mama looks like Python; if you have done it as long as I have.

Alan Turing was right.

Bro, your takes on OOP are so fucking retarded, and this is no different.

More of these videos, please

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.

bro fr switched sides!!

I just think about designing a giant ui without a diagram; do not want. OOP, or at the very least OOP thinking/methodology, simplifies that process. Yet, just like an over engineered DB, if you break everything down into its smallest possible elements you over complicate and overburden the system, not to mention the poor coder.

This sounds good, but anyone else having trouble grasping how to apply the concept of logic vs state modules properly in an application using an OOP oriented language? If logic modules can't reach out for state, how would I mutate state based on logic? Is it as simple as passing a copy of that object to a function inside a logic module, mutate its state, and return the mutated object? If a object has a function that modifies its internal state (trivially lets say a hashmap, with functions to lookup/add/remove items), is that following the pattern outlined here? Or am I supposed to pass a copy of the states somewhere else to do that mutation? I agree with the notion that most application code is logic, but its mostly logic that mutates state, so what is the proper technique to cross that line from logic => state mutation?

Your videos are very delightful and useful. They teach properties, problems and philosophies rather than merely recipes(also they go straight to the point).

The paradigm I follow for 20 years now is "results oriented programming". Do whatever leads you to the quickest result while delivering short and readable code. Don't over engineer. Every line of code introduces potential bugs and needs to be read, understood and maintained by some poor guy in the future (...you in 7 years)

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

The biggest question and doubt I have is, why do we consider, that splitting data and logic is good? (I don't argue that it is, just there is no arument for that in the video and it's taken as a fact that almost everything then builds upon)

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?

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.

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.

The comments about Logic Modules seem correct.
The comments about State Modules is not as good. Phrases like "limiting surface area" are quite poor since this only refers to a general concept of encapsulation and data hiding. He still doesn't seem to understand inheritance. His notion of a public interface is also woefully limited.
He is correct that the abstractions in OOP are of limited utility.

Brian I think you would like Rust

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

The philosophy about interfaces and data types presented in the end seems similar to the philosophy best supported by Rust

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.

This gives me hope

We need examples!

Anyone writing 3-tier architecture systems remembers that a good OO design makes development easy -- by building up an "application-specific language" of domain and controller objects. For more advanced designs, I always recommend the 2002 book "Object Design" by Rebecca Wirfs-Brock and Alan McKean. The section on "class prototypes" is really valuable - a simple design can categorize various classes/objects into 6 stereotypes ("service provider", "information holder", "structurer", "controller", "coordinator", and "interfacer"). Controllers are usually very ugly and very procedural singletons (just what Brian likes), but they are somewhat less spaghetti-like because they are built on top of a solid base of real-time external messages coming from interfacers and well-encapsulated data structures managed by structurers and really easy-to-maintain information holders. Note that Ivar Jacobson promoted "controllers" in his 1992 book... this stuff has been around since the earth cooled.

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

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.

Functional programming in c++ is actually a beautiful thing

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

I think I've been organizing code like that already... but whenever some OO nut comes along and demands I defend myself, they obviously don't have the brain capacity to listen to different ideas. in all instances of self-defense I feel the urge to deep-six the offender.

you mix up style guides / good practises with OOP. To speak in OO terms, you generalized too much.

"Modules are singleton, and we're unapologetic about it" - uh huh.

interface Device {
executeTask(): Promise<Result>
}

export class DeviceController implements Device {
constructor(private readonly devices: Device[]) {}

executeTask(): Promise<Result> {
// balance executeTask across each sub device
}
}

Good luck implementing the above when your DeviceController (and Devices) are all Singleton modules. But would be curious to see someone try express the above as elegantly.

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.

On the structure part you are wrong. At least judging from my 12y of experience.

Badly structured code has nothing to do with a particular language, paradigm or orders of abstraction. Bad structure is a disease infecting the vast majority of projects developed in the past decade or so.

To structure properly you need to learn it from master programmer (as in master apprentice). It includes aspects like the black art of software architecture, time to market, avenues of extendibility, fixed and variable business logic, reliability and performance requirements, team composition and skill,....

The recent influx of new programmers makes that impossible. The industry has decayed so much that a person with 5 years of experience has the chance of getting the "senior" tag from day 1 after hire to a new company.


These are the same people who blame their inadequacies on technologies, paradigms, languages and so on. They go ahead and build almost un-maintainable applications to which the obvious solution is hireling more developers. Which in turn eats up more and more of the workforce attracting people without experience and lowering the seniority threshold.

The other day I was watching a tutorial on some redux in the context of a book store or something. And the dude, without blinking whatsoever, just went ahead and created the actions and reducers folders like a fucking psycho in the src folder. Like actions and reducers where the main feature of his app. I left an angry comment and continued with decoupling, hiding and recomposing that thing to fit the project I was working on.

After 2 years, if you ask my juniors (aka seniors in 2022) what redux is, none will answer you, but they know what the global state management on the project is and how to use it. We had parallel development of 4 features one time. 4 developers with the total number of files touched by multiple equal to exactly 0.

Computer science needs analytic metaphysics.

logic??? there is none

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.

ECS then.

This is basically how big projects written in c (for example an operative system) are written

This is a joke right? Just write SOLID code. And your code won't suck.

OOP is fine.
You're confusing OOP with style guides.
Having many small pieces and abstractions is not OOP, but a style guide for "good" design, that you can break whenever you feel it's appropriate.
OOP doesn't encourage you to modularize by speculation at all, you can literally write the same damn abstractions in OOP or procedural code.
Current OOP does have problems
1) Inheritance should not be conflated with subtyping at all. Subtyping is a form of polymorphism, while inheritance is way to avoid writing duplicate code that has nothing to do with polymorphism.
2) Not everything should be in a class. There should be functions and data in namespaces. The boilerplate of creating a static class to emulate functions and data in namespaces is just stupid. Modules are Namespaces, so you're right with the point that it conflates modules with data types, but that doesn't change coding much, it just means some boilerplate for things that aren't in data types, but it doesn't change anything in the design of the software.
3) It should be possible to add methods to types, like Rust-traits and C# extension methods allow for

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.

so this guy roasts OOP for Precudural, why not Functional?