Found this new (to me) FP library called Sanctuary.
It has total functions; unlike Ramda/Lodash it validates types at runtime; no need to check for the correct data type before using functions.
It makes intelligent decisions around results being ADT’s. You get back a Maybe for things in Lodash that would report a String or undefined. A lot more clear and something you’d end up probably wrapping yourself anyway.
Currying: Only 1 Arg Per Function
add(1, 2, 3) vs
add(1)(2)(3) helps them out a lot to learn.
Throws For Wrong Type
This kind of makes me rage is what they call invariants. Meaning, if you pass in the wrong type, it throws. Now, during unit testing + manual testing at runtime, this can help suss out bugs even if you’re using typings via Flow/TypeScript, etc. However, throwing Errors is a side effect, and it blows my mind a group smart enough to create Sanctuary would do this. Good news, tho, you can turn it off, heh!
Read more about Sanctuary.
In my journey to learn functional programming and drink deep of the kool-aid, I wanted to share my latest learnings. Specifically around the quest for no errors and how you get things.
After reading this article, you should understand why errors aren’t helpful embedded in your code & avoiding them is good and why we use functions to get things instead of the old way of assigning variables. Check out the first article if you missed it.
Continue reading “Functional Programming for OOP Developers: Part 2 – No Errors and Getting Things”
Yeah yeah yeah, tl;dr; and show me the code, yo!
I have been learning Functional Programming over the past year with a friend of mine. We’ve both cut our teeth on finding who to learn from, what articles are useful, and what actually translates into your day to day programming job. I’ve also learned a lot of natural problems that arise as you start a new project from scratch with an OOP background, or if you’re refactoring some OOP code to be more functional.
Continue reading “Functional Programming for OOP Developers: Part 1”