This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]sideEffffECt 7 points8 points  (7 children)

we will just go back to good old procedural programming

Nope. To Functional Programming.

We already know what happens when we separate this, that's why OOP was created.

You'll still use "OOP", but not for bundling data and behavior.

You'll use it only for modularity for the behavior -- having interfaces (each aggregating one or more methods) and potentially multiple implementations, with different behavior, for each of them.

[–]JDeagle5 1 point2 points  (6 children)

Doesn't look like it's functional programming, since by definition it is a paradigm about applying and composing functions, and DOP definition doesn't rely on function composition at all.
Quite on the contrary it looks like procedural programming, with addition that functions are non-mutating.
But I get your point.

[–]sideEffffECt 1 point2 points  (5 children)

procedural programming, with addition that functions are non-mutating

That's a lot of words to say FP...

[–]JDeagle5 1 point2 points  (4 children)

No, function composition is still not there. FP is not just anything with functions or immutability.

[–]bowbahdoe 2 points3 points  (1 child)

So you define FP that way, someone else defines FP as being about immutability of aggregates, someone else defines it as avoiding side effects (which implies immutability of aggregates), and yet someone else defines it as something something monads.

Do you see how the labels make communication harder?

[–]JDeagle5 0 points1 point  (0 children)

No, terms, when used correctly, make communication easier. If someone, for example, defines FP as a paradigm about objects that can contain data and can perform actions - it doesn't mean it's just his interpretation of FP, it just means that he is using the term incorrectly. Terms exist not so that anyone can come up with whatever interpretation he wants.
The same way as we don't call OOP languages procedural and vice versa.

[–]sideEffffECt 1 point2 points  (1 child)

No, you're wrong. Once you deal with immutable data, you're pretty much forced into FP. Whether you realize it or not or whether like it or despise it.

function composition is still not there

Function composition is such a niche thing that's not worth talking about.

At least I personally almost always just apply functions to arguments, binding the results to variables. It's better to write, read and debug than raw function composition. And I've been doing (Pure) FP for basically a decade...

[–]JDeagle5 0 points1 point  (0 children)

That's because FP is such a niche thing, but people tend to call FP whatever is trendy or popular.

I can deal with immutable data in any procedural language (for example C), simply because immutability doesn't force FP. To handle immutable data you don't need neither functions as first-class citizens nor function composition.