(note to Haskellers: Yeah, I'm handwaving things here, no need to point out counter-examples to my generalisations!)<br><br><div><span class="gmail_quote">On 4/26/07, <b class="gmail_sendername"><a href="mailto:firstname.lastname@example.org">
email@example.com</a></b> <<a href="mailto:firstname.lastname@example.org">email@example.com</a>> wrote:<br>We'll do this one first:<br><br></span><div style="margin-left: 40px;">What are the mysterious "side effects" which are avoided by using Haskell, which
<br>everyone talks about? Null pointers?<br></div><span class="gmail_quote"><br>Side effects are usually things like mutable state. In Haskell variables don't vary. "x=x+1" isn't valid in Haskell. This means, among other things, that functions always do the same thing given the same input (they can't depend on some mutable state changing value), which is great since you'll never get those "oh I forgot that I must first call foo before I call bar, or I'll get an error". This really is a HUGE win, since programming with state is unreasonably error-prone. I'm afraid it's next to impossible to convince anyone that this is true, unless they're willing to give it a serious try, though :-)
<br><br>Null pointers are possible when you're dealing with C functions mostly. You don't use pointers in Haskell normally, only when you're interfacing with external C libraries etc.<br><br></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello,<br><br>what are the advantages of haskell over semi-functional programming languages<br>such as Perl, Common Lisp, etc.?</blockquote><div><br>For me? Purity. I mean you can get plenty of the benefits of FP in any old language (witness C#
3.0), but the one thing you can never get by just adding support for a "functional style" in another language is purity. Once purity is gone, it's gone! It can't be retrofitted on an existing language.<br>
<br>Purity is great because it makes it much easier to write programs without making silly mistakes. When writing programs in languages with lots of side effects you have to sort of keep a "mental log" in your head for all possible execution paths ("in this branch x is equal to y plus w, and this pointer here is null in the other branch x is null and..."). For me I can quite literally *feel* "brain resources" being freed up when using Haskell, which I can use to get stuff done quicker (or probably more accurate: I can feel how much brainpower I waste on book keeping and keeping track of this "mental log" when using languages like C++).
<br><br>Also purity is very interesting when you want to paralellize programs (a pure function can be executed on any thread, at any time, and its guaranteed to never interfer with the computation of other functions -- in impure languages this doesn't hold at all!). This is probably the killer app for functional programming IMO. FP is cool for a number of reasons, but I think "isn't almost unusable in a multithreaded setting" is what sets it apart the most from imperative languages.
<br><br>Haskell also has STM which is great for that low level shared state concurrency that you sometimes need (no locks, monitors, or any of that non-composable, insanity-inducing, messiness!)<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>Aren't Haskell's advantages outweighed by its complexity (Monads, etc.) and<br>rigidity?</blockquote><div><br>I can sometimes feel that Haskell looses out on not being user friendly in the Java sense (i.e. "cut out any feature that can't be understood in five minutes by a chimp"). Some things do take some effort to learn, but there is a huge payoff for it (it's really powerful!). But yeah, there might be plenty of folks who will never bother learning about them, and they won't understand your code.
<br> </div></div><br><br clear="all"><br>-- <br>Sebastian Sylvan<br>+44(0)7857-300802<br>UIN: 44640862