61–70 of 557 posts
- They're small and single-purposed
- They don't inherit (or at the very least, extremely light inheritance)
- There's a very clear relationship between the state and the methods (e.g. a counter class, or a future/promise)
For example in JavaScript, I think you can still uses classes and end up with functional-ish code: https://bluepnume.medium.com/functional-ish-javascript-205c0...
How I've seen OOP work at big tech is the following: 1. New code base is needed 2. Some developer comes up with the master oop abstraction to solve the problem 3. Years of dev effort spent with the abstraction at the core 4. Dev on step 2 is now the expert in some overly convoluted complex system 5. Is determined a genius since new comers cant easily grasp the complexity, gets promoted to a high ranking dev job My nu…
My grading criteria for a codebase is "Can a hungover junior engineer comprehend this and work on it successfully?" When we are getting to "only a Principle engineer who is an expert in scala with a history of strong mathematics can work on this" is about when a codebase gets a fail.
TBF that one is really going to depend on the domain addressed by the code.
OOP is a great fit for UI frameworks. OOP is a bad fit for many other things. They guy who hammers nails all day thinks screwdrivers are worthless.
> OOP is a great fit for UI frameworks. The biggest UI framework of the past decade is decisively anti-OOP in its philosophy
How I've seen OOP work at big tech is the following: 1. New code base is needed 2. Some developer comes up with the master oop abstraction to solve the problem 3. Years of dev effort spent with the abstraction at the core 4. Dev on step 2 is now the expert in some overly convoluted complex system 5. Is determined a genius since new comers cant easily grasp the complexity, gets promoted to a high ranking dev job My nu…
My grading criteria for a codebase is "Can a hungover junior engineer comprehend this and work on it successfully?" When we are getting to "only a Principle engineer who is an expert in scala with a history of strong mathematics can work on this" is about when a codebase gets a fail.
Were there ever any real objective [hah] studies done about how much it improved software development? And did they show a significant improvement? Even if you're still pro-OOP today, you would have to admit it fell vastly short of its promises even if it does help a little bit.
Today it seems like there's been very little accountability or learning from all this. Some people have sheepishly climbed down off the bandwagon, but there's been very little overall reflection. I'm not talking about witch hunts -- there will always be more snake oil salesmen -- I mean learning as individuals and an industry to demand data and reason rather than handwaving and assertions. The sad thing too is that a lot of the baseless hype came out of academia too (microkernels are another one that comes to mind).
I still see this today. The new languages and language features. New database concepts like NoSQL. "AI". Blockchain. All the way down to the CPU (transactional memory, various "security" features, etc). Proponents can make extremely compelling-sounding cases for these things, and make it sound like they'll solve all the world's problems. And some may well turn out to be a net win in the end. But the only thing that actually matters is the real world results, and you can only evaluate that by studying the data.
In general, if something sounds too good to be true, it usually is. Maybe the incredible trajectory of the computing industry has dulled peoples' common sense when it comes to detecting this kind of hype. It's absolutely rife in the computing industry and academia.
I don't quite understand what this is trying to say. It's a summary review of some reviews? Or something. It's not even clear if the author of this post agrees or disagrees with the claim in the YC News title. It's peppered with sentences like: "That you don't understand something doesn't mean it's flawed or bad." Precisely. Many of the arguments against OO are from academics that don't write real-world, large-scale…
Taking "anti-OO" to mean languages that specifically don't have OO capabilities (rather than languages where you can choose not to use OO). Any of the large C code bases?
Earlier quoted context omitted.
My grading criteria for a codebase is "Can a hungover junior engineer comprehend this and work on it successfully?" When we are getting to "only a Principle engineer who is an expert in scala with a history of strong mathematics can work on this" is about when a codebase gets a fail.
This does a massive long-term disservice to junior engineers, especially because they're most likely just out of school and still very eager to learn.
Your entire team could be highly experienced and have PhDs in exotic subjects and I still think it would be a good approach to take.
In my mind, state is the real enemy impacting: comprehension, brittleness towards making changes, and the surface area exposed to potential bugs. OOP as frequently implemented, while claiming to encapsulate state, ends up creating so much more. In accordance with this view, I think project architecture should be approached with an emphasis around how much state is necessary for it to run. This is why simulations like…
OOP itself could be good for problems where you need state machines. The Erlang Actor model is successful for a reason, but I wouldn't apply OTP to general programming.
In my mind, state is the real enemy impacting: comprehension, brittleness towards making changes, and the surface area exposed to potential bugs. OOP as frequently implemented, while claiming to encapsulate state, ends up creating so much more. In accordance with this view, I think project architecture should be approached with an emphasis around how much state is necessary for it to run. This is why simulations like…
Games are actually moving away from OOP by separating out state into a data oriented system.
In my mind, state is the real enemy impacting: comprehension, brittleness towards making changes, and the surface area exposed to potential bugs. OOP as frequently implemented, while claiming to encapsulate state, ends up creating so much more. In accordance with this view, I think project architecture should be approached with an emphasis around how much state is necessary for it to run. This is why simulations like…
I don't know if it's just me but I watched that talk a couple years into my career and it was like something clicked into place in my brain. It changed the way I think about software.