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

[mike clemow]

Phiroc,

I'm new to these ideas too--especially since my college math training
is non-existent.  I found the following wikipedia articles
particularly illuminating on the topic of side-effects:

http://en.wikipedia.org/wiki/Side_effect_%28computer_science%29

and

http://en.wikipedia.org/wiki/Referential_transparency

FP is a completely different way of thinking about solving a problem
than is generally used in imperative programming.  It's a lot more
like math (see Alonso Church, Lambda Calculus, and Haskell Curry,
after which Haskell is named and the process called "Currying," ->
another great wikipedia read:  http://en.wikipedia.org/wiki/Currying
where some of the real power of FP comes from).

The main advantage to solving the problems in this way is that you can
be more sure (like mathematical proof kind of sure) that your program
does what it's intended to do.

As far as language vs language discussion, I say get a book, or look
on the net for a tutorial (try haskell.org for starters) and try it
out and see if it works for you.  That's what I'm doing.    It's fun!
But, use the right tool for the job, of course, as Rob pointed out.

Cheers,
Mike (FP Ultra-Noob)


On 4/26/07, Sebastian Sylvan <sebastian.sylvan at gmail.com> wrote:
> (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
> _______________________________________________
> Haskell mailing list
> Haskell at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
>


-- 
http://clembie.livejournal.com
http://shadowofaculture.blogspot.com
http://deadlylittlepills.com