7 ms·
This is describing issues and tradeoffs of OOP relative to FP and haskell. It conveniently side steps the fundamental issue with OOP as used in Java or C++ or C
by Geminidog 6y ago
This is describing issues and tradeoffs of OOP relative to FP and haskell. It conveniently side steps the fundamental issue with OOP as used in Java or C++ or C#. I agree with most of what the author says except that his OOP version is basically incredibly hard to read and not intuitive. However that's just my opinion.
The real big problem with OOP in context of the popular definition is the promotion of using logical operations that are not combinators. This makes OOP less modular.
class X:
int b
int c
int d
int x[100000] = {1,2,3,4,5,6,.......}
function addOne(){
return b + c + 1
}
The tradeoff with OOP is convenience. You have b and all the context of X implicitly accessible within the function but addOne cannot ever be used outside the context of X.
To reuse addOne means to recreate the entire context of X. I want a banana but in order to get the banana I must recreate the gorilla holding the banana and the entire jungle the banana is sitting in.
That's what most people complain about even when they don't realize it. In terms of the authors definition of OOP I don't think there's much controversy for that stuff.
- GavinMcG 6y agoDidn't the author address that? > In effect, the major selling point of the “object”-style design here is also a major downside: you don't have guarantees about the specific representation of data, which means your programs can easily mix-and-match different representations, but it also means that your program can't make use of representation-specific knowledge in ways that are advantageous. > There's another major concern as well, and that's that the specific choice of “object” representation can make a big difference in terms of what operations you can and cannot support.
- Geminidog 6y agoThe author is talking about representation of data, I'm talking about something different. I'm talking about scoping, grouping, modularity and free variables. y = 6 f(x) = x + y y is called a free variable and f is dependent on it. I cannot move f to another place because y will now be undefined. OOP is a more extreme version of this. class X y = 6 b = 8 f(x) = x + y Now f can't even be moved to another place without b. If you want to move f you have to move b as well. Combinators vs. free variables is the fundamental issue of OOP which this article writer effectively side steps with a unique definition of OOP where the method returns an entirely new object with differently defined methods. It's ok. It's worth talking about the trade offs of unique definitions of OOP but I think the author needs to mention that this is also not a mainstream definition and therefore sidesteps all the mainstream controversy.
- tcgv 6y agoI'm not sure I uderstand the point you are trying to make here: > To reuse addOne means to recreate the entire context of X. I want a banana but in order to get the banana I must recreate the gorilla holding the banana and the entire jungle the banana is sitting in. If 'banana' is dependent upon 'gorilla' then you're doing OOP wrong, or maybe you didn't need to reuse 'banana' in the first place and took some shortcuts while coding and now that you need you will have to refactor the code and extract that functionality into a new class. Even in the case of inaccessible logic hidden into classes it's entirely possible to extract that code into, say, an utility class that can be reused across several classes. In this case the resulting code may resemble a combination of higher level OOP classes wich take advantage of lower level functional modules for implementing their behavior.
- dnautics 6y agoYes, that's all true, but after even two stages of this you're in the kingdom of the nouns. Note the argument is not structural, but philosophical. Yes, the two constructs are logically isomorphic, but to get composability with objects you must start twisting your brain in uncomfortable ways. I would concede there might be a minority of folks whose brain truly works like this. For the rest, it must be stockholm syndrome.
- Geminidog 6y agoIt's structural. class X: constructor(y=3,z=2) y; z; b = [......] F(x) = y + x F cannot be reused outside of the context of X and z y and b. This is not a philosophical issue but concrete. G(x, y) = y + x Here G has the same exact logic as F but can be reused and is more modular. No philosophy of fuzzy stuff here I am talking about a concrete problem. Philosophical arguments lead to unresolved controversies. I am not going in that direction. I am talking about a concrete issue that can be resolved.
- dnautics 6y agoI think parents posters idea about reuse is that if you need to reuse it, you make it into an abstraction and hoist (copy/paste) to a superclass and make where you took it from a child class. On the one hand, it does make the reuse explicit ("explicit is better than implicit"). Or you broaden the member elements to be able to take a broader interface. On the other hand, this is how you wind up with enterprise java.
- blackrock 6y agoThe other thing about objects like this, is that the members b, c, d, and x, are actually global variables, within that object. Where any other method can overwrite its value at will, unless you force all modifications through another setter method, which will perform the error checking and validation. This is fine, when your object is just a toy object you learn in C++ 101, in school. But it becomes quite unwieldy, when working with actual real world business data. Unless you minimize the footprint of your object.