Ask HN: Should you always prefer pure functions?
6 comments
Pure functions are easier to understand. They're easier to prove correct. They're easier to test, either manually or with unit tests. They're easier to use without surprises.
On the other hand, as someone said here, "Real programs have state". (I searched for that comment, to give credit where due, and couldn't find it.) Especially in my field (embedded systems), programs have to track and remember the state of the external world, and programs do things that change the state of the external world. So "compute best trajectory to the ball" can be a pure function, but "grab the ball" cannot.
In my world, so many of my functions cannot be pure that I don't pay much attention to it. That's my world; it may well not apply to you.
> Are there cases when you would prefer _not_ to write pure functions even when you could, or should you always prefer pure functions? In either case, why?
I will not jump through hoops in order to write pure functions. I will not run through a monad in order to not write to a log file in a function, for example. I don't care about purity for purity; I care about purity to the degree that it helps me, and no further.
> On the other hand, I try to avoid dogma and assess situations on a case by case basis.
I think that's the right approach. Where it helps you, use it. If you run into a situation where it doesn't help you (or gets in the way of something that would help you more), well, you aren't a slave to the high priests of functional programming. Do whatever will work best for your situation.
On the other hand, as someone said here, "Real programs have state". (I searched for that comment, to give credit where due, and couldn't find it.) Especially in my field (embedded systems), programs have to track and remember the state of the external world, and programs do things that change the state of the external world. So "compute best trajectory to the ball" can be a pure function, but "grab the ball" cannot.
In my world, so many of my functions cannot be pure that I don't pay much attention to it. That's my world; it may well not apply to you.
> Are there cases when you would prefer _not_ to write pure functions even when you could, or should you always prefer pure functions? In either case, why?
I will not jump through hoops in order to write pure functions. I will not run through a monad in order to not write to a log file in a function, for example. I don't care about purity for purity; I care about purity to the degree that it helps me, and no further.
> On the other hand, I try to avoid dogma and assess situations on a case by case basis.
I think that's the right approach. Where it helps you, use it. If you run into a situation where it doesn't help you (or gets in the way of something that would help you more), well, you aren't a slave to the high priests of functional programming. Do whatever will work best for your situation.
Where functional programming really shines is in large, complicated codebases. Pure functions helps you reason about code and the way different pieces of code interact. This is probably controversial, but I think that for scripts/small applications, imperative programming is probably easier. If the scope is small enough that I can keep track of the state in my head, the primary benefit of functional programming is not as useful. And if you're dealing with a simple problem, its probably an easy mapping from problem domain to imperative program. Though again, this is a pretty small set of programs. Anything large needs to handle state, and pure functions is a great way to do that.
Somewhere I heard that 80% pure 20% impure is a good sweet-spot. I think I read it somewhere on this blog: https://prog21.dadgum.com/56.html but it does kinda ring true.
What I experienced more, is that function to be state-less is more important than it to be pure. And many functional languages (i.e. erlang or clojure) don't really have a way to curb I/O, but they have strong primitives for dealing with mutable-state or they forbid-it altogether.
What I experienced more, is that function to be state-less is more important than it to be pure. And many functional languages (i.e. erlang or clojure) don't really have a way to curb I/O, but they have strong primitives for dealing with mutable-state or they forbid-it altogether.
Yes.
On the other hand, I try to avoid dogma and assess situations on a case by case basis.
Are there cases when you would prefer _not_ to write pure functions even when you could, or should you always prefer pure functions? In either case, why?