Data 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...
Case against OOP is understated, not overstated (2020)
41–50 of 557 posts
Re: Case against OOP is understated, not overstated (2020)
#42The problem with OOP is not just with poor implementations and inheritance models (e.g. Java) but that state encapsulation is actually bad and cements complexity.
The real goal should be to untangle state and decouple it from computations by putting it all in global shared state (e.g. SQL, Redux, ECS frameworks, etc.) while using stateless functional computations to compute changes to the global state. Pure functions are composable in a way that objects simply aren’t.
Re: Case against OOP is understated, not overstated (2020)
#43Earlier quoted context omitted.
I think in a lot of ways you're correct. FP and imperative code tends to makes state explicit; OOP hides state. The latter MAY make things "easy"; it never makes it simple.
"Hiding" state is necessary to endow it with well-defined invariants. This can be done in many FP languages, too. The semantics-side implications of "encapsulated" state w/ proper invariants have yet to be explored, though, and this is where newer PL formalisms like "homotopy types" might end up being quite helpful.
> The semantics-side implications of "encapsulated" state w/ proper invariants have yet to be explored, though
It seems that that's called a state machine, and OOP objects should come with state charts, but they don't.
> and this is where newer PL formalisms like "homotopy types" might end up being quite helpful.
PL research would actually get adopted if they didn't insist on using the worst possible names for everything. If they're not calling something an "intuitionistic type theory in the calculus of constructions" they're calling it a "pi-calculus".
Re: Case against OOP is understated, not overstated (2020)
#44Earlier 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.
Thats a broad generalization and many niche codebases cannot be high quality and still have a drunk junior become productive with it in a week. People need to accept that it's ok to require for some teams to have discussions on a level which requires serious experience and education
Indeed. A more nuanced interpretation of the question might be: “Can the most junior (or least tenured) engineer on my team understand the code in time to deliver the feature they’re working on?”
To be fair, OP’s original phrasing is still a good rule of thumb. And nowhere does the OP imply it’s an absolute.
Re: Case against OOP is understated, not overstated (2020)
#45OOP 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
Re: Case against OOP is understated, not overstated (2020)
#46I've come around to Julia's point of view that it makes more sense for the methods to be separate from the object they're acting on. I just wish Julia had a succinct way of saying "This object needs to have implementations for functions X,Y,Z", rather than duck typing everything and just seeing if it works. Maybe it isn't too bad in practice I just don't like it when a function can fail because the implementation cha…
This is known as "multiple dispatch" or "multimethods":
Re: Case against OOP is understated, not overstated (2020)
#47OOP 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.
The good parts of AppKit (which most OOP frameworks are based on) wasn't just that it came with nouny objects representing controls, it's that it used the "hard and soft layer" pattern with messaging and notifications. Which is not C++-style OOP.
Most of the even more OO frameworks around the same time, like Taligent, failed.
Of course it did win over procedural frameworks like classic MacOS, but some of those are still popular in games or embedded systems.
Re: Case against OOP is understated, not overstated (2020)
#48Interesting collection of point of views. A language like Erlang indeed seems to align more closely with the spirit of the OOP goals - especially regarding encapsulation and avoiding shared state. I would argue one of the best implementations of OOP is found in OCaml, where a nominal type system lives side-by-side with a structural type system, the latter which is used for objects and classes [1]. You still can use s…
> A language like Erlang indeed seems to align more closely with the spirit of the OOP goals - especially regarding encapsulation and avoiding shared state.
Indeed, Alan Kay himself said, to Joe Armstrong, that Erlang was closer to his idea of OOP than any contemporary language that claims to be OOP.
Re: Case against OOP is understated, not overstated (2020)
#49People 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…
Experience is not highly valued in articles about programming but often it comes down to that. I'm using tools with roughly the same level of expressiveness as I have for the last 20 years but I develop much better code now.
I've been guilty of over-abstraction and I've been guilty of under-abstraction.
There's a lot of blaming the tool for what amounts to lack of experience. Everyone has lacked that experience at some point in their career.
Re: Case against OOP is understated, not overstated (2020)
#50People 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…
[deleted]