I apologize if I sound harsh, but I do feel the need to correct what I believe to be a few mistakes. Specifically:
but there ain't no rule in functional programming that stops you from making this function, that operates on raw numbers, visible to the whole world. That's why it's not a paradigm.
This is not a valid conclusion. Nothing about being a paradigm requires hiding certain functions. FP has a strong mathematical basis, one that allows for unlimited composition, so it does not need this kind of distinction of complexity and meaning.
Since you are comparing a declarative paradigm exclusively to imperative ones, differences will show up.
Regardless of terminology, your conclusion also seems incorrect to me:
Effectively writing functional code, then, still requires you to make a plan for your software system's architecture beyond "functional design"
This is false if your architecture were truly functional. In that case you'd only need to decide which functions to expose. Getting to a functional architecture is a different matter. I, for one, have never seen one. For instance, using IO monads in Haskell to create a webserver is still a form of imperative programming.
A point I'd like to make about OOP:
I "mutate" the person by returning a new instance with the applied changes
This is not OOP. That requires mutable state, returning a different object is not the same.
In particular, in OOP, A and B may both have a reference to C, if A causes C to change, B will see those changes. In FP, B will not. This is why OOP fails to deliver on its promise of encapsulation whereas FP succeeds.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I second this.
I apologize if I sound harsh, but I do feel the need to correct what I believe to be a few mistakes. Specifically:
This is not a valid conclusion. Nothing about being a paradigm requires hiding certain functions. FP has a strong mathematical basis, one that allows for unlimited composition, so it does not need this kind of distinction of complexity and meaning.
Since you are comparing a declarative paradigm exclusively to imperative ones, differences will show up.
Regardless of terminology, your conclusion also seems incorrect to me:
This is false if your architecture were truly functional. In that case you'd only need to decide which functions to expose. Getting to a functional architecture is a different matter. I, for one, have never seen one. For instance, using IO monads in Haskell to create a webserver is still a form of imperative programming.
A point I'd like to make about OOP:
This is not OOP. That requires mutable state, returning a different object is not the same.
In particular, in OOP, A and B may both have a reference to C, if A causes C to change, B will see those changes. In FP, B will not. This is why OOP fails to deliver on its promise of encapsulation whereas FP succeeds.