|
|
|
|
|
by tel
4181 days ago
|
|
Without backing a horse exactly: * FP as I understand it doesn't much oppose imperative or even most of OO. It opposes non-composability using discipline from pure/total languages. * Even if you want to encapsulate data and logic together like you suggest, you only need to buy 10% of OO to get that (ADTs, existential types, modules, what-have-you do it fine if not far better). The remaining 90% may be a waste or actively harmful. * FP, as I practice it, means using the simplest possible thing in a world where simple things compose nicely. This may end up being some kind of full-scale OO, I'm eager to try to find places where it does, but so far it hasn't ever. As a meta note, "my kind of FP" is the Haskell type of purity and other such nonsense. |
|
I think this is definitely true, if you take 'oppose' as 'incompatible'. If we look the design concept and plot them, there will be axes, and I think this is what we'll see.
>* Even if you want to encapsulate data and logic together like you suggest, you only need to buy 10% of OO to get that
That's also true, but it's not an argument against the seed of usefulness of the 10%. We have kitchen sinks because people pick and choose features at will.
>* FP, as I practice it, means using the simplest possible thing in a world where simple things compose nicely.
Same here, and everyone should practice this when they look at any function, or object method, trying to make it as atomic as possible.
> This may end up being some kind of full-scale OO
I don't think it's any more useful shoehorning a program into "everything objects" more than "everything is functions".
My point was to say that the core goal of OOP is a great one, it simply codifies something that people have done in C when they put structs and procedures in the same header file. Let's not throw the baby out with the bath water.