You're creating a new definition of paradigm, one that doesn't help anything. Nobody doing OOP believes that everything needs to be OOP. A system will mix a variety of paradigms, trying to find a combination that works well.
You can write entire components in a functional manner, so I don't get how it isn't a structural system. Some components are perfectly structured are pure computations.
I definitely agree. I was having the same thought as I was reading through this.
Anyhow, as you know, functional programming is more than just "I wrote a lambda," the same as object-oriented programming is more than just "I created an object." You can use the tools of any paradigm, but the paradigm itself has more to do with structure than anything, and again, that structure can be a hybrid of any variety of paradigms. (For example, my personal favorite is OOP+Generic).
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.
You're creating a new definition of paradigm, one that doesn't help anything. Nobody doing OOP believes that everything needs to be OOP. A system will mix a variety of paradigms, trying to find a combination that works well.
You can write entire components in a functional manner, so I don't get how it isn't a structural system. Some components are perfectly structured are pure computations.
I definitely agree. I was having the same thought as I was reading through this.
Anyhow, as you know, functional programming is more than just "I wrote a lambda," the same as object-oriented programming is more than just "I created an object." You can use the tools of any paradigm, but the paradigm itself has more to do with structure than anything, and again, that structure can be a hybrid of any variety of paradigms. (For example, my personal favorite is OOP+Generic).
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.