<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 26, 2016 at 2:08 PM, Michael Orlitzky <span dir="ltr"><<a href="mailto:michael@orlitzky.com" target="_blank">michael@orlitzky.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 02/26/2016 12:41 PM, Rein Henrichs wrote:<br>
> Pointfree is good for reasoning about *composition*. It can often be<br>
<span class="">> more readable than pointful code when the focus of the function is on<br>
> composition of other functions. For example, take this function from<br>
</span>> Bird's /Pearls of Functional Algorithm Design/:<br>
<span class="">><br>
>  boxes = map ungroup . ungroup . map cols . group . map group<br>
><br>
> Compare the pointful version:<br>
><br>
> boxes matrix = map ungroup (ungroup (map cols (group (map group matrix))))<br>
><br>
> Readibility is subjective, but I think many people will agree that the<br>
> pointfree version is easier to read.<br>
><br>
<br>
</span>Sure, but does anyone have any idea what that first version is supposed<br>
to do? It would be much better to write it out:<br>
<br></blockquote><div><br></div><div><br></div><div>On Haskell's readability, I am getting better at reading point-free and idiomatic Haskell with practice, and I now think that a short Haskell function with a meaningful type signature is much more readable that other languages I've used. </div><div><br></div><div>On using short variable names, that plus point free style can make a lot of expressions into one-liners, which I see as an advantage for comprehension on the whole, even if you need to learn what the variables mean. Using 'm' for a map, 'l' for a list, and other conventions helps. </div><div><br></div><div>Some styles make a program more readable when it is first encountered, but my own pet project is something I've worked with for a long time, allowing me to establish consistent and carefully thought-out naming schemes, not to mention I'm familiar with the concepts, so I find it easier to read my own code (say, written a long time ago) when it's concise (meaning point-free in many cases).</div><div><br></div><div>One could argue that a public project needs to put greater focus on readability to the uninitiated. </div><div><br></div><div>The Haskell hierarchical libraries are public, and their design seems, as far as I can tell, intended to trade off toward the person who has become expert in them rather than making everything obvious to the beginner. But maybe I'm wrong about that. </div><div><br></div><div>D</div><div><br></div></div></div></div>