Now we've got some structure into this (just to keep Dijkstra happy) we can perform a fair comparison.
Both of these functions are 'pure'.1 They are both stateless, returning the same value for the same set of arguments. They do not mutate state - they have no effect upon any value outside of the function.
to their consumers they do the same thing
They don't only 'do' the same thing, they are indistinguishable. Other than the imperative one is faster. You do the maths.
The point is, the loop breaks referential transparency, which means that you have opened up the possibility for a class of errors that misuse it.
The loop does break referential transparency. But the solution as a whole doesn't. Do you know what else breaks referential transparency:
Nice, thanks for the great discussion, and I agree with your points, as always nothing is black and white, both paradigms have benfits, and yes FP can be daunting, I'm very lucky to have landed my dev job at a company with a strong FP community so have a lot of people around me to learn from.
One question, in regards to the filter function not being referentially transparent, could you make it so like this?:
itemToSearch is still closed over by the lambda (i.e. it's not one of its arguments).
Before I get into this - I really wouldn't do this in real life! It's fine that the lambda closes over itemToSearch. I'm only doing this because it's fun and I enjoy FP :D.
But since you asked... one way of handling this - if you really, really only wanted pure functions everywhere - would be to pass itemToSearch as an argument and return the friendFilter function, essentially currying the function:
Whew - some fine responses!
Let's do this!
here's the one with imperative guts:
and here's one with functional guts
Now we've got some structure into this (just to keep Dijkstra happy) we can perform a fair comparison.
Both of these functions are 'pure'.1 They are both stateless, returning the same value for the same set of arguments. They do not mutate state - they have no effect upon any value outside of the function.
They don't only 'do' the same thing, they are indistinguishable. Other than the imperative one is faster. You do the maths.
The loop does break referential transparency. But the solution as a whole doesn't. Do you know what else breaks referential transparency:
Yup, that there lambda don't get
itemToSearch
as an argument... I guess it's not functional. But the solution as a whole is.Anyway, obligatory xkcd comic:
schoolofhaskell.com/school/startin... ↩
Nice, thanks for the great discussion, and I agree with your points, as always nothing is black and white, both paradigms have benfits, and yes FP can be daunting, I'm very lucky to have landed my dev job at a company with a strong FP community so have a lot of people around me to learn from.
One question, in regards to the filter function not being referentially transparent, could you make it so like this?:
Classy! But It still involves a non-referentially transparent function.
itemToSearch
is still closed over by the lambda (i.e. it's not one of its arguments).Before I get into this - I really wouldn't do this in real life! It's fine that the lambda closes over
itemToSearch
. I'm only doing this because it's fun and I enjoy FP :D.But since you asked... one way of handling this - if you really, really only wanted pure functions everywhere - would be to pass
itemToSearch
as an argument and return thefriendFilter
function, essentially currying the function:Lambda and currying make a great way to add data into your functions as and when its needed.
small refactor:
stupid why-oh-why refactor:
Ridiculous, please-make-it-stop refactor
If you enjoy this madness, might I recommend reading some books about the Scheme programming language.
Haha nice, I actually work with Scala day to day and a lot of code ends up looking similar to the second last example (with types).
Thanks again mate :)
Thanks for sharing all your insights (all of you), I will have a closer look at them.