5 ms·

OOP is great. Certain interpretations of OOP that certain popular languages adopted are bad, but the problem is not really OOP. The idea of objects is one of th

OOP is great. Certain interpretations of OOP that certain popular languages adopted are bad, but the problem is not really OOP. The idea of objects is one of the most powerful ideas in programming, because it is able to bring a level of modularity that is otherwise very hard to accomplish. For instance popular very high level languages like Ruby and Python are so easy to use and to build things with, because you have such initial collection of objects of all the kinds that are so trivial to use and versatile. The Array object may have a lot of methods in Ruby, but such methods are self contained inside its implementation, and to have a lot of tools for such data structure is great. This idea, that we give for granted when using Ruby or Python now, is quite impressive.

shados 6y ago
Having a collection of methods associated to an object isn't really OOP though. You can have one without the other. There's also not a huge benefit to having data.sort() vs Array.sort(data). OOP is a lot more than that. One can argue its great, one can argue it sucks, but either way, a bunch of methods grouped together isn't really what is being debated.
- jayd16 6y ago
  Sort isn't a great example because its presumably only looking at public fields of the elements only and could be functional. However, Arrays in ruby grow so they presumably have private fields and manage their own internal state. This is what the parent was referring to.
  - shados 6y ago
    You can do that with various constructs without doing OOP style though. Eg: in JS you could use a symbol to store that state that is only known to the methods allowed to handle he array "internal" state. (JS isn't a great example because there are ways to get access to those hidden symbols when you shouldn't, but it doesn't have to be that way)
- exclipy 6y ago
  OOP is not much more than single-dispatch runtime polymorphism. The benefit of `data.sort()` is you could write that in a function that accepts a `data` that could be an array, a vector, a linked list, etc... anything that implements the "sortable" interface. Writing `Array.sort(data)` in your function means the function won't be usable for any kind of data other than arrays. The other features of OOP like encapsulation, inheritance and abstraction -- these aren't so special. But OO polymorphism is pretty unique.
  - mrkeen 6y ago
    I hadn't thought of interfaces (e.g. sortable) as being an OO thing. That said, I do sometimes confuse myself trying to use them in Java, e.g. void foo() { Fruit[] basket = new Apple[] { new Apple(), new Apple() }; handleFruit(basket[0]); } void handleFruit(Fruit fruit) { System.out.println("Do I get called?"; } void handleFruit(Apple apple) { System.out.println("Or do I?"; } If it were runtime polymorphism I'd expect it to dispatch to the apple method, but it dispatches to the fruit method. I also run up against friction trying to define, e.g. the "mappable" interface across these two guys. Can't seem to get it done. class Optional { <U> Optional<U> map(Function<? super T,? extends U> mapper); } class Optional { <R> Stream<R> map(Function<? super T,? extends R> mapper); } For what it's worth, Java went with the polymorphic Collections.sort(data) approach, not the polymorphic data.sort() approach.
    - tpxl 6y ago
      >Collections.sort(data) approach, not the polymorphic data.sort() Since java 8, java.util.List had a sort method and Collections.sort(List) just calls List::sort. Before that, only the Collections.sort method existed. At least from java 6 on, java has a SortedSet and SortedMap that accept comparators as constructor parameters, but have no sort methods (So basically data.sort, not collections.sort(data)). Arrays can of course only be sorted via Arrays.sort, since arrays have no methods.
    - _old_dude_ 6y ago
      Java like C++ or Swift uses single-dispatch polymorphism, so only the receiver (the argument before the '.') is used at runtime. In Java, you can implement your own dispatch table quite easily Map<Class<?>, Consumer<Fruit>> dispatchTable = Map.of(Apple.class, fruit -> handleFruit((Apple)fruit)); Fruit fruit = basket[0]; dispatchTable.get(fruit.getClass()).accept(fruit);
- antirez 6y ago
  I consider "true OOP" what SmallTalk introduced. And the most fundamental thing in SmallTalk OOP is the encapsulation of complexity in the idea of an object, and the ability to pass messages to such objects that can be other objects, including "blocks". There is more than that to OOP, but I think that the fundamental idea is that code and functions operating on a given software component are defined within the concept of a class, and that objects only communicate with the other parts via messages. From that, a lot of things happen that are not obvious given this simple idea of OOP. For instance every object knows how to turn itself into a string, or to compare it with another one of its kind or of different kinds. And so forth.
  - CyberDildonics 6y ago
    What smalltalk introduced is not widely spread, which would imply it is not what the title is about.
    - scroot 6y ago
      Maybe. But the article opens by quoting Dave Robson's article in the 1981 Byte issue and even links to the archived version of the magazine. That issue was entirely dedicated to articles about Smalltalk. Robson's article is also about Smalltalk.
      - igouy 6y ago
        And yet, the "Why is OOP still so widely spread?" article never mentions Smalltalk. Perhaps the author did not wish to admit that even back in 1980, "you [could] have your class Cake and EatCake() it too". [:each :aCake | each eat: aCake]
  - dnautics 6y ago
    While that's true historically, SmallTalk has more in common with some functional languages (like erlang) than it does with even Ruby, which is directly a SmallTalk derivate. I think when everyone talks about OOP today they mean the lineage that descended from C++, which broadly is: Java, Javascript, C#, Python, and Ruby, to a lesser extent Go. Contemporary OOP is the enforced semantic association of data with their methods, encapsulation of private data, and shared memory.
- bosswipe 6y ago
  The advantage of data.sort() over Array.sort(data) is discoverability, especially with autocomplete.
  - deleted 6y ago
    [deleted]
- collyw 6y ago
  data.sort() vs Array.sort(data) I think the first one feels a lot more natural. It also seem to lower the cognitive load of knowing where to find the sort method / function. Is that just because I have used mainly OOP style languages?
  - newen 6y ago
    Pretty sure it’s a cognitive bias. The Array.sort method is obviously in the Array module. While to find the sort method, I’d have to find out what class data is in. Probably slightly harder is sort(data) in a language like Julia. The sort method wouldn’t be located inside the class definition and I’d have to run a command like @which sort(data) to find out where sort is defined. All three would be trivial with a decent IDE though.

shados 6y ago

Having a collection of methods associated to an object isn't really OOP though. You can have one without the other. There's also not a huge benefit to having data.sort() vs Array.sort(data). OOP is a lot more than that. One can argue its great, one can argue it sucks, but either way, a bunch of methods grouped together isn't really what is being debated.

jayd16 6y ago
Sort isn't a great example because its presumably only looking at public fields of the elements only and could be functional. However, Arrays in ruby grow so they presumably have private fields and manage their own internal state. This is what the parent was referring to.
- shados 6y ago
  You can do that with various constructs without doing OOP style though. Eg: in JS you could use a symbol to store that state that is only known to the methods allowed to handle he array "internal" state. (JS isn't a great example because there are ways to get access to those hidden symbols when you shouldn't, but it doesn't have to be that way)
exclipy 6y ago
OOP is not much more than single-dispatch runtime polymorphism. The benefit of `data.sort()` is you could write that in a function that accepts a `data` that could be an array, a vector, a linked list, etc... anything that implements the "sortable" interface. Writing `Array.sort(data)` in your function means the function won't be usable for any kind of data other than arrays. The other features of OOP like encapsulation, inheritance and abstraction -- these aren't so special. But OO polymorphism is pretty unique.
- mrkeen 6y ago
  I hadn't thought of interfaces (e.g. sortable) as being an OO thing. That said, I do sometimes confuse myself trying to use them in Java, e.g. void foo() { Fruit[] basket = new Apple[] { new Apple(), new Apple() }; handleFruit(basket[0]); } void handleFruit(Fruit fruit) { System.out.println("Do I get called?"; } void handleFruit(Apple apple) { System.out.println("Or do I?"; } If it were runtime polymorphism I'd expect it to dispatch to the apple method, but it dispatches to the fruit method. I also run up against friction trying to define, e.g. the "mappable" interface across these two guys. Can't seem to get it done. class Optional { <U> Optional<U> map(Function<? super T,? extends U> mapper); } class Optional { <R> Stream<R> map(Function<? super T,? extends R> mapper); } For what it's worth, Java went with the polymorphic Collections.sort(data) approach, not the polymorphic data.sort() approach.
  - tpxl 6y ago
    >Collections.sort(data) approach, not the polymorphic data.sort() Since java 8, java.util.List had a sort method and Collections.sort(List) just calls List::sort. Before that, only the Collections.sort method existed. At least from java 6 on, java has a SortedSet and SortedMap that accept comparators as constructor parameters, but have no sort methods (So basically data.sort, not collections.sort(data)). Arrays can of course only be sorted via Arrays.sort, since arrays have no methods.
  - _old_dude_ 6y ago
    Java like C++ or Swift uses single-dispatch polymorphism, so only the receiver (the argument before the '.') is used at runtime. In Java, you can implement your own dispatch table quite easily Map<Class<?>, Consumer<Fruit>> dispatchTable = Map.of(Apple.class, fruit -> handleFruit((Apple)fruit)); Fruit fruit = basket[0]; dispatchTable.get(fruit.getClass()).accept(fruit);
antirez 6y ago
I consider "true OOP" what SmallTalk introduced. And the most fundamental thing in SmallTalk OOP is the encapsulation of complexity in the idea of an object, and the ability to pass messages to such objects that can be other objects, including "blocks". There is more than that to OOP, but I think that the fundamental idea is that code and functions operating on a given software component are defined within the concept of a class, and that objects only communicate with the other parts via messages. From that, a lot of things happen that are not obvious given this simple idea of OOP. For instance every object knows how to turn itself into a string, or to compare it with another one of its kind or of different kinds. And so forth.
- CyberDildonics 6y ago
  What smalltalk introduced is not widely spread, which would imply it is not what the title is about.
  - scroot 6y ago
    Maybe. But the article opens by quoting Dave Robson's article in the 1981 Byte issue and even links to the archived version of the magazine. That issue was entirely dedicated to articles about Smalltalk. Robson's article is also about Smalltalk.
    - igouy 6y ago
      And yet, the "Why is OOP still so widely spread?" article never mentions Smalltalk. Perhaps the author did not wish to admit that even back in 1980, "you [could] have your class Cake and EatCake() it too". [:each :aCake | each eat: aCake]
- dnautics 6y ago
  While that's true historically, SmallTalk has more in common with some functional languages (like erlang) than it does with even Ruby, which is directly a SmallTalk derivate. I think when everyone talks about OOP today they mean the lineage that descended from C++, which broadly is: Java, Javascript, C#, Python, and Ruby, to a lesser extent Go. Contemporary OOP is the enforced semantic association of data with their methods, encapsulation of private data, and shared memory.
bosswipe 6y ago
The advantage of data.sort() over Array.sort(data) is discoverability, especially with autocomplete.
- deleted 6y ago
  [deleted]
collyw 6y ago
data.sort() vs Array.sort(data) I think the first one feels a lot more natural. It also seem to lower the cognitive load of knowing where to find the sort method / function. Is that just because I have used mainly OOP style languages?
- newen 6y ago
  Pretty sure it’s a cognitive bias. The Array.sort method is obviously in the Array module. While to find the sort method, I’d have to find out what class data is in. Probably slightly harder is sort(data) in a language like Julia. The sort method wouldn’t be located inside the class definition and I’d have to run a command like @which sort(data) to find out where sort is defined. All three would be trivial with a decent IDE though.