Totally agree, because OOP is so often horribly written and abused, sometimes where OOP has no business being! Inheritance is very useful in SOME cases, and is the thing most often ABUSED!!!!!!!!!!!!

And yet... autocompletion. I mean... I get it. Clean code, easy to read, less lines, business flowing line down line down no jumps from class to class... but: autocompletion You've got a really big and complex codebase (as it should be, I mean, we are modelling big-ass problems and they translate to big-ass code, we want it or not), and you type a name and a dot and you get what you can do. Not on the list? Fine. Go to that name "class" and add it. Be serious about it. Be kind to your coworkers. Add something that makes everyone's coding life better. "Data is data, no behavior": That's awesome. We have Value Objects, and Persistence Objects, and every kind of Data Objects (records... you name it), and we pass them layer to layer to layer until we have no control of the data anymore, because each layer can modify it at their will (its data, and I modify data, that's what I do). I don't buy the "pure function" approach, That's why mathematicians and physicians have need battling around the last 2 centuries... and they are way smarter tan us, programmers that type out under their discoveries. I appreciate the point of view. It really made me think about our foundations. But I feel it's all a dellusion. Coding the world is F***ing hard. Coding the world is F**ing amazing as well. We (the coders) have made a lot of tools to make that coding easier for us and more joyfull. I've enjoyed multiple times a well designed SDK, as Objects (or whatever name you want to call them), but never I enjoyed a pure imperative programming where I don't know where to start off if all I got is a huge list of functions (perfectly-agnostic-generic)

If having less functions to read in order to get a foothold and get started in a codebase is an issue, then you need to have a serious talk with your teamlead about why you're not getting a good introduction into the codebase and whether they expect you to read the whole 1M+ lines of code before you can finally get started. I don't expect you to read and understand all functions of a product before you can get to work with it. But I will give you a headsup on the basic architecture of the application, where some of the known issues are, the things you really need to know. OO often becomes complexity for complexity's sake, at which point the team is just not being professional and using the codebase for their own entertainment, experiments, and brain exercises. That being said there is some value to stuff such as a job pattern. The first example in Ruby seems to be some kind of job class, that's maybe scheduled for execution at some point in time. It makes sense then that this object only exists as long as the job has not been executed yet. It could also make sense that the class doesn't contain any data. Whoever told you that classes need to be datatypes maybe did not mean that the class should actually contain data fields and anyone who told you that is simply wrong. Plus, the mere existence of an instance of a class is a datapoint in itself. Consider if you will, an abstract class called BooleanObject, with 2 descendant classes, called TrueBool and FalseBool. The abstract base class would contain an abstract function Not(), returning a Boolean. The TrueBool implementation would return a FalseBool instance and the FalseBool implementation would return a TrueBool instance. Without any datafields in these classes, you still have a representation of a boolean point of data. Also, the SOLID principles are not meant to be enforced dogmatically. At that point you'll never have a class with a single responsibility and if you'll want to solve that, you'll eventually have to make classes for every single assembly instruction that the compiler spits out. It's just leaving sanity behind at that point. Those "principles" that people tell you about when learning how to code OO are not the law. They can be bent or broken occasionally for pragmatism. Looking back to programming history, structural programming had some issues. And like Robert C Martin also said.. The things that OO boasts like encapsulation, polymorphism and such.. They are nothing new. Even polymorphism is possible in structured programming. But OO made it easy and less error prone. C++ classes have encapsulation for sure, but C can just declare an empty struct in a header and leave it at that, and define the fields of the structure in the C implementation file. Like Robert C Martin said. C has "perfect encapsulation". That's not possible with a class in C++: you have to define member data in the header file unless you only the class in the implementation.. But OO makes it more obvious by using syntax that ties stuff together. In order to access stuff that's private to an object, you'll have to do special things with some pointer magic, which requires you to know how the compiler configures the data of an object in memory. It's very hacky and not meant to be done at all (though I've done it in Delphi while debugging some weird stuff and for curiosity how Delphi did it). Structural code just allows you to access everything as long as you know it exists. So by using OO the compiler enforced encapsulation and made people think about where their code was pulling data from. It helped people to take data out of the global scope (where it doesn't belong) and keep it close to the code that needs it. Do you have to do it? Of course not. It's all going to be machine code in the end anyway. In assembly there is no "private", "public", "global" or "static".. Programming languages are not meant for the computer to understand what we want it to do. Some people may say that, but we all know computers don't understand sh!t. You might as well code in assembly. It almost always works faster, because you've got ultimate control about how you get the computer to do what you want. And the resulting executable will most likely be smaller as well. And it's not even (primarily) meant for you to understand what you're writing, because you'll be capable of that in assembly as well. But writing stuff in assembly doesn't help you to understand your own code 3 years later.. And it definitely doesn't help someone else to understand your code. OO helps not only you, but also future you and especially others to understand the scope of data and how it is related to the functions and how functions relate to each other and gives context. But when you become dogmatic with the "rules" of OO, that's where things start to fall apart. We humans are not meant to follow rules. We're meant to think about our actions and consequences and do what's right. Not what some rule tells us to do, because rules may have been written without anticipating the situation we're in. If human civilization were facing extinction and you're the only one who can save us but you've got limited time, are you going to wait for a red traffic light because otherwise you'd be breaking the law? No, that'd be stupid. So principles of OO are meant for developers to understand how to do it right, not something to justify judging each other. About the coin flipping game.. That's really not a good example. The code contains lots of duplication, three times a random function, two definitions of the coin names, one being a non static member of a class where it doesn't belong. But perhaps the most telling sign that this is not a great coder, is having two variables for a player index, neither are called playerIndex and the way of getting the opponent index is using a ternary expression 🤨 Why not just call it playerIndex and then do playerIndex = 1 - playerIndex; ? Then the function setCoinOption is VERY counterintuitive because it's setting the OPPOSITE value of what was passed in, and moreover using string values to do so, which is very bad for performance (not that you'd notice in such a small example, but if this were code of someone who'd apply for my software development team, that would definitely be one of the reasons not to hire them.) In terms of naming it's bad as well. "didPlayerWin" is a yes/no question. Based on the name alone, I would expect a boolean result, not the function to print a string. By the way, why are you using an if statement with a temp variable to swap the names of player 1 and 2? That's 5 lines of code, altering the function argument values, where 1 suffices without changing the input. String winningPlayer = (math.random() < 0.5) ? player1 : player2; The polymorphism case is also not a great example. You're dealing with hardcoded situations that have a very big overlap in how each case functions (hence having lots of duplicated code). If these were from plugins, I could understand the reason for using polymorphism. But this is using a canon to shoot a fly. I'm not a fan of your solution either by the way. What if these cases keep growing, and you're getting exception cases.. Would you use a nested switch? That gets ugly really quickly. One question about your argument marshalling code. Could you please put it in a library that I can reuse? But I have this argument to set verbosity which can be just -v but I can also make it -vv or -vvv for added levels of verbosity. Your current marshallers don't handle that case, but that's ok. I can just provide a custom marshaller, right? No? Why not?

00:11 - operating system 01:01 - windows; unix 01:54 - device driver 02:31 - primary purpose of an OS 03:42 - pre-emptive multitasking 05:31 - sharing memory between processes 07:31 - process memory 08:06 - stack; heap 12:45 - virtual memory 15:43 - process lifecycle 17:50 - filesystem 20:23 - filepaths 22:49 - interprocess communication (IPC)

00:00 - introduction 00:49 - classes of computer systems 02:57 - RAM 04:36 - programming model 05:22 - binary instructions 07:27 - registers 09:19 - Instruction Set Architecture (ISA) 11:06 - big-endian vs little-endian 13:20 - processor cache 16:47 - communication between devices; memory-mapped I/O; port-mapped I/O 19:17 - polling vs interrupts 20:40 - hardware exception 21:20 - boot firmware 22:09 - what a programmer needs to know about a particular CPU

me watching this on a mac, wanting to try out Linux

The The cope in the comments is unreal "its just bad code, its not because OOP itself is bad" Typical no true scotsman stuff. If OOP is so vague as a concept and so many well respected OOP write bad code anyway, then whats the point of using the term anyway? Either their code was typical OO code and was massively improved by removing the OO. Or OO just doesn't mean anything at all and calling something OO or not OO is absolutely useless, because you can never know if something is actually OO when noone can agree on what that means.

Apart from over use, OO's biggest problem is life management when you are passing objects around as parameters, which is often required in complex systems! ...and NO auto destruction with reference counting DOES NOT work reliably due to code complexity and creative object uses! ...OO has serious issues!

I often use classes just a namespace! Handy. Complex data structures DO need objects, even if singleton, to encapsulate operations. I totally agree OO is way over used and not useful often at all! In fact OO sometimes just makes a simple thing crazy more complicated! Some of this is that mots programmers these days are CRAP!

I think OOP is good in small doses, but it's really overdone sometimes. Having dog.bark() instead of dog_bark(dog) is nice as long as name mangling isn't an issue, but things can get ugly pretty quick if you go further.

"There isn't a simple pointer type in C." void* would like a word, but the less said about that the better.

If your OO is functional, you're good

I’ve my Java exam tomorrow. I’m an engineering taking Java for fun, and I gotta say, all the abstraction with OOP has felt way too convoluted. Thanks for validating that feeling.

these are so good

Not cherry picked my balls bro what

A few years later, you were correct, this was the most important programming video I ever watched. Thank you for making the video.

This was incredibly insightful!

I'd be interested in an updated video on how your approach has changed, what's stayed, and so on. It's been years so I imagine you've had many opportunities to practice what you preach, so to speak. What might you say differently?

This honestly feels like some great satire, backed by Some Dude's opinions online. No introduction to who you are, what your history is, what projects you've worked on and what tech stacks, just some graphs and ideas that go directly against what is taught in the industry. The author makes no mention of unit testing and how OOP makes it easier to do mocks and test parts of your program easily, makes no mention of of static analysis, nor do they mention that while you can't have lots of tiny classes, you also can't have lots of massive classes, they merely go for the other side of the spectrum and take a firm stance there, not any different from some other religious programmers. The fact is that part of our job is also to adapt to existing projects so we deliver value as quickly as possible, and if a codebase is written in a certain way, it's often best to follow established patterns. Part of our job when designing code is also to deal with these difficult philosophical questions of how to design a system, it's how it is. It takes time to become good at designing systems, there's no clear rulebook and there's a lot of trial and error. We are often used to be told "best practices" and liberally apply it to our work, but not everything is going to be so easy. The principles of designing good objects are taught to us, but it's up to us to master them in practice, because every project is very different, and they touch different domains, some patterns are better and some patterns are worse.

A friend of mine brought this video to me, claiming that OOP should not even be practiced anymore. All I have to say is this: Video title says: OOP is bad. But All you complain about is encapsulation. I suggest renaming the video...

`function () use ($var1, $var2) { ... }` exists in PHP :) You can create static functions, so that you don't bind to the current object. Pretty neat.

The idea about anonymous functions that doesn't see it's enclosing scope is exactly how C++ lambdas work (except you can get references and not just copies).

Just use maps! kzbin.info/www/bejne/l4Sogpmng76Bd8U OOP leads to countless types that make languages inside languages, death by over-specification!

I've been programming since the 1980s. I even remember when people used to use Assembler and Basic. As one starts to build more complex programs in either language is it easy for it to get too complex to easily keep track of. And thus was invented Procedural Languages like Pascal and C. However the same group of people who could turn Assembler or Basic into spaghetti still found a way to make one-use functions and even worse again spaghetti code. The new solution was to force coders to write their code in encapsulated blocks called Objects. I think of it as nothing more than yet another attempt to try to get coders to write better code. Interestingly, everything they did with Objects i was already doing with well written code libraries. Also the Objects included overhead memory use that i didnt require as unused functions were removed by the compiler. Somehow coders managed to write bad code -- even Object Classes that weren't generic or couldn't be reused. Basically they never understood good coding and changes to the language didnt fix that -- not even when Microsoft turned EVERYTHING into an Object in their C# version. Java, JavaScript, and a lot of other languages are still trying to teach good coding by hiding & protecting their internals. Even "namespace" came about because coders couldn't think up original names for most things -- repeating already used names. So what is the True Purpose of "Object Oriented Code"? As far as i can tell it has never been anything but a method of compiler developers to force better coding practices on a bunch of Noobs or Insulants who can't seem to get the idea. Is OO coding necessary? Of course not. Everything done with OO can be done without it. Even compiling it and looking as the Assembler Code your compiler creates and it doesnt know if the code were procedural or object oriented. By the time it gets thru the compiler it is all sequential Assember Code / Machine Code anyway. PROGRAMMERS need to learn and use good programming practices just like a Database Designer needs to design a DB that doesn't require constant ETL because inadequate designs. Well, today Python is the new Basic. Lets see how badly they mess that one up too. I'm betting there will ALWAYS be a certain number of bad coders. Lets support those who know what they're doing not fix the language for the worst of the handicapped coders.

you want something perfect? good luck. things start out simple and eventually gets conplex. so what do you suggest? Python? are you kiddkng me? LOL

It's Mac OSX, not Mac OS 10. The X is pronounced "Ex" as a reference to its kernel; which is a UNIX kernel written in Objective-C. I can't watch this video past 1:49 because you keep saying "Mack OS 10". This is like when my grandfather got a computer science professor thrown out at the university he worked for, because that professor wrote a journal article where he called the speed of a CPU "kilocycles" like it was an old radio. Little mistakes like this in the computer science world can cause major issues in the long run, so accuracy is extremely important. This issue must be fixed

Core Dumped @ KZbin vibes

Truth. OOP is in essence just coupling functions to state. It's a nifty trick to use from time to time, but using it as the base of a paradigm is insane. It literally just reduces the flexibility of your code!

Late to this (8 years later). Unnecessary complications are bad. You picked two examples that were used for TEACHING the fundamentals of OOP. Also a bad choice. However, there are many scenarios where OOP is great. Many examples where procedural and functional are great. The difference between a regular programmer and a great programmer is knowing WHEN those things are needed. I feel like you were (or if you still feel this way ARE) one of those developers that would argue 'this language is better' or 'this thing is better' instead of "this is the right tool for the job and here's why". And as you mention more and more in this video, you talk about principles and such, but it almost feels like the justification for not liking it is grounded in not wanting to do more work vs the actual reasons of why/when oop should be used vs not.

Are you related to the voice behind Casually Explained? Such a striking resemblance in voice and general manner of speaking in my opinion. Anyway, these videos are fantastic even over 13 years later, so thank you! In my case I was wondering about the "-t" flag (force pseudo terminal allocation) of the openssh client program, and why without it a command given as argument to the client would be left running on the remote end after closing the connection by pressing Ctrl+C. And also wondering about the pseudo terminal escape commands, which I didn't even realize have always been present in the typical use case of ssh. I believe these videos helped me understand this better. I still find similar program flags confusing sometimes and I run into them frequently, when executing programs inside containers for example.

I'm interested in what the 'Delphi' issues. I'm starting on a Delphi project.

Brilliant

Amazing video ! I've seen it twice so far

Great, concise and understandable explanations!

Didn’t watch, you’re wrong

The concept of encapsulation (aka modularization) has been around from the beginnings of structured programming. The original K&R C book is loaded with it (filters). The point of any methodology isn't to provide a monolithic solution. Software is still way too young for that. Don't throw out valuable concepts based solely on what you perceive is poor implementation or dogmatic application.

Is the number one oop hater really using c#, huh?????

I can't get this to work. I can render to the default buffer only. I'm not getting any errors, and framebuffer is complete. I'm using DSA functions. Any tips?

The frame at 6:35 is exactly what my code looks like. The top is a series of actions (do this, then this, then this). Below that is where it's defined how each of them do that. You can open any file and immediately understand what the file is supposed to be doing, and you can scroll down if you want to know how it's doing those things. I've never done this as a class though. It's always done as a subroutine. Subroutines call each other without using classes.

Sounds like a skill issue

The concepts in this video are deeply similar to those in the book "Data-Oriented Programming" by Yehonathan Sharvit

Video avanzado para mi en menor medida, volveré a verlo para cuando pueda entenderlo

yea yea. Every guy thinks they know better than every single person that came before, etc. If OOP is so bad and you had the answers you'd be making millions or billions revolutionizing the industry

If you appreciated this suggested approach, you may be interested in the C3 Language.

Are you in cooperate with Geek's Lesson? They had a absolutely the same vids here. Operating system for beginners || Operating system basics watch?v=6-mdtMKfEYM

Wrong on so many levels. Yall just don’t know how to code in OOP to truly appreciate it. And those who don’t like to jump around to read code shouldn’t code. Explain all this to the Gang of Four, the founders who created OOP. The benefit of understanding OOP is it provides solutions to the same problems applications can come across. Got multiple implementations of an abstraction whose calling class doesn’t need to know about the specifics? Use the Factory Pattern Got a call to an API whose calling class cares only about its returning data? Use the Adapter pattern to encapsulate the details. There’s the Builder pattern that helps encapsulate the instantiation and creation of an object with multiple data types. The thing is OOP provides a common language and systematic approach on which to develop from. Yall just clueless and should leave the coding up to the pros.

A console emulator must always have a pew pew you 😁

In practice, outside some niche areas like game development, there are rarely such long-lived objects with shared state. Most shared objects are stateless services. Stateful objects are often not shared, and are part of a very controlled and short lifecycle. Often, state is also immutable. But I agree that in the situation where you run into multiple objects mutating state of an object, you have to manage the consistency/correctness of your application yourself or re-design it. Plus at kzbin.info/www/bejne/h36Umoiba66inK8 for instance, how would C even obtain a reference to F in the first place if it is not a singleton or similar. And if it is the latter, then it should not have state.

This is Composition over Inheritance with extra steps.