Live data from Hacker News

OOP vs. FP

medium.com

21–30 of 30 posts

Re: OOP vs. FP

#21
post #15
post #6

Earlier quoted context omitted.

Take a class C. Alice extends class C with class A, which implements function a. Bob extends class C with class B, which implements function b. I have both Alice’s and Bob’s code, and I want to use both a and b. How can I do it? Of course, there are ways to do it – notably multiple inheritance, if your language supports it – but the point is, in a functional language, this question never even arises. You just import…

Inheritance is not a strict requirement of OOP. In OOP, you can always use composition, in which case the question also never arises. Inheritance is there if you need it . It's an available option.

Yes, but in common discussion, noone when talking about OOP is referring to inheritence-less OOP. No common programming language uses it, few to no programmers practice it. OOP/w inheritance is the default item being discussed.

Re: OOP vs. FP

#22
post #15

Earlier quoted context omitted.

Inheritance is not a strict requirement of OOP. In OOP, you can always use composition, in which case the question also never arises. Inheritance is there if you need it . It's an available option.

Yes, but in common discussion, noone when talking about OOP is referring to inheritence-less OOP. No common programming language uses it, few to no programmers practice it. OOP/w inheritance is the default item being discussed.

And why is "common discussion" technically relevant? This is not a fault of OOP but of education.

Re: OOP vs. FP

#23

Is this guy talking about OO as described by smalltalk? Because he says that objects are bags of functions, not data, but in languages like java, c# and c++ objects are bags of both.

The C++ family of languages isn't really all that object-oriented; it's practically a different (static, class-oriented) paradigm that takes some inspiration from OOP (mostly from Smalltalk) but more from C's particular implementation of statically-typed procedural programming, as a result they are based around structs-enhanced-with-methods rather than proper objects.

Re: OOP vs. FP

#24
post #3

I don’t wholly disagree with the article, but I think it overstates its case. In particular: > Is there really so much difference between f(o), o.f(), and (f o)? Yes, there is! In the case of o.f(), o needs to know about f. In the case of f(o), f needs to know about o.

In Nim, with its unified function call syntax, there is no difference between them, which is pretty neat.

Re: OOP vs. FP

#25
post #15
post #6

Earlier quoted context omitted.

Take a class C. Alice extends class C with class A, which implements function a. Bob extends class C with class B, which implements function b. I have both Alice’s and Bob’s code, and I want to use both a and b. How can I do it? Of course, there are ways to do it – notably multiple inheritance, if your language supports it – but the point is, in a functional language, this question never even arises. You just import…

Inheritance is not a strict requirement of OOP. In OOP, you can always use composition, in which case the question also never arises. Inheritance is there if you need it . It's an available option.

> in which case the question also never arises.

I'm not sure I see that.

If class A and B wrap a C by composition and expose, respectively, `a` and `b`, then I still very much have the choice of which I'm building. Perhaps less so if they wrap a C by reference, so the C can be reused (it's too late at night to be sure I've thought it all the way through).

Re: OOP vs. FP

#26
post #13

hmm, not so sure I agree to that extent. [To me,] FP is more about nobody owning the data. Everything operating on all the data. (Mostly) All data exposed and accessible. OOP is about certain classes owning data and limiting exposure to that data.

It has nothing to do with ownership. In FP, a function can only operate on data of a particular type. In OOP, a particular type (or class) gathers all the applicable functions (or methods) under one roof. Same difference.

Well, not really.. In effect, your class owns the relevant piece of data that it operates on and only allows pre-defined operations on that data.

Maybe my point is better articulated by saying [to me,] functional programming is more data oriented than OOP.

Re: OOP vs. FP

#27
post #13

Earlier quoted context omitted.

It has nothing to do with ownership. In FP, a function can only operate on data of a particular type. In OOP, a particular type (or class) gathers all the applicable functions (or methods) under one roof. Same difference.

Well, not really.. In effect, your class owns the relevant piece of data that it operates on and only allows pre-defined operations on that data. Maybe my point is better articulated by saying [to me,] functional programming is more data oriented than OOP.

The word "own" is pretty meaningless. What does "own" even mean? Classes and objects (thought of as "types") are an organizing principle for organizing your functions. If you didn't organize them in this manner, then you'd have the same functions that operate on the same data types, only they're scattered everywhere, just like in functional programming.

Re: OOP vs. FP

#28
post #22

Earlier quoted context omitted.

Yes, but in common discussion, noone when talking about OOP is referring to inheritence-less OOP. No common programming language uses it, few to no programmers practice it. OOP/w inheritance is the default item being discussed.

And why is "common discussion" technically relevant? This is not a fault of OOP but of education.

You're talking about about OOP-B, everyone here is talking about OOP-A. OOP-B isn't really a part of what's being discussed.

Anyone can bring it up, but "education" isn't relevant here. It's not what was discussed in the article, or the comments.

Re: OOP vs. FP

#29
post #27

Earlier quoted context omitted.

Well, not really.. In effect, your class owns the relevant piece of data that it operates on and only allows pre-defined operations on that data. Maybe my point is better articulated by saying [to me,] functional programming is more data oriented than OOP.

The word "own" is pretty meaningless. What does "own" even mean? Classes and objects (thought of as "types") are an organizing principle for organizing your functions. If you didn't organize them in this manner, then you'd have the same functions that operate on the same data types , only they're scattered everywhere, just like in functional programming.

> the same functions that operate on the same data types, only they're scattered everywhere

???

OO is different because you have things like private variables. Meaning that only methods of an object's class can access the variable. So you now have a special group of functions that can access the variable. FP is not like that.

Re: OOP vs. FP

#30
post #22

Earlier quoted context omitted.

And why is "common discussion" technically relevant? This is not a fault of OOP but of education.

You're talking about about OOP-B, everyone here is talking about OOP-A. OOP-B isn't really a part of what's being discussed. Anyone can bring it up, but "education" isn't relevant here. It's not what was discussed in the article, or the comments.

As neither of you, I'm talking about OOP. Nobody's limiting the discussion to composition or inheritance. Otherwise we'd be talking about how 'inheritance sucks' rather than 'OOP sucks'.
Post reply on HN