I oscillate between using more functional paradigms and more object-oriented ones. is that normal?
I use a linter BTW(TypeScript) if that is a useful info.
I think using both is normal. Closures and objects are duals of each other. Do whatever is understandable and maintainable, neither paradigm is magic.
that's a nice way to look at it. thanks!
Is the duality statement meant to be true in a technical sense?
Yeah! For example, if the language allows closures to capture state, they can act like properties on an instance.
I don't see the duality
A closure is a function with captured state. An object is state with methods.
Avoid shared mutable state like the plague in any paradigm and you'll be fine
state management crying in the corner
Functional state management is fine
I also do that. Very simple stuff, especially of those that are easy to optimize for the compiler, are often very close to functional programming paradigms.
I use a combination of both. Objects are declared const, all members are set in the constructor, all methods are const. It doesn't really work for some types of programs (e.g. GUIs) but for stuff like number crunching it's great.
I heavily use classes while working on back end, and when I'm making a really self-contained logic, such as a logger or an image manipulation service.
but since most frontend stuff heavily leans on functional side, I go with it
I oscillate between using more functional paradigms and more object-oriented ones. is that normal?
I use a linter BTW(TypeScript) if that is a useful info.
I think using both is normal. Closures and objects are duals of each other. Do whatever is understandable and maintainable, neither paradigm is magic.
that's a nice way to look at it. thanks!
Is the duality statement meant to be true in a technical sense?
Yeah! For example, if the language allows closures to capture state, they can act like properties on an instance.
I don't see the duality
A closure is a function with captured state. An object is state with methods.
Avoid shared mutable state like the plague in any paradigm and you'll be fine
state management crying in the corner
Functional state management is fine
I also do that. Very simple stuff, especially of those that are easy to optimize for the compiler, are often very close to functional programming paradigms.
I use a combination of both. Objects are declared const, all members are set in the constructor, all methods are const. It doesn't really work for some types of programs (e.g. GUIs) but for stuff like number crunching it's great.
I heavily use classes while working on back end, and when I'm making a really self-contained logic, such as a logger or an image manipulation service.
but since most frontend stuff heavily leans on functional side, I go with it