News for hackers. Stuff that matters.
Re:“Mostly functional” programming does not work (2014) by viraptor on Monday June 22, 2015 @09:52AM (#9758284)
I've been very excited by many approaches before, then Haskell, and now I'm past it. While pure functional language will force you to cleanly separate computation and IO, with an app big enough you'll find yourself one day in a situation where independent data from 3 different places comes together in a way that the only reasonable way to proceed is to log a warning, tweak the value, and continue the computation. And that's what you'll do in any unpure language. In a pure one, you'll start to think how to redesign the computation to allow this... It's not wrong, but in many cases it's pointless.
Re:“Mostly functional” programming does not work (2014) by TazeTSchnitzel on Monday June 22, 2015 @10:03AM (#9758352)
> In a pure one, you'll start to think how to redesign the computation to allow this... It's not wrong, but in many cases it's pointless.

Are you sure it's pointless? Having to show I/O in the type signature means you can't end up with accidental side-effects.

Re:“Mostly functional” programming does not work (2014) by viraptor on Monday June 22, 2015 @10:12AM (#9758415)
In some cases - yes, pointless. You rarely care if a function logs something or not. If you do care, you can still return the log lines as an extra value and use the pure solution. At least you have a choice.
Re:“Mostly functional” programming does not work (2014) by marcosdumay on Monday June 22, 2015 @03:40PM (#9760685)
You either add the logs as type annotations, or you run it inside a logging monad (not IO).