<blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"><font size="4" face="LM Mono 12"><font size="4" face="LM Mono 12">I won't mention
the name so as not to offend anyone.</font></font></blockquote><br>Oh I'm sure we can handle it ;)<br>Though I'm curious as to how a language could be effect free in a practical sense, but not a strict one? could you give an example?<br>
<br><br>To answer your original question, there are many benefits haskell gains from being a pure language. (And by pure I mean that functions have no side effects, they can only give data to their environment via their return value). I think the my biggest reason (though there are probably others) is as follows:<br>
<br>Pure code is easier to reason about than impure code:<br> When I program for work (we use ada, ick) and I find that a function is returning a bad result it is very difficult to figure out where the malfunction is. Is the function itself the problem? incorrect parameters? some global flags setup incorrectly? Did I need to call another function to setup state before I called this one? In a pure language I can just check the function inputs. Are they good?
if yes, then the problem is in the function, if no, then follow the
value up the chain, etc...<br> A simpler case would be a single variable in a large function. Say I trace a bug down to a bad value in a particular variable in a big function. I have to look at every place that the variable is modified in the function as well as any places where the variable is passed to other functions by reference _as well as_ the control flow from those mutations to the usage of the variable in question. In a pure language If a variable doesn't have the correct value
I check the definition (there can only be one)<br>Data flow in a pure language is so much easier to follow/understand and you never have to worry about the order of execution (which is what makes it easy to implement lazy evaluation).<br>
<br>I have literally debugged _hundreds_ of errors in our codebase at work that would _not have even been possible_ in a pure language.<br><br>The downside to purity is that sometimes it's slower (though this is becoming less and less of an issue, sometimes it's even faster) and sometimes it's much easier to mutate some state than pass a value back up a big chain. But overall I much prefer purity, it make my life so much easier.<br>
<br><br>- Job<br><br><br><br><div class="gmail_quote">On Thu, Dec 10, 2009 at 11:15 AM, John D. Earle <span dir="ltr"><<a href="mailto:JohnDEarle@cox.net">JohnDEarle@cox.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="padding-left: 10px; padding-right: 10px; padding-top: 15px;" name="Compose message area">
<div><font size="4" face="LM Mono 12"><font size="4" face="LM Mono 12">To elaborate
there is another language that is also a functional language. I won't mention
the name so as not to offend anyone. It too is effect free, that is what makes
it functional and it is a functional language in the true sense of the term, but
it is not effect free in the sense that Haskell is effect free. This other
language is effect free in every practical sense whereas Haskell is effect free
in a strict sense.</font></font></div></div>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br>