[Haskell-cafe] Re: Monads aren't evil

[Alberto G. Corona]

As a physicist, I think that programming, like any design in general, is all
about making as little use of brain resources as possible at the time of
solving problems and to transmit the solution to others. This is the reason
why it is pervasive in all kinds of engineering the concepts of modularity,
isolation, clean interfacing (for which referential transparency is part of)
etc. To decompose a problem in parts each one with simple solutions and with
as little uncontrolled interaction with other parts is a rule of good
design simply  because we can not think in nothing  but around seven
concepts at the same time (By the way, an evolutionary psychologist would
say that the beatifulness of simplicity is related with this release of
brain resources). As a matter of fact,  these rules of "good" design do not
apply to the design of living beings simply because the process of Natural
Selection has not these limitations. that is indeed the reason because
natural designs are so difficult for reverse engineering.
Because such kid of human brain limitations and our lack of knowledge,
design has a lot of trial and error. The danger of this is to get lost in
the explosion of unfruitful alternatives due to low level issues outside of
our high level problem, because the limitation of the tools we are using for
it. In this sense, things like the strong type inference is superb for
cutting the explosion of erroneous paths that the process of software
development can generate. If designing solutions is sculpting order from
chaos and against chaos, intelligent tools are the thing needed  to keep us
concentrated in fruitful courses of action. A physicist would say that
design is to lower the entropic balance by progressively lowering the number
of microstates until the only ones permitted correspond with the desired
outcomes, called "solutions" and a few bugs, of course.

For me, syntactic sugar is one more of this features that make haskell so
great. Once we discover that a solution  general enough has a correspondence
with something already know, such are monads for imperative languages, then,
why not make this similarity explicit ,with the do notation, in order to
communicate it better with other people making use of this common
knowledge?.

I have to say also that, without Haskell, I never dream to have the
confidence to play simultaneously with concurrence, transactions, internet
incommunications, parsing and, at the time, keeping the code clean enough to
understand it after a month of inactivity.  This is for me the big picture
that matters for real programming.


2009/1/10 Peter Verswyvelen <bugfact at gmail.com>

> Related to this issue, I have a question here.
>
> I might  be wrong, but it seems to me that some Haskellers don't like
> writing monads (with do notation) or arrows (with proc sugar) because of the
> fact they have to abandon the typical applicative syntax, which is so close
> to the beautiful lambda calculus core. Or is it maybe because some people
> choose monads were the less linear applicative style could be used instead,
> so the choice of monads is not always appropriate.
>
> Haskell is full of little hardcoded syntax extensions: list notation
> syntactic, list comprehensions, and even operator precedence that reduces
> the need for parentheses, etc...
>
> Of course IMHO the syntactic sugar is needed, e.g. a Yampa game written
> without the arrows syntax would be incomprehensible for the average
> programmer. But one could claim that this syntactic sugar hides what is
> really going on under the hood, so for newcomers these extensions might make
> it harder. It could also feel like a hack, a failure to keep things as
> simple as possible yet elegant.
>
> Some people I talked with like that about the Scheme/ & LISP languages: the
> syntax remains ultimately close to the core, with very little hardcoded
> syntactic extensions. And when one wants to add syntactic extensions, one
> uses syntactic macros.
>
> I'm not sure what others feel about the hardcoded syntax extensions in
> Haskell...
>
> Personally I'm not that much of a purist, I'm an old school hacker that
> mainly needs to get the job done. I like the syntax extensions in Haskell
> (and even C#/F# ;) because they let me write code shorter and clearer...
>
> On Fri, Jan 9, 2009 at 4:07 AM, Neal Alexander <wqeqweuqy at hotmail.com>wrote:
>
>> Ertugrul Soeylemez wrote:
>>
>>> Hello fellow Haskellers,
>>>
>>> When I read questions from Haskell beginners, it somehow seems like they
>>> try to avoid monads and view them as a last resort, if there is no easy
>>> non-monadic way.  I'm really sure that the cause for this is that most
>>> tutorials deal with monads very sparingly and mostly in the context of
>>> input/output.  Also usually monads are associated with the do-notation,
>>> which makes them appear even more special, although there is really
>>> nothing special about them.
>>>
>>>
>> Yea, i was the same way when i started learning Haskell. I understood how
>> Monads worked, and what the motivation was for them, but not why i would
>> want to restructure code to use them in specific instances.
>>
>> "Why should i care about monads when i can use Arrows or (.)" was also a
>> factor.
>>
>> Its kinda like getting advice from an adult as a child. You have no
>> particular reason to distrust the advice, but the value of it doesn't set in
>> until something happens to you first hand to verify it.
>>
>> For me the turning point was writing some code that needed to handle
>> running code locally/remotely in a transparent manner.
>>
>> Maybe having a list of real-world usage scenarios or exercises on the wiki
>> may help.
>>
>>
>> ______________________________ _________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090111/97108079/attachment.htm