<div dir="ltr"><div class="gmail_default" style="font-family:georgia,serif;font-size:small">2¢ from a Haskell newbie, who would be delighted to be instructed or corrected:</div><div class="gmail_default" style="font-family:georgia,serif;font-size:small"><br></div><div class="gmail_default" style="font-family:georgia,serif;font-size:small">I have experienced some of the same issues mentioned earlier in this thread when trying to read code written by a real expert (e.g. from "How do I verbalize that, to think out loud or discuss it with someone else?" to "Why that particular abstraction at this point?"). I tend to think that Haskell has no exclusive claim on this consideration. Witness, for example, the experience of a newcomer looking at a compact Java source file that makes heavy use of generics and framework-specific annotations. However, as one of the most directly mathematically-influenced programming languages, I can also believe that it may happen to a greater degree in Haskell than most others.</div><div class="gmail_default" style="font-family:georgia,serif;font-size:small"><br></div><div class="gmail_default" style="font-family:georgia,serif;font-size:small">Mathematics, Haskell, and certain approaches to programming tend to share the practice of building up an elegant pyramid of abstraction which allows one to say more and more with fewer and fewer marks. (Witness the description of Maxwell's laws at <a href="https://en.wikipedia.org/wiki/Maxwell%27s_equations">https://en.wikipedia.org/wiki/Maxwell%27s_equations</a> .)</div><div class="gmail_default" style="font-family:georgia,serif;font-size:small"><br></div><div class="gmail_default" style="font-family:georgia,serif;font-size:small">I suspect that a beginner to any of the above, on first examining an artifact from an expert practitioner, will struggle to find the keyhole (or even the doorknob). As a part time instructor, I also struggle with the degree to which some "explanations" risk either dumbing-down important concepts or covering them in so much metaphorical baggage that they actually exacerbate the problem faced by the student.</div><div class="gmail_default" style="font-family:georgia,serif;font-size:small"><br></div><div class="gmail_default" style="font-family:georgia,serif;font-size:small">Just as agile practitioners use spikes to explore the skeleton of a problem, knowing full well that they have simplified it for the purpose of addressing one concern,  I'm starting to experiment with "spike explanations" that draw a simplified connection from the apex of the pyramid to ground level. For example:</div><div class="gmail_default" style="font-family:georgia,serif;font-size:small"><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_default" style="font-family:georgia,serif;font-size:small"><i>For present purposes, think of a monoid as a general scheme for accumulating a result over a specific data type, such as the sum of integers or the concatentation of strings. We'll talk later about some specific expectations that must be satisfied.</i></div></blockquote><div class="gmail_default" style="font-family:georgia,serif;font-size:small"><br></div><div class="gmail_default" style="font-family:georgia,serif;font-size:small">An expert is going to say (or write) high-economy utterances that other experts will instantly grasp and that newcomers will find opaque. I suspect that the editing process that the original poster described is the crucial part of developing an understanding. One "spike explanation" technique with which I have had some success involves starting with a verbose, concrete artifact (e.g. bit of source code), then progressively editing re-factoring it into the final nicely-abstracted, economical form. Accessible examples that come to mind include <a href="http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html">http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html</a> and <a href="http://codon.com/refactoring-ruby-with-monads">http://codon.com/refactoring-ruby-with-monads</a> .</div><div class="gmail_default" style="font-family:georgia,serif;font-size:small"><br></div><div class="gmail_default" style="font-family:georgia,serif;font-size:small">I'd be very interested to know whether there examples of this technique for more advanced Haskell code.<br></div><div class="gmail_default" style="font-family:georgia,serif;font-size:small"><br></div><div class="gmail_default" style="font-family:georgia,serif;font-size:small">Thanks,</div><div class="gmail_default" style="font-family:georgia,serif;font-size:small">Joel</div><div class="gmail_default" style="font-family:georgia,serif;font-size:small"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 27, 2016 at 9:24 PM, Rustom Mody <span dir="ltr"><<a href="mailto:rustompmody@gmail.com" target="_blank">rustompmody@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Sun, Feb 28, 2016 at 2:26 AM, Jeffrey Brown <span dir="ltr"><<a href="mailto:jeffbrown.the@gmail.com" target="_blank">jeffbrown.the@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>It is, I agree, not appropriate everywhere, but point-free code can in the right place be much more readable. Maps are a good example. Compare:</div><div><br></div><div>    map (f . g . h) xs</div><div><br></div><div>to</div><div><br></div><div>    map (\x -> f $ g $ h x) xs</div></div></blockquote><div><br></div></span><div>Not quite a fair comparison<br></div><div>How about?<br></div><div>[ f (g (h x))  |  x <- xs ] <br></div><div><br><br></div></div>
</div></div>
<br>_______________________________________________<br>
Beginners mailing list<br>
<a href="mailto:Beginners@haskell.org">Beginners@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Beauty of style and harmony and grace and good rhythm depend on simplicity. - Plato</div>
</div>