4 ms·

Look I get that many people like to make these broad statements about the quality of one model vs the other, when the reality is that they do better for differe

Look I get that many people like to make these broad statements about the quality of one model vs the other, when the reality is that they do better for different things. OOP works really well for abstracting and creating easy to read and write code. Functional Programming works much better for data science related tasks. The truth is both are here to stay, and that is a good thing.

emsy 10y ago
Well put. Programming paradigms shouldn't be an ideology but a tool. Too often did I see FP evangelists abuse FP as an excuse to write "academic" code.
Chris2048 10y ago
I can't see that this is true - how is OOP better at abstraction? Or readability?
- theaustinseven 10y ago
  OOP abstracts pieces of functionality into objects, which is closer to how we view the real world. It is often much easier to think about code that has been abstracted into objects, given that good abstractions have been made. This makes code re-usability more well organized. This all breaks down, however, when the task at hand is not well suited to OOP(think data science). If the number of abstractions per amount of code gets to be too great than OOP starts to become somewhat detrimental. In this case Functional would be easier to read and have more efficient abstractions.
  - Chris2048 10y ago
    I think the first point is precisely why OOP is dangerous: https://en.wikipedia.org/wiki/Reification_(fallacy) https://en.wikipedia.org/wiki/Reification_(fallacy) It may be initially easier to model a problem with 'Nouns', but this won't necessarily reflect the structure of the implementation, which is what I think the code should reflect. http://homepage.ntlworld.com/christopher.mallagh/INCKy/OrgPrelIntro/Intro/PlatFal.html http://homepage.ntlworld.com/christopher.mallagh/INCKy/OrgPr... Sometime the abstractions aren't quite as perfect in their implementation as modelled in the mind. Then you realise you need to model implementation differently from domain, and the difference between the two can cause issues (leaky abstractions, shared-encapsulated state, etc). To put it another way, information should be communicated using concepts from the way people thing about the problem, and the code can communicate this, but the actual structure of the code should reflect the implementation. the same kind of thing that can happen in ORMs wrt the actual difference between object-hierarchy structures, and relational database structures...

emsy 10y ago

Well put. Programming paradigms shouldn't be an ideology but a tool. Too often did I see FP evangelists abuse FP as an excuse to write "academic" code.

Chris2048 10y ago

I can't see that this is true - how is OOP better at abstraction? Or readability?

theaustinseven 10y ago
OOP abstracts pieces of functionality into objects, which is closer to how we view the real world. It is often much easier to think about code that has been abstracted into objects, given that good abstractions have been made. This makes code re-usability more well organized. This all breaks down, however, when the task at hand is not well suited to OOP(think data science). If the number of abstractions per amount of code gets to be too great than OOP starts to become somewhat detrimental. In this case Functional would be easier to read and have more efficient abstractions.
- Chris2048 10y ago
  I think the first point is precisely why OOP is dangerous: https://en.wikipedia.org/wiki/Reification_(fallacy) https://en.wikipedia.org/wiki/Reification_(fallacy) It may be initially easier to model a problem with 'Nouns', but this won't necessarily reflect the structure of the implementation, which is what I think the code should reflect. http://homepage.ntlworld.com/christopher.mallagh/INCKy/OrgPrelIntro/Intro/PlatFal.html http://homepage.ntlworld.com/christopher.mallagh/INCKy/OrgPr... Sometime the abstractions aren't quite as perfect in their implementation as modelled in the mind. Then you realise you need to model implementation differently from domain, and the difference between the two can cause issues (leaky abstractions, shared-encapsulated state, etc). To put it another way, information should be communicated using concepts from the way people thing about the problem, and the code can communicate this, but the actual structure of the code should reflect the implementation. the same kind of thing that can happen in ORMs wrt the actual difference between object-hierarchy structures, and relational database structures...