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]
length(list)

This seriously feels backwards compared to the OO and Java basis that I began with. Time to stretch the mental muscles some more!

A single golf clap? Or a long standing ovation?

By clapping more or less, you can signal to us which stories really stand out.