[Haskell] Newbie: what are the advantages of Haskell?

Sebastian Sylvan sebastian.sylvan at gmail.com
Thu Apr 26 13:27:04 EDT 2007


(note to Haskellers: Yeah, I'm handwaving things here, no need to point out
counter-examples to my generalisations!)

On 4/26/07, phiroc at free.fr <phiroc at free.fr> wrote:
We'll do this one first:

What are the mysterious "side effects" which are avoided by using Haskell,
which
everyone talks about? Null pointers?

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 :-)

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.

Hello,
>
> what are the advantages of haskell over semi-functional programming
> languages
> such as Perl, Common Lisp, etc.?


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.

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++).

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.

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!)



> Aren't Haskell's advantages outweighed by its complexity (Monads, etc.)
> and
> rigidity?


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.




-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell/attachments/20070426/72d2ceb7/attachment-0001.htm


More information about the Haskell mailing list