How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
10 plus years* active enterprise development experience and a Fine art degree 🎨
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
10 plus years* active enterprise development experience and a Fine art degree 🎨
Some of the solid principles certainly do apply to FP and OPP that is true. But when I was a junior I used to blindly quote SOLID for everything, not a mistake I wish others to repeat.
Good OOP winds up as functional parts anyway. Why? The Single Responsibility Principle. Ultimately functional programming styles and OOP are the same thing when favoring composition over inheritance.
The whole Inheritance discussion is of much lesser importance; but unfortunately, many articles start off with discussing it.
Traditional inheritance is an advanced topic and not strictly needed or taught in Javascript. This is due to the excellent 'functions as true first class citizens' feature of Javascript.
C# and Java don't treat functions as true first class functions which leads to other solutions. All of which we are too familiar.
Certain problem statements can fit perfectly into design patterns. Design Patterns where entity are considered as objects, are easily resolvable. FP is a great way of solving problems, but not serves all the purpose.
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.
OOP and SOLID is not for everything.
Just a fact that, SOLID makes you a better developer. Something you learn with experience.
Some of the solid principles certainly do apply to FP and OPP that is true. But when I was a junior I used to blindly quote SOLID for everything, not a mistake I wish others to repeat.
Yes. Admit what you are saying.
Good OOP winds up as functional parts anyway. Why? The Single Responsibility Principle. Ultimately functional programming styles and OOP are the same thing when favoring composition over inheritance.
The whole Inheritance discussion is of much lesser importance; but unfortunately, many articles start off with discussing it.
Traditional inheritance is an advanced topic and not strictly needed or taught in Javascript. This is due to the excellent 'functions as true first class citizens' feature of Javascript.
C# and Java don't treat functions as true first class functions which leads to other solutions. All of which we are too familiar.
Certain problem statements can fit perfectly into design patterns. Design Patterns where entity are considered as objects, are easily resolvable. FP is a great way of solving problems, but not serves all the purpose.
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?