Programming is not confined to web-development alone.
Real-time embedded programming is all about the side effects. Interacting with digital and analog io, timers, serial and parallel ports, everything interesting is done by calling functions with side efffects.
GUI programming is not a good fit for functional programming
Games; they are easier to manage stateful.
Major difference in FP and OPP:
OPP is stateful to an extent
FP asks to pure; without any side effect, i.e., stateless
As I said, FP is great, not suitable for all problem statements.
Wrong. Every program ever, uses functions or what is called a method in OOP. This is the start of a functional style. There are different definitions of functional styles. We are free to mix and match any of them. This includes pure and non pure, mutatable and non mutatable functions. It includes async and non-async, it includes reactive and non reactive.
Correctly written functions have just one concern and optional mutation. Purity is not mandatory in functional programming.
Functions openly expose parameters which is the interface, which requires an implicit required state to enter. They can advance the state either by mutation or return a non mutated result.
All state is the responsibility of a parent container which composes functions. This, 'controller' is perfect for GUI and any other application merely for following compositional styles.
C# and Java do not have true first class functions, unlike Typescript and Javascript . This makes functional styles more difficult but totally doable in Java and C#, via class based functions or complex classes containing other classes or even static function calls.
So the issue ultimately is a non issue when we choose to really understand and use compositional technique as was recommended in 1985 via the GoF book. 'Favor composition over Inheritance'
When we do this correctly we arrive at the door step of Functional styles. We are free to enter in and dive as deep as we want. Single Responsibility takes us deeper.
In the end there's no difference in Compositional OOP and Functional programming except in articles that like to focus on non compositional polymorphic design versus pure functional styles. It's really a waste of time doing that because there's no similarity nor was there ever intended to be similarity.
The only reason this keeps getting airplay is due to Javascript people disliking any discussion of OOP. They don't even like SOLID and rarely even follow DRY. They don't even like the Class object or the New keywords which are part of their own language.
Good point, asserting that functional style is stateless is harmful and misleading. Functional approach favors immutability, purity, composition, and declarative style. It doesn't mean it’s hard or disallowed to introduce the state. It’s just brought to a minimum. GUI is not a good fit for fp? So what about React which favors immutability? Or Rust as embedded lang?
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.
Not true. How does a method or function not solve a problem?
Programming is not confined to web-development alone.
Real-time embedded programming is all about the side effects. Interacting with digital and analog io, timers, serial and parallel ports, everything interesting is done by calling functions with side efffects.
GUI programming is not a good fit for functional programming
Games; they are easier to manage stateful.
Major difference in FP and OPP:
As I said, FP is great, not suitable for all problem statements.
Wrong. Every program ever, uses functions or what is called a method in OOP. This is the start of a functional style. There are different definitions of functional styles. We are free to mix and match any of them. This includes pure and non pure, mutatable and non mutatable functions. It includes async and non-async, it includes reactive and non reactive.
Correctly written functions have just one concern and optional mutation. Purity is not mandatory in functional programming.
Functions openly expose parameters which is the interface, which requires an implicit required state to enter. They can advance the state either by mutation or return a non mutated result.
All state is the responsibility of a parent container which composes functions. This, 'controller' is perfect for GUI and any other application merely for following compositional styles.
C# and Java do not have true first class functions, unlike Typescript and Javascript . This makes functional styles more difficult but totally doable in Java and C#, via class based functions or complex classes containing other classes or even static function calls.
So the issue ultimately is a non issue when we choose to really understand and use compositional technique as was recommended in 1985 via the GoF book. 'Favor composition over Inheritance'
When we do this correctly we arrive at the door step of Functional styles. We are free to enter in and dive as deep as we want. Single Responsibility takes us deeper.
In the end there's no difference in Compositional OOP and Functional programming except in articles that like to focus on non compositional polymorphic design versus pure functional styles. It's really a waste of time doing that because there's no similarity nor was there ever intended to be similarity.
The only reason this keeps getting airplay is due to Javascript people disliking any discussion of OOP. They don't even like SOLID and rarely even follow DRY. They don't even like the Class object or the New keywords which are part of their own language.
Good point, asserting that functional style is stateless is harmful and misleading. Functional approach favors immutability, purity, composition, and declarative style. It doesn't mean it’s hard or disallowed to introduce the state. It’s just brought to a minimum. GUI is not a good fit for fp? So what about React which favors immutability? Or Rust as embedded lang?