Re:“Mostly functional” programming does not work (2014)
by viraptor on Monday June 22, 2015 @10:07AM
(#9758381)
Why should anything calling f2 care whether it can produce a warning or not? If the contract is simple - return a value, then that's all we normally care about.
If logs are not convincing, then think about profiling. One day you want to know what kind of values are computed by some function. Same story: impure adds stats.record(x), pure requires IO redesign.
Re:“Mostly functional” programming does not work (2014)
by TazeTSchnitzel on Monday June 22, 2015 @10:12AM
(#9758416)
> Why should anything calling f2 care whether it can produce a warning or not? If the contract is simple - return a value, then that's all we normally care about.
What if you call f2 multiple times? What if you call f2 an unpredictable number of times? What if you call f2 in a situation where the logging system isn't initialised?
The parameters and return value are not the only things that matter.
Re:“Mostly functional” programming does not work (2014)
by viraptor on Monday June 22, 2015 @10:24AM
(#9758498)
Simplest situation in order: multiple logs, multiple logs, default uninitialised log behaviour.
These aren't situations specific to the pure/not issue. You have to know how you deal with them in either case. The uninitialised case it a specific case of: what if your logging target goes away / never existed. Signatures won't help here, because that's a dynamic property of the system.
Are you sure you don't? This means that anything calling your function now produces log entries, but it's not obvious without reading its code.
Allowing side-effects saves you time now, but you might hate yourself later when trying to figure out why code in one part of your codebase is magically affecting code in another part.