<span class="Apple-style-span" style="border-collapse: collapse; ">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. <div style="margin-top: 0px; margin-bottom: 0px; ">
<br></div><div style="margin-top: 0px; margin-bottom: 0px; ">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.</div>
<div style="margin-top: 0px; margin-bottom: 0px; "><br></div><div style="margin-top: 0px; margin-bottom: 0px; ">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?. </div>
<div style="margin-top: 0px; margin-bottom: 0px; "><br></div><div style="margin-top: 0px; margin-bottom: 0px; ">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.<br>
</div><div style="margin-top: 0px; margin-bottom: 0px; "><br></div></span><br><div class="gmail_quote">2009/1/10 Peter Verswyvelen <span dir="ltr"><<a href="mailto:bugfact@gmail.com">bugfact@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><span style="font-size:small">Related to this issue, I have a question here.</span></div><div><span style="font-size:small"><br>
</span></div><div><span style="font-size:small">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.</span></div>
<div><br></div><div><span style="font-size:small">Haskell is full of little hardcoded syntax extensions: list notation syntactic, list comprehensions, and even operator precedence that reduces the need for parentheses, etc...<br>
</span></div><div><span style="font-size:small"><br></span></div><div><span style="font-size:small">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.</span></div>
<div><span style="font-size:small"><br></span></div><div><div><span style="font-size:small">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. </span></div>
<div><span style="font-size:small"><br></span></div></div><div><span style="font-size:small">I'm not sure what others feel about the hardcoded syntax extensions in Haskell...<br>
</span></div><div><span style="font-size:small"><br></span></div><div><span style="font-size:small">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... </span></div>
<div><div></div><div class="Wj3C7c">
<div><span style="font-size:small"><br></span></div><div><span style="font-size:small">On Fri, Jan 9, 2009 at 4:07 AM, Neal Alexander </span><span dir="ltr"><span style="font-size:small"><<a href="mailto:wqeqweuqy@hotmail.com" target="_blank">wqeqweuqy@hotmail.com</a>></span></span><span style="font-size:small"> wrote:<br>
</span></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><span style="font-size:small">Ertugrul Soeylemez wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span style="font-size:small">
Hello fellow Haskellers,<br><br>
When I read questions from Haskell beginners, it somehow seems like they<br>
try to avoid monads and view them as a last resort, if there is no easy<br>
non-monadic way. I'm really sure that the cause for this is that most<br>
tutorials deal with monads very sparingly and mostly in the context of<br>
input/output. Also usually monads are associated with the do-notation,<br>
which makes them appear even more special, although there is really<br>
nothing special about them.<br><br>
</span></blockquote>
<span style="font-size:small"><br></span></div><span style="font-size:small">
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.<br><br>
"Why should i care about monads when i can use Arrows or (.)" was also a factor.<br><br>
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.<br><br>
For me the turning point was writing some code that needed to handle running code locally/remotely in a transparent manner.<br><br>
Maybe having a list of real-world usage scenarios or exercises on the wiki may help.
</span><div><div></div><div><span style="font-size:small"><br><br>
______________________________
</span><span style="font-size:small">_________________<br>
Haskell-Cafe mailing list<br>
</span><a href="mailto:Haskell-Cafe@haskell.org" target="_blank"><span style="text-decoration:none"><span style="font-size:small">Haskell-Cafe@haskell.org</span></span></a><span style="font-size:small"><br>
</span><a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank"><span style="text-decoration:none"><span style="font-size:small">http://www.haskell.org/</span></span><span style="text-decoration:none"><span style="font-size:small">mailman/listinfo/haskell-cafe</span></span></a><span style="font-size:small"><br>
</span></div></div></blockquote></div><br></div>
</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>