On Saturday, 28 April 2012 at 23:41:29 UTC, Peter Alexander wrote:
But in D the main purpose of "pure" is not as optimization
tool, but more as a tool to enforce a better coding style,
that makes code understanding (and testing simpler), and helps
avoid some bugs, coming from using variables from outer scopes.
True, but I'm quite happy to write pure functions without the
static checking. I do not believe that the safety provided by
the static checks outweighs the development cost of ensuring
you have the correct qualifiers everywhere.
Maybe you don't feel the benefit because you have less bugs in
multithreaded applications than you would without, but you can't
really know unless you do write the same code without ? Or
something like that. :o)
Anyway, I have the feeling that it's very hard to quantify the
benefits of adding purity vs not having it. The benefits are both
very theoretical, and practically verified in functional
languages everyday. But knowing that the compiler *guarantees*
certain properties and that some classes of errors cannot happen
helps coding with a certain peace of mind, i.e you *know* that
some bad things can't happen. So it's a little pain to satisfy
the static checking of the compiler, but it's still much better
than having to debug random race conditions that happen once in a
while in production and are thus very hard to reproduce, and it
does certainly help when you have to *ensure* that your critical
code can never hang.
