7 ms·

OOP is great if all you are doing is OO and if your solution to a problem is running a simulation (what OOP was invented for). But you are not staying in your

by beders 8y ago

OOP is great if all you are doing is OO and if your solution to a problem is running a simulation (what OOP was invented for). But you are not staying in your pure OO-world nowadays. There's always the boundary issue where you are giving up your careful encapsulation and where state needs to be transferred instead of being hidden away in some object (like exporting to JSON). Poof, your encapsulation is gone. Furthermore, may OOP languages don't deal with ownership at all. If I'm a constructor and someone passes me an object A or worse, a list of As. Can I hold onto that list? Should I make a shallow copy? Should I make a deep copy, because I need the A objects in the state they are currently in? What if I have to work with 3rd party libraries? What assumptions do they make about that? Can I call methods on objects from multiple threads? I need to rely on the documentation to figure that out or provide synchronization myself just to make sure I'm not breaking things. Also, it is no accident that refactoring tools have become so popular in the OO world. If you need to design OO with 'change' in mind, you need to employ lots and lots patterns that make your code looks like new FactoryBuilderPatternVisitorImpl(). But with refactoring, hey, I can easily change my classes thanks to my IDE, yay! Too bad if someone then passes me data that only fits the old classes and too bad if consumers of my library are getting nasty surprises. It is with everything in software: use the appropriate tool for the job.

0815test 8y ago
> OOP is great if all you are doing is OO and if your solution to a problem is running a simulation (what OOP was invented for). And even for simulation-like code (or really any other case of "very-high-level" code featuring "object"-like entities linked by complex, non-trivial relationships) ECS systems work a lot better than plain old OOP, while preserving the wide variety of advantages that you rightly point out. Especially since ECS works as a reasonably-thin layer over the usual sort of data-oriented programming.
gambler 8y ago
Sorry, but you're just validating my stereotype of a typical OOP critic. OOP != Java. >OOP is great if all you are doing is OO and if your solution to a problem is running a simulation (what OOP was invented for). Most problems most programmers solve are simulation in some sense. Including DevOps. I wish larger number of people realized this. Things would become much simpler. The problem with class-oriented languages like Java is precisely that they are horrible for making simulations. Been there, done that. >There's always the boundary issue where you are giving up your careful encapsulation and where state needs to be transferred instead of being hidden away in some object (like exporting to JSON). Poof, your encapsulation is gone. Solving boundary issues is what OOP was designed for. Like, that's literally the original goal of the whole concept, as explained by Alan Kay many, many times. You were able to send objects over the wire in Smalltalk in the 70s. Every time you open a webpage with JavaScript you're performing an ad-hoc reenactment of the same idea. The fat that this idea is implemented badly on the web doesn't mean this is a bad idea. >Furthermore, may OOP languages don't deal with ownership at all. If I'm a constructor and someone passes me an object A or worse, a list of As. Can I hold onto that list? Should I make a shallow copy? Should I make a deep copy, because I need the A objects in the state they are currently in? This problem has been solved in 1978. http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-205.pdf http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-20... >Can I call methods on objects from multiple threads? I need to rely on the documentation to figure that out or provide synchronization myself just to make sure I'm not breaking things. See the paper above. BTW, guess how I found it? Alan Kay's talks. >Too bad if someone then passes me data that only fits the old classes and too bad if consumers of my library are getting nasty surprises. Again, getting rid of "raw data" was one of the core motivations behind OOP. See the email above.
- chalst 8y ago
  I'm curious as to which languages you do recommend. You don't see Smalltalk being used a whole lot in devops. Actually, class-based handling of raw data can be done very nicely if you have multiple dispatch, which solves the so-called expression problem. Cf Julia.
  - gambler 8y ago
    Pharo SmallTalk is getting some steam right now and worth checking out. Elixir is pretty cool. But I don't think either are the holy grail of OOP. I would really like to see some OOP language that implements James Reed's reference versioning or at lest a weaker implementation where every object "mutation" creates an effective copy with the changes, without touching anything that would be referenced previously. It would fix a lot of low-level annoyances people have with SmallTalk, JavaScript and so on. Would be extra amazing if it was based on prototypes, not classes. But at this point it sounds like I would have to write it myself.
    - wwright 8y ago
      This sounds like “persistent data structures,” which are offered in most modern FP environments (including JavaScript, if you use libraries.) Those structures don’t behave as objects themselves, but it’s not uncommon for Haskell monads, for example, to have very object-like behavior when you build them up a high layer, while each step in the monad is still an immutable value with cheap mutation-copies.
- arduinomancer 8y ago
  >BTW, guess how I found it? Alan Kay's talks. Are their any specific talks you recommend? I've only been exposed to OOP through Java so I'm curious to hear more about its roots
  - gambler 8y ago
    Most Alan Kay's presentations I've seen were worth watching. Tons of great ideas in each. They really improved how I reason about systems. There is this famous talk from OOPSLA 1997: https://www.youtube.com/watch?v=oKg1hTOQXoY https://www.youtube.com/watch?v=oKg1hTOQXoY If you want to see what "practical" OOP looked like in the 80s, this is a good video: https://www.youtube.com/watch?v=QjJaFG63Hlo https://www.youtube.com/watch?v=QjJaFG63Hlo
endgame 8y ago
> running a simulation (what OOP was invented for) I used to believe that. I no longer do. Among other things, I watched this talk about Overwatch's architecture and it really seems like you have to go against your OO instincts to create larger simulations: https://www.youtube.com/watch?v=W3aieHjyNvw https://www.youtube.com/watch?v=W3aieHjyNvw

by beders 8y ago

0815test 8y ago

> OOP is great if all you are doing is OO and if your solution to a problem is running a simulation (what OOP was invented for). And even for simulation-like code (or really any other case of "very-high-level" code featuring "object"-like entities linked by complex, non-trivial relationships) ECS systems work a lot better than plain old OOP, while preserving the wide variety of advantages that you rightly point out. Especially since ECS works as a reasonably-thin layer over the usual sort of data-oriented programming.

gambler 8y ago

Sorry, but you're just validating my stereotype of a typical OOP critic. OOP != Java. >OOP is great if all you are doing is OO and if your solution to a problem is running a simulation (what OOP was invented for). Most problems most programmers solve are simulation in some sense. Including DevOps. I wish larger number of people realized this. Things would become much simpler. The problem with class-oriented languages like Java is precisely that they are horrible for making simulations. Been there, done that. >There's always the boundary issue where you are giving up your careful encapsulation and where state needs to be transferred instead of being hidden away in some object (like exporting to JSON). Poof, your encapsulation is gone. Solving boundary issues is what OOP was designed for. Like, that's literally the original goal of the whole concept, as explained by Alan Kay many, many times. You were able to send objects over the wire in Smalltalk in the 70s. Every time you open a webpage with JavaScript you're performing an ad-hoc reenactment of the same idea. The fat that this idea is implemented badly on the web doesn't mean this is a bad idea. >Furthermore, may OOP languages don't deal with ownership at all. If I'm a constructor and someone passes me an object A or worse, a list of As. Can I hold onto that list? Should I make a shallow copy? Should I make a deep copy, because I need the A objects in the state they are currently in? This problem has been solved in 1978. http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-205.pdf http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-20... >Can I call methods on objects from multiple threads? I need to rely on the documentation to figure that out or provide synchronization myself just to make sure I'm not breaking things. See the paper above. BTW, guess how I found it? Alan Kay's talks. >Too bad if someone then passes me data that only fits the old classes and too bad if consumers of my library are getting nasty surprises. Again, getting rid of "raw data" was one of the core motivations behind OOP. See the email above.

chalst 8y ago
I'm curious as to which languages you do recommend. You don't see Smalltalk being used a whole lot in devops. Actually, class-based handling of raw data can be done very nicely if you have multiple dispatch, which solves the so-called expression problem. Cf Julia.
- gambler 8y ago
  Pharo SmallTalk is getting some steam right now and worth checking out. Elixir is pretty cool. But I don't think either are the holy grail of OOP. I would really like to see some OOP language that implements James Reed's reference versioning or at lest a weaker implementation where every object "mutation" creates an effective copy with the changes, without touching anything that would be referenced previously. It would fix a lot of low-level annoyances people have with SmallTalk, JavaScript and so on. Would be extra amazing if it was based on prototypes, not classes. But at this point it sounds like I would have to write it myself.
  - wwright 8y ago
    This sounds like “persistent data structures,” which are offered in most modern FP environments (including JavaScript, if you use libraries.) Those structures don’t behave as objects themselves, but it’s not uncommon for Haskell monads, for example, to have very object-like behavior when you build them up a high layer, while each step in the monad is still an immutable value with cheap mutation-copies.
arduinomancer 8y ago
>BTW, guess how I found it? Alan Kay's talks. Are their any specific talks you recommend? I've only been exposed to OOP through Java so I'm curious to hear more about its roots
- gambler 8y ago
  Most Alan Kay's presentations I've seen were worth watching. Tons of great ideas in each. They really improved how I reason about systems. There is this famous talk from OOPSLA 1997: https://www.youtube.com/watch?v=oKg1hTOQXoY https://www.youtube.com/watch?v=oKg1hTOQXoY If you want to see what "practical" OOP looked like in the 80s, this is a good video: https://www.youtube.com/watch?v=QjJaFG63Hlo https://www.youtube.com/watch?v=QjJaFG63Hlo

endgame 8y ago

> running a simulation (what OOP was invented for) I used to believe that. I no longer do. Among other things, I watched this talk about Overwatch's architecture and it really seems like you have to go against your OO instincts to create larger simulations: https://www.youtube.com/watch?v=W3aieHjyNvw https://www.youtube.com/watch?v=W3aieHjyNvw