[leafboi]

I've found that FP using function composition or other higher order forms of function like composition mitigates the design problem that you and many others complain about.

Essentially in FP you design your entire program as a single immutable function expression that's made out of a pyramid of layers that's constructed of smaller closed lego like functions composed together. People in the FP world call it the point free style.

The type signatures guide the architecture of your program and can easily be replaced decomposed or recomposed into higher or lower forms of abstraction without compromising your overall program. Design comes naturally like building something out of legos... Easily configurable, and minimal planning or need to hold the entire program in your head. If the design is wrong like legos your program is easily reconfigurable.

The main factor that allows lego like design is immutability. A lego that mutates state outside of its own scope is a lego piece that cannot be modular. FP by making everything immutable makes your program legos all the way down meaning your smallest primitive can likely be broken down further to reuse in other places and recomposed to form other higher order abstractions that are easier to reason about. In both OOP and procedural programming your designs can never have this level of flexibility due in to modules being tied together by shared mutable state.

Of course there are costs to immutability: both low level costs such as memory management and high level costs such as graph algorithms that require mutability to be effective. There are ways to deal with these issues but they are not trivial. In the end all FP programs must "cheat" in some way and have a small portion of their program actually mutate something.

Overall though, in all my years of programming I have found FP to be the best overall answer to the design problems that most programmers run into. It's by no means a perfect answer but it is the best I've seen and unfortunately not applicable to all domains.

[fsloth]

Agree FP is great as you exposed for a large category of tasks. Agree it is not suitable for some fields, and hence, not a panacea.

FP offers a better syntax for most of the programs I write, hence it makes the initial effort easier. Especially "compiler like" or "interpreter like" programs more often than not just fall into a pit of success.

But still - my original point remains. I am unable to design a program beforehand. The iteration is just faster with FP.

On one point I disagree: " In both OOP and procedural programming your designs can never have this level of flexibility due in to modules being tied together by shared mutable state."

There is nothing that stops one from writing most OO or procedural programs using immutable style. In fact, this style makes those programs better as well. Just try it. Never mutate an object. Each method, if they must mutate something, then let them return a new object instead.

This style is not applicable everywhere, and due to lack of garbage collected immutable datastructures in the C++ basic library, for example, the area where immutable style can be used is smaller than in a FP language.

And you can't use it in those cases naturally where you actually need to mutate existing storage. But, say, an array of 10 elements? Immutable! Most strings smaller than n * 1000 chars? Immutable! Etc.

[leafboi]

I agree with everything you said. To address the part we disagree though:

>On one point I disagree: " In both OOP and procedural programming your designs can never have this level of flexibility due in to modules being tied together by shared mutable state."

When I define OOP I define it as mutable state. The main reason is because there's a equivalence when you do "immutable OOP"

  object.verb(parameter)

is no different than:

  verb(object, parameter)

Because both features are equivalent I would say neither feature is OOP and neither feature is really FP.

The difference is (mostly) syntactic sugar and it won't change the structure of your programs overall.

That being said:

  object.setter()

has no equivalence to FP and is unique exclusively to OOP. Even the vocabulary: "setters" is unique to OOP. Hence following this logic, if you're doing OOP your code will have methods and "setters" that mutate or set internal state. If you're doing FP your code should be devoid of such features.

In fact if you do regular procedural C-style programming with immutable variables your code also becomes isomorphic to FP as assignment becomes equivalent to just creating macros for substitution in an otherwise functional expression.

immutable procedural

  def add(x, y):
     doublex = x * 2
     doubley = y * 2
     return doubley + doublex

functional:

  def add(x, y):
     return y * 2 + x * 2

haskell (functional):

  add x y = let doublex = x * 2,
                doubley = y * 2
            in doubley + doublex

also haskell:

  add x y = (y * 2) + (x * 2)

Due to the fuzziness in boundaries there's really only a few things that are hard differentiators between the three styles. When you examine the delineation and try to come up with a more formal definition of each programming style you will find that FP is simply defined as immutable programming, OOP is defined as a programming style that uses subroutines to modify scoped external state and procedural programming involves programming that can mutate variables in all scopes from local, external to global. There's really no other way to come up with hard barriers that separates the definitions and stays in line with our intuition.

It's all semantics either way and most people do a bit of a hybrid style of programming without ever thinking about what are the real differences so it's not too important.

The thing that's sort of bad about OOP is that it sort of promotes a style of programming where subroutines modify external state that's scoped. You tend to get several subroutines that modify some member variable and this is what prevents you from ever reusing those methods outside of that shared state. <= This is in fact the primary area of "bad design" that most people encounter when doing OOP programming... shared state glues all the lego bricks together making your code inflexible to counter the inevitable changes and flaws that you can never anticipate. The other issue is people never realize that this is what's wrong with their program. They blame their initial design as incorrect when really it analogous to saying that their initial lego project was incorrect and they should have glued the bricks together a different way. The primary key to fixing this design problem is to NOT glue your bricks together at all!

While even though you're capable of the above antics in procedural programming... in procedural programming most programmers tend to keep the mutations scoped to within the boundaries of the function definition hence keeping the function reusable. The downside of this is that if you have shared state within the scope of your function it becomes harder to decompose your function into smaller functions because shared state glues all your internal instructions together.

It's easy to see this face in functional reduce. Higher order functions like reduce allow you to break out the function that actually reduces a list while a for loop with a mutating accumulator can not be broken into further smaller functions.

compare the two below:

loop decomposed into two reusable functions (reduce and add):

  add = (acc, x) => x + acc
  m = reduce(add, [1,2,3])

  m => 6

not decomposable by virtue of mutating accumulator:

  m = [1,2,3]
  acc = 0
  for(int i = 0; i < m.length; i++){
     acc += m[i]
  }

  acc => 6

[fsloth]

Again we disagree :)

"if you're doing OOP your code will have methods and "setters" that mutate or set internal state"

I don't think there is nothing in OOP that "forces" you to explicitly mutate state. People just happen to do it that way, even if there was no need for that.

I.e. instead of mutating an instance of class Foo

void Foo.set(Some bar)

There are several patterns that make instance of Foo immutable. As an example:

1. Use just 'Factory' pattern to build state and disregard mutation altogether FooFactory fact; fact.AddBar(Bar bar); Foo foo = fact.build();

This may appear as mutating (the factory) but the point is the mutations are located at the factory, which is expceted to have a limited scope, and the entity with larger scope (Foo) is immutable wihtout setters.

2. If there is need to modify existing state, instead of mutating the instance, return a new instance with the value modified. So instead of

void foo.Set(Bar bar)

Use method that creates a copy of foo, modifies state, and then returns a new instance of Foo

Foo foo.Modify(Bar bar)

Just removing mutability actually goes long way in making programs more legible akin to functional programs.

I agree functional style is often the best. Unfortunately we just don't have a functional language that could replace C++.

[leafboi]

>I don't think there is nothing in OOP that "forces" you to explicitly mutate state. People just happen to do it that way, even if there was no need for that.

I never said it forces you to do this. Please read my post carefully.

Let me repeat what I wrote. I'm saying that FP and OOP have blurry definitions that people have an intuition about but have not formally defined. Immutable OOP is can be called FP and vice versa. What is the point of having two names for the same style of programming? There is no point that's why you need to focus in on the actual differences. What can you do in OOP that absolutely makes it pure OOP that you cannot call it FP?

That differentiator is setters and mutators. If you use setters and mutators you are doing OOP exclusively and you are NOT doing FP. My response to your post is mostly talking about this semantic issue and why you need to include mutation in your definition of OOP. Otherwise if you don't than I can say all your descriptions of patterns to me are basically FP. You're following the principles of FP and disguising it as OOP and confusion goes in circles.

Please reread my post, I am aware of OOP and it's patterns so there's no need to explain the Factory pattern to me. I'm also in agreement with you like I said.

I am talking about something different: semantics and proper definitions, you likely just glossed over what I wrote, that's why your response is so off topic.

[cannabis_sam]

> That being said object.setter() has no equivalence to FP and is unique exclusively to OOP.

What about Lens.Setter? (http://hackage.haskell.org/package/lens-4.19.2/docs/Control-... )

[leafboi]

That's not mutating anything. It's not a true setter.

[cannabis_sam]

But maybe it’s a true scotsman..?