
Ask HN: Should you always prefer pure functions? - crcl
In general, I prefer following functional programming principles. This leads me to default to writing pure functions and only writing impure functions when it&#x27;s absolutely necessary (meaning that the program would not work unless the functions were impure).<p>On the other hand, I try to avoid dogma and assess situations on a case by case basis.<p>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?
======
AnimalMuppet
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.

------
nepeckman
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.

------
a-saleh
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](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.

------
rs86
Yes.

~~~
ljw1001
Absolutely. And no sex unless it's really, truly love.

~~~
rs86
Pure functions can be even better if they are combinators, I mean, no free
variables used. When you have no free variables you have exactly zero
dependencies on any other code unit. It makes your code unit testable to the
extreme.

