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