A collection of my thoughts from using FP extensively in my day job.
Effect is the right way to test side effects (IO)
And we want to test side effects as values; this is something not easily achieved in non FP, and is very valuable
Types that support validation and short-circuit are awesome
Most of real world programs today are handling errors, and most of them handle errors not in a decent manner
Pushing concrete types to the outer boundary of application is a good pattern (i.e. tagless final)
Although it does require multiple components bind to the same F[_]
Converting between different F[_]s is still pretty painful (Edit: use FunctionK, i.e. ~> from cats)
Constructs like MonadError makes code linear (if..else is abstracted away), but does introduce mental redirects
Types mean differently in FP and non-FP world:
in non-FP, you model data with types. eg. classes
in FP, you model both data and logic with types
this provides some benefits as you implicitly trust the abstraction will work, although to me the too-many types still remain the biggest entry barrier or annoyance in levling up FP. (Picking the right type for the job is like solving a puzzle, but not always a fun puzzle)
and sometimes it defeats the purpose of simple, clear, easy-to-understand code.
Please, please, please, stop thinking you are a mathematician. We write programs to solve problems, to create worlds, NOT to feel superior.
(FP = Functional Programming)
A collection of my thoughts from using FP extensively in my day job.
Effectis the right way to test side effects (IO)F[_]F[_]s is still pretty painful (Edit: useFunctionK, i.e.~>from cats)MonadErrormakes code linear (if..elseis abstracted away), but does introduce mental redirects