6 ms·

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 d

by 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);
    - pjmlp 6y ago
      In C++ you can fake multi-dispatch, by making use of templates, templates specialization and overloading though. It is just somewhat cumbersome.
- dnautics 6y ago
  > But OO polymorphism is pretty unique It's not. Julia uses multiple dispatch so that you can use the same * operator on integers, floats, complex numbers, quaternions, matrices, matrices of quaternions, galois field elements, and then it's sophisticated enough that if you implement a new type with +, -, /, etc. you can get matrix solving from the standard library for free. So you just implement + - * / on the GF(256) and you can do reed-solomon erasure repair, hell, in quite optimized code trivially without rewriting LU decomposition. Other FPs have solved the polymorphism question in their own ways as well (protocols are a common scheme).
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.

by shados 6y ago

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);
  - pjmlp 6y ago
    In C++ you can fake multi-dispatch, by making use of templates, templates specialization and overloading though. It is just somewhat cumbersome.
dnautics 6y ago
> But OO polymorphism is pretty unique It's not. Julia uses multiple dispatch so that you can use the same * operator on integers, floats, complex numbers, quaternions, matrices, matrices of quaternions, galois field elements, and then it's sophisticated enough that if you implement a new type with +, -, /, etc. you can get matrix solving from the standard library for free. So you just implement + - * / on the GF(256) and you can do reed-solomon erasure repair, hell, in quite optimized code trivially without rewriting LU decomposition. Other FPs have solved the polymorphism question in their own ways as well (protocols are a common scheme).

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.