hah, is this the return of "topmind"? I miss that guy, he was the anti-OO fanatic of the 2000s on usenet and c2.com.
Case against OOP is understated, not overstated (2020)
81–90 of 557 posts
Re: Case against OOP is understated, not overstated (2020)
#82In 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…
There's a really wonderful talk that I've recommended to almost everyone I've ever worked with called Simple Made Easy[1] by Rich Hickey. I also struggled to explain why I hated state so much. You can talk about races with shared mutable state but even single threaded code I found I couldn't stand it, that it made things harder to reason about and change. It's because state is complex , in the sense Rich discusses in…
Me as well but I was already sold on Clojure by then.
Re: Case against OOP is understated, not overstated (2020)
#83Data Oriented Programming. In short, don't entangle your code with data, and the data should immutable. https://blog.klipse.tech/databook/2020/09/25/data-book-chap0...
A program with only immutable data cannot do anything interesting, almost by definition. Some data has to be mutable.
Re: Case against OOP is understated, not overstated (2020)
#84People spend way too much time arguing about this.. If you're a good programmer u will be able to do excellent maintainable work in any language you're experienced with. If you're bad you will make a mess in any language. It'd be like carpenters saying "spruce is terrible if you make anything from spruce its fucked, you have to use oak." ; A good carpenter will be able to make something amazing from spruce. Like carp…
Yeah pretty much this. If a paradigm (whether functional, OOP, or whatever label makes you feel better) isn't working for you when it has worked for many others, maybe it's not because the paradigm sucks... it's because you might just suck at the paradigm? Obviously there are cases where things were pigeonholed into the wrong paradigm for the job. Then it's a case of the person choosing the paradigm sucking at choosi…
Absolutely. I really want to love FP style programming, but I just can't get it to gel in my head. I'm totally on board with the concepts of side effect free programming, minimising state, passing around functions as parameters, etc...
But I struggle with reading it, and I struggle with writing it, and I struggle to build a conceptual framework of how FP style components fit together. I've been banging my head against the FP wall for _years_ now, and I still can't seem get a level of fluency that where I'm comfortable using it regularly.
That doesn't mean FP sucks, it just means my brain isn't wired that way.
Re: Case against OOP is understated, not overstated (2020)
#85I 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…
> Has anyone seen large scale development done successfully in an an "anti-OO" language like Rust? 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?
Very often in code like that you see "struct" types filled with function pointers.. Those are literal OO "vtables", just implemented manually instead of being generated by the compiler.
The Linux kernel is huge, yes, and is written in a "pre-OO" language. It's also full of OO paradigms.
For example, the core kernel developers don't want to have to write huge "switch" statements to handle the thousands of different drivers written by tens of thousands of third-party developers.
What do you expect to see at this API boundary? Perhaps.. and OO API with vtables and everything?
Yup: https://www.kernel.org/doc/html/v4.11/driver-api/infrastruct...
Function pointers in structs as far as the eye can see...
Re: Case against OOP is understated, not overstated (2020)
#86Article like this miss the question of what purposes OOP serves in practice and so fail to offer alternatives to that purpose.
In practice, OOP basically exists to take some horribly messy program, put an interface around it, and make it slightly less terrible to deal with. Similarly, it also involves creating an interface to a thing a programmer barely understands and letting the programmer do some things with it. Which is to say is about letting the programmer be wrong and only fail moderately - as opposed to making the programmer is right.
Inheritance, one of the worst feature of OOP, has wormed it's way because it's also incredibly convenient.
Everything that OOP is compared to (notably functional programming), is based on a "green fields" paradigm where everything can be controlled. And maybe those approaches work great (though you can't exhibit stuff with they replaced in OO in the trenches and maybe things great).
It's got the tone of "this suspension bridge is far superior to your roll of duct tape" - yeah, maybe you're right but that won't make the duct tape go away even slightly.
I wish someone would come up with a good and immediately applicable alternative to OOP but I can't this sort of critique leading there.
Re: Case against OOP is understated, not overstated (2020)
#87In 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 experience many game companies were never big on OOP in the first place.
Re: Case against OOP is understated, not overstated (2020)
#88In 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…
There's a really wonderful talk that I've recommended to almost everyone I've ever worked with called Simple Made Easy[1] by Rich Hickey. I also struggled to explain why I hated state so much. You can talk about races with shared mutable state but even single threaded code I found I couldn't stand it, that it made things harder to reason about and change. It's because state is complex , in the sense Rich discusses in…
This is one of my favorite talks. It also helped things click for me regarding state. I try to use immutability wherever I can now and when there are unavoidable state changes, I try to understand and constrain the factors that could lead to such a state change. It's simplified things so much for me.
Re: Case against OOP is understated, not overstated (2020)
#89Article like this miss the question of what purposes OOP serves in practice and so fail to offer alternatives to that purpose. In practice, OOP basically exists to take some horribly messy program, put an interface around it, and make it slightly less terrible to deal with. Similarly, it also involves creating an interface to a thing a programmer barely understands and letting the programmer do some things with it. W…
> In practice, OOP basically exists to take some horribly messy program, put an interface around it, and make it slightly less terrible to deal with. Similarly, it also involves creating an interface to a thing a programmer barely understands and letting the programmer do some things with it. Which is to say is about letting the programmer be wrong and only fail moderately - as opposed to making the programmer is right.
I don't think any of this is unique to OOP; rather, this applies generally to the concept of abstraction.
Re: Case against OOP is understated, not overstated (2020)
#90That is a wall of text that I admit I could not fully read or understand.
It seems to argue that OOP is bad but what I gathered from it is that it argues that complexity is bad and that we should make things simple.
The problem is that complexity is unavoidable and even if we make every part individually as simple as possible the final system will still be complex and hard to understand and test.
OOP was supposed to help build the simple parts and then system would be easier to understand. It failed, not because it is inherently bad but because it enabled people to build more complex systems at which point the end result became hard to understand and test.
FP might help a bit by forcing certain style of development which could make current systems easier to understand but the end result will be the same - it will reach the point where the systems built with FP style are hard to understand and test.
What we should be developing is software to help us understand complex systems - both software systems and real world systems - and then the style in which software is developed will become less important and we will be able to understand how the system is working as a whole and drill into how individual parts are interacting. A good version of this software would allow more complex system to be created but it should also help with understanding them regardless of the level of complexity.