FP: Die, side effects!
While reading an article today about what functional programming is, a comment rang true to me about the side-effects that might occur when a function calls a global element, such as a queue:
Can we test this code? Not in isolation. Unlike a circuit board, we can’t just plug into its inputs and check its outputs. We have to break open the code, figure out its hidden causes and effects, and simulate the world it’s supposed to exist in.
Granted, figuring out scenarios is part of testing, but I’ve definitely done setup to get the environment setup to get one edge scenario. Or used TimeCop. Anyway, I’m still wrapping my head around this idea and how I can use it in my current languages going forward. Refactor time!
Or maybe time to learn Haskell? And stop mocking? Anyway, one last thought from the comparison article on which languages are functional. There are two great bits about functions with no arguments and functions with no return value:
No Arguments Signal Side-Causes
No Return Value Signals Side-Effects
So in Ruby, when counting the methods of an array the function call might be:
[1, 3, 7].count
The count function operates on the inline-declared array, so technically it has a hidden input or side-cause of the array. But a functional language like Elixir? Try a function for that with a defined input and output!
list = [1, 2, 3]
This seriously feels backwards compared to the OO and Java basis that I began with. Time to stretch the mental muscles some more!