All I ask, so that you don't come out being the same brainwashed drone everyone else does until 10 years into their career and it's too late: When they start teaching you that the proper way to write code is to break it up into objects and those objects represent things like a car just realize that there is an arguably better way to do it called functional programming. If I had known that from the beginning I wouldn't have hated programming so much because I would know that what I actually hate is the though pattern of OOP, which is messy and ugly.

Now most of the software in the world is written in OOP pattern because that is what they teach in school. Most programmers don't know anything else and it's a shame. I think the fact that the industry was sold OOP is one of the biggest tragedies in the modern world on scale that is unfathomable.

The problem started back in 1967 with Ole-Johan Dahl and Kristen Nygaard created Simula 67. Then Alan Kay in 1970.

Sumula 67 was used to define digital objects and in the real world physical things share a lot of properties. This is where this kind of coding can make sense. This is why you start out learning about 'cars' even though your chances of ever making a car object in your programming life are next to none. The reason is very simple. The VAST majority of coding that exists in the world in not a mirror of any physical objects. Our code represents completely abstract things and almost all of them are extraordinarily unique. So for 50 years developers have been trying to figure out how to make 'cars' in their code so that they can make a 'lamborghini class that inherits from the 'car' class.

The problem is they are not working with cars or lamborghinis they are working with applications that do accounting or manage a network connection. They will create parent classes that get inherited into child classes and then realize they overwrite something from the base class in almost every child class to the point where you start wondering why you have the base class at all. Oh it's because there are still 2 functions in there that some children use and a few that some other children use. You get everything in every child whether you use it or not. You just have to keep track in your head of what your classes look like when stacked on top of each other. What cancels out what. What might interfere with something in your current class. Now imagine that stack in 5 levels deep and all of that is in every object you make. Just ignore it don't worry. Just turn your brain off and embrace chaos. That is the inheritance model.

Now lets get on to the even worse thing. Hidden state. You see Alan Kay was a biologist and he thought it would be cool if software acted like the cells in his petri dish. He figured that if it works for nature, why not software? He though, hey what if we slice up our software so that it acts like a colony of cells all communicating with each other unaware of the big picture. Put them all together and they will arrive at a conclusion. Done. There is a small problem. They will arrive at A conclusion, just not any particular conclusion. As long as you don't need a correct answer or there is no correct answer this is fine. Cells are chaos. Cells exist to be robust so an organism can lose them and the organism can continue to function. The quality of that function can be anywhere from a sick orphan to a marathon runner. This is not what we use software for. For most of what we use software for there is an EXACT CORRECT answer. For instance when you want to keep an airplane, say a 737 Max, in the sky you don't let the engine sensors each act like a cell that hopefully work together. What you actually need is a machine, an army that is managed and coordinated exactly like a fine tuned machine. There is no room for the main thread of an application, the brain to not know EXACTLY what is happening everywhere. When you're controlling an airplane. There is one mind, one set of actions that affects everyone on the airplane. The main brain needs to be able to audit and control absolutely everything that is happening to the smallest detail. When you create these 'cells' with their own persistent state data they are no longer part of the main organism. They're looking out for themselves. You can hey speed up 10mph and the first time you call it maybe it speeds up 10mph, but then you ask it the same thing 20 minutes later and it speeds up 15mph. Why? Because it's a cell man, it's living it's own life, it has it's own data and that's none of your business. So the plane crashes and no one blames OOP, because how could the thing my college teacher, who never had a job writing software, be wrong?

So when they start teaching you about private variables and initiating objects that act like these independent cells that float around invisibly and you get this weird feeling that it seems completely arbitrary to what you actually want to accomplish just realize it's because a biologist thought it would be neat. It's more like if you decided to dress up like a 17th century aristocrat every day and you spend 2 hours getting dressed up every morning. Maybe because your family was big into the Renaissance faire. One day someone asks you. "Why do you dress like that every day?". And you say "Well I have to wear clothes. What else would I wear?" and they say "You could wear LITERALLY anything else." OOP should not be 'the' way people code. It should not even be considered 'correct' in most situations. It should be considered a whimsical style not really appropriate for most cases. You're doing way to much for style, you take way longer than needed to get ready in the morning and your cod piece is making it hard to walk.

So what is the alternative? Well I bet if you were to just design a way to reuse code on your own, with your own intuition you would just come up with the alternative because the alternative IS the natural way to do it. It is the jeans and a t-shirt. It is exactly what you need and nothing you don't. Functional programming is where your main thread, your application brain, the 'self', does something it actually has complete control over the entire application. When it asks it's arm to go up, the arm goes up. The arm does exactly the same thing every time, or it tries to at least. The arm has no opinion, stored memory, baggage, left over from any previous evocation. That's kind of a bad analogy because an arm does have a kind of stored state, but think about how jarring it would be if your arm didn't go up when you wanted. You could not trust it anymore. That is how most of our software today is programmed. Ironically the actual better way to keep the state of that arm in software is still not grouped with a bunch of arm code in an OOP object. The best place for the state of that arm is with other arm data from all the other arms. OOP ignores 40 years of relational database development. Even in temporary memory all the same rules apply. OOP says "let's just put all this data which could be extremely important all over the place in boxes that blink in and out of existence." This is all because the digital world is absolutely nothing like the physical world and thinking of it that way was a very naive and whimsical stab in the dark.

Why does it perpetuate? There is a lot of job security making something harder than it needs to be. It's harder to learn, you need to write more code, it takes more time to write code because you have to translate into this arbitrary and unnatural format... It keeps people out of business. A lot of people will just give up on programming because they think it doesn't make sense. That's great for job security as well. You can't leave out all the teachers in the world who never learned any other way and never bothered to question anything. When all you ever write is code long enough to complete a homework assignment you will never be exposed to the nightmare of an actual corporate OOP codebase. When you have hundreds of thousands of lines of code and you're editing an object and spending half an hour trying to figure out even what is inside, when debugging the state of any of your objects could be different at any time depending on when they are called you realize the nightmare the world is in. Don't get me wrong. It's great for a lot of people, people who like busy work, job security, and don't care about the intention of any of it. This is also why most programmers you meet today are concerned with procedure rather than product. It's all about routine and ritual for them. They never needed it to make sense. "The ford is the car, the car is the auto". They just do it. You could have told them code needs to be written in the form of a rap battle and they would be doing that.

So go off now, learn your OOP to start, because that's how they all start, but when your intuition tells you something is wrong, trust yourself. It may seem crazy that an entire industry is broken, but in this case it is. That could make you feel a lot more confident in yourself and we need good programmers, not priests doing absurd rituals.