> It’s not as if functional programming is newer or untested.
It's not about maturity. It's about suitability for the purpose.
FP is probably not ever going to be easier to use, but it is safer, and can be used to safely implement algorithms of greater complexity than other paradigms.
It needs to be coupled with a reactive, event-driven system (that has state, but the state can be hidden in end nodes or a model), in order to deliver a great UX; which, at the end of the day, is what this is all about.
You can't have UX without state. It's all about where the state is maintained, and how many copies of it need to be made, as the program executes.
For example, say we have a checkbox that reflects/controls the state of a variable in our calculation. The on/off state is important. If it is on, let's say that we will introduce a compensating coefficient. If it is off, that coefficient is not applied to the function.
The state is not a part of the function, so it doesn't make sense to incorporate it (or even knowledge of the existence of that state) into the function.
Nevertheless, it is a crucial component of the user experience, and needs to be maintained somewhere.
The best bet may be to try to keep the state in the checkbox object, itself, and query it at runtime, or use a messaging system to be informed of state changes. I've always found a central model to be annoying. If the UX is at all complex, the model can get crazy, and turn into a richly productive bug farm.
Federated/franchised state can have its own issues, like when there's a lot of interaction/dependency between state nodes. That can get crazy, too, and difficult to debug.
So far, no one has come up with a perfect pattern, but I kind of like the idea of a "composer" pattern, that queries federated states, and "weaves" them together, at runtime, as opposed to a model that sends directives out to a set of nodes.
The issue that lots of folks have with OO, is polymorphism. That is not really the same thing. It can make discovering an algorithm difficult, as functionality can cascade through a whole bunch of levels, and debugging can be a real pain in the butt. If anyone has had sticky CSS specificity issues, they have an idea of what it can be like to grope around in a polymorphic codebase.
Protocol-oriented programming is not a panacea, either. This is especially true, when mixed with polymorphism. I wrote about a strange issue I encountered, here[0].
But polymorphism isn't bad. It's just a tool, and we don't use a nailgun as a hammer. Like so many tools, people have tried to shoehorn it into unsuitable configurations, and refuse to consider other, more suitable tools. I see FP proponents, doing the same thing.
Swift is nice, because it has a rich toolbox, allowing us to select the right tool, for the right job, without having to do complex linking games between libraries of different languages.
It's not about maturity. It's about suitability for the purpose.
FP is probably not ever going to be easier to use, but it is safer, and can be used to safely implement algorithms of greater complexity than other paradigms.
It needs to be coupled with a reactive, event-driven system (that has state, but the state can be hidden in end nodes or a model), in order to deliver a great UX; which, at the end of the day, is what this is all about.
You can't have UX without state. It's all about where the state is maintained, and how many copies of it need to be made, as the program executes.
For example, say we have a checkbox that reflects/controls the state of a variable in our calculation. The on/off state is important. If it is on, let's say that we will introduce a compensating coefficient. If it is off, that coefficient is not applied to the function.
The state is not a part of the function, so it doesn't make sense to incorporate it (or even knowledge of the existence of that state) into the function.
Nevertheless, it is a crucial component of the user experience, and needs to be maintained somewhere.
The best bet may be to try to keep the state in the checkbox object, itself, and query it at runtime, or use a messaging system to be informed of state changes. I've always found a central model to be annoying. If the UX is at all complex, the model can get crazy, and turn into a richly productive bug farm.
Federated/franchised state can have its own issues, like when there's a lot of interaction/dependency between state nodes. That can get crazy, too, and difficult to debug.
So far, no one has come up with a perfect pattern, but I kind of like the idea of a "composer" pattern, that queries federated states, and "weaves" them together, at runtime, as opposed to a model that sends directives out to a set of nodes.
The issue that lots of folks have with OO, is polymorphism. That is not really the same thing. It can make discovering an algorithm difficult, as functionality can cascade through a whole bunch of levels, and debugging can be a real pain in the butt. If anyone has had sticky CSS specificity issues, they have an idea of what it can be like to grope around in a polymorphic codebase.
Protocol-oriented programming is not a panacea, either. This is especially true, when mixed with polymorphism. I wrote about a strange issue I encountered, here[0].
But polymorphism isn't bad. It's just a tool, and we don't use a nailgun as a hammer. Like so many tools, people have tried to shoehorn it into unsuitable configurations, and refuse to consider other, more suitable tools. I see FP proponents, doing the same thing.
Swift is nice, because it has a rich toolbox, allowing us to select the right tool, for the right job, without having to do complex linking games between libraries of different languages.
[0] https://littlegreenviper.com/miscellany/swiftwater/the-curio...