3 ms·

> this fashion of blaming OOP is really weird and should stop Right. There are many places where OO fits well. As you mentioned in the medium/large on the ser

by dgb23 6y ago

> this fashion of blaming OOP is really weird and should stop Right. There are many places where OO fits well. As you mentioned in the medium/large on the services/systems level. But it is also a good paradigm to model pretty much any real, outside thing. A database, a file-system abstraction (loading configs etc.), an external web-service, a peripheral device (keyboard, mouse), a GUI context (the whole thing, not the parts) and so on. In these cases we want the properties of OOP: local retention, message passing, abstraction through public interfaces and state-machine-like behavior. The issue arises when we model data with OO: A Person is not an object in your system. It is an associated data-structure. Treat it as such. A User interacts with an interface (CLI, config files, GUI...) treat those as objects. The data about the User is just data about the User. I don't have an authoritative opinion to offer here. I'm just a dude who writes programs. This is merely the model that works for me.

slifin 6y ago
> But it is also a good paradigm to model pretty much any real, outside thing If we get to the crux of the matter, what you like there is the tree structure (which definitely is the end result you want) the problem is if you store your data in a tree structure (whether by OO, file system or json document) you cannot easily express that same information but in a different tree layout Trees couple relationships and things together in such a way that they are hard to tease apart. If you think about your brain what it does is stores the sum of your knowledge in a graph, then at runtime your brain can construct any number of trees from that graph easily You can think of yourself as being a member of the tree of life and a member of your workplace hierarchy very easily, your data store should be graph like and your query language should be able to pull trees out of at will, checkout Clojure's Fulcro or any EAVT database if you want to see how that works in practise
mratsim 6y ago
> In these cases we want the properties of OOP: local retention, message passing, abstraction through public interfaces and state-machine-like behavior. That's not OOP but Actors or event loops.
- dgb23 6y ago
  Depends on who you are asking. https://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en https://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_ka... https://www.infoq.com/interviews/johnson-armstrong-oop/ https://www.infoq.com/interviews/johnson-armstrong-oop/

by dgb23 6y ago

slifin 6y ago

> But it is also a good paradigm to model pretty much any real, outside thing If we get to the crux of the matter, what you like there is the tree structure (which definitely is the end result you want) the problem is if you store your data in a tree structure (whether by OO, file system or json document) you cannot easily express that same information but in a different tree layout Trees couple relationships and things together in such a way that they are hard to tease apart. If you think about your brain what it does is stores the sum of your knowledge in a graph, then at runtime your brain can construct any number of trees from that graph easily You can think of yourself as being a member of the tree of life and a member of your workplace hierarchy very easily, your data store should be graph like and your query language should be able to pull trees out of at will, checkout Clojure's Fulcro or any EAVT database if you want to see how that works in practise

mratsim 6y ago

> In these cases we want the properties of OOP: local retention, message passing, abstraction through public interfaces and state-machine-like behavior. That's not OOP but Actors or event loops.

dgb23 6y ago
Depends on who you are asking. https://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en https://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_ka... https://www.infoq.com/interviews/johnson-armstrong-oop/ https://www.infoq.com/interviews/johnson-armstrong-oop/