On Fri, Feb 26, 2016 at 2:08 PM, Michael Orlitzky
On 02/26/2016 12:41 PM, Rein Henrichs wrote:
Pointfree is good for reasoning about *composition*. It can often be more readable than pointful code when the focus of the function is on composition of other functions. For example, take this function from Bird's /Pearls of Functional Algorithm Design/:
boxes = map ungroup . ungroup . map cols . group . map group
Compare the pointful version:
boxes matrix = map ungroup (ungroup (map cols (group (map group matrix))))
Readibility is subjective, but I think many people will agree that the pointfree version is easier to read.
Sure, but does anyone have any idea what that first version is supposed to do? It would be much better to write it out:
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. 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. 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). One could argue that a public project needs to put greater focus on readability to the uninitiated. 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. D