People get genuinely surprised when I explain that closures and OOP represent the same shit where the former is much easier to use and compose.
There's a common-language word for "a feature that's beautiful and efficient and robust that only the high end of the bell curve can understand". The word is "hard". Closures are fucking hard. I use "functional programming" in python when I see an opportunity to sneak it in -- apparently a custom python decorator is a "closure", and I'm very good at writing those -- but I can't understand a single sentence in the wikipedia article on closures.
OOP is easy. Retards like me can use it. Retards like me can get and keep a solo dev job with no programming experience whatsoever, a nice IDE, and a best practices guide from the vendor. Soydev-friendly IDEs are geared toward OOP. The demand for developers is such that most of them are soy (soyer than me at least), and there will always be OOP jobs. Because it's easy. OOP puts food, and expensive collectible Chinese teapots, on my table.
Job-wise, OOP is "good enough", it's easy and it's self-reinforcing. It's cheaper to hire a good-enough soydev ro write classes than to hire
@Sperg Coalition to write closures and structs. Even if someone offers to write closures and structs for a fraction of the opportunity cost, who's going to support it after the closure guy finds something better to do?
We* had a customer with a fucked-up database who wanted a new react frontend + "any" backend for it. We couldn't change the database. I offered to write a reasonably fast, efficient, lightweight backend for it. I got told NO, because they'd want to eventually kick us out and hire an in-house soydev, and we had to use something they could find soydevs for. They eventually followed through on that plan, and they left some of our diagnostics code in because they don't know what it's for, and we get funny crash messages from their production server a couple times per week.
I learned the basics of system validation, to better describe workflows. Guess what? No one fucking cares. this knowledge is above my pay grade and is therefore useless at my pay grade. No one expects me to have it and no one has a use for it. The customer wouldn't understand it, so I do workflow validation off the cuff in my head. Found a million-dollar exploit. It took them a month to even understand what the problem was (essentially arbitrage).
*I'm soy, but my "boss" (senior partner) is a real computer scientist. It's been almost two years since I started working with him, and it's the longest I haven't hated a job.
I'll say that I think OOP is useful just for the fact that using objects helps me organize my code and and makes it easier to make significant changes to the code.
This.
Also, inheritance is awesome. I'm probably too retarded to do the kind of work and use the languages where composition shines. In python, I only got to use it once, to re-implement an economics model with two distinct parts (input, to be loaded from various sources, and output, either calculated from inputs or loaded from an authoritative source for validation). If I want to change how a class processes its fields, I'm not making a "mixin" that operates on those fields and calls other methods but has no knowledge of the fields and methods, it's retarded and unreadable.
Making the tokenizer is fun little mental exercise.
This was the first task I outright failed at vocational training and couldn't even understand the code someone generously provided. Made me give up on learning programming for fun. I loved the simple algorithms (e.g. sorting with extra work to do), graphs, strings, but tokenizers can get fucked.
