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.

On Fri, Feb 26, 2016 at 8:19 AM MJ Williams <matthewjwilliams101@gmail.com> wrote:
As I see it, Haskell and pure functional languages aren't
`necessarily' about readability so much as expressing thought in
mathematical terms.  The readability comes with the consistency and
transparency of well-formed mathematical notation.
by the way, that's transparency in laymen's sense and not referential
transparency.
Matthew


On 26/02/2016, Dudley Brooks <dbrooks@runforyourlife.org> wrote:
> One problem is that, while the symbolic operators do seem to have names
> (specified in the standards?) which are often sufficiently explanatory,
> you can find many tutorials which never even mention those names.
>
> On 2/26/16 1:55 AM, Mike Pentney wrote:
>
>> As a newbie, something I dislike about Haskell is the use of infix
>> operators like <||> which are unpronouncable and therefore (if you
>> don't happen to know the notation the symbol is based on) are more or
>> less meaningless.
>>
>> And Haskellers often seem to prefer 1 and 2 character variable names,
>> which again convey little or no information.
>>
>> And don't get me started on point-free code...!
>>
>> N.B. I am not trying to start a flame war, these are just comments
>> from my experience of trying to get beyond text-book examples and
>> start using Haskell libraries and trying to learn from open source
>> code. In general I find idiomatic Haskell hard to understand, and for
>> me this is a barrier to using Haskell for real projects. Maybe someday
>> I'll have learnt enough to get past this problem, but as the language
>> and libraries seem to evolve quickly, I have my doubts...
>>
>>
>> On 25/02/16 19:19, Jeffrey Brown wrote:
>>> Something I like about functional programming is how it interfaces
>>> with natural language.
>>> Haskell, somehow to a greater extent than other languages, encourages
>>> me to divide functions
>>> into one or two-liners. Each has a type signature that means
>>> something in English. Further, each
>>> gives you the opportunity to choose a good name for the function and
>>> its arguments. After doing
>>> those things, the function is much easier to write, and much easier
>>> to read -- so much so that
>>> often you don't have to read the function body at all, just the type
>>> signature, function name
>>> and argument names.
>>>
>>> On Thu, Feb 25, 2016 at 8:17 AM, Dudley Brooks
>>> <dbrooks@runforyourlife.org
>>> <mailto:dbrooks@runforyourlife.org>> wrote:
>>>
>>>     Ages and ages ago I saw this advice about programming:
>>>
>>>     Q:  "What's the best language for a programmer to know?"
>>>
>>>     A:  "English" (or whatever your native language is)
>>>
>>>     -- Dudley
>>>
>>>
>>>     On 2/24/16 4:03 PM, Dennis Raddle wrote:
>>>
>>>>     This is more about programming in general than Haskell, although
>>>> Haskellers probably know
>>>>     it well.
>>>>
>>>>     I don't claim to have expert knowledge on this, but I'm
>>>> gradually getting better at it.
>>>>
>>>>     When I set out to write a program, or refactor a program, or
>>>> modify a program, it helps to
>>>>     set out my thinking in a clear way. And how I make it clear is
>>>> to document my thoughts.
>>>>
>>>>     An outline is one good way to organize thoughts and is probably
>>>> my main tool. But good
>>>>     English prose is also helpful.
>>>>
>>>>     The key factor is "editing." In what sense do I mean that? Good
>>>> writers do it, and the
>>>>     Haskell documentation does it. I mean (1) brevity and (2) good
>>>> flow. To achieve brevity,
>>>>     you must think about the essence of each statement and trim away
>>>> the unnecessary stuff.
>>>>     Good flow refers to how the document builds up and modifies your
>>>> concepts as you read it.
>>>>     A document can actually mirror an effective learning process, or
>>>> influence and change your
>>>>     process.
>>>>
>>>>     I work with my documentation, making several editing passes. By
>>>> the time I'm done, I am in
>>>>     a great position to write a concise and flexible program.
>>>>
>>>>     It's interesting that not only is Haskell a concise language,
>>>> but the Haskell library
>>>>     documentation is concise. Contrast that with the Python
>>>> documentation which often wanders
>>>>     about into areas that are irrelevant--it could easily be cut
>>>> into one third its present size.
>>>>
>>>>     Mike
>>>>
>>>>
>>>>
>>>>
>>>>     _______________________________________________
>>>>     Beginners mailing list
>>>>     Beginners@haskell.org <mailto:Beginners@haskell.org>
>>>>     http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>>
>>>
>>>     _______________________________________________
>>>     Beginners mailing list
>>>     Beginners@haskell.org <mailto:Beginners@haskell.org>
>>>     http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>>
>>>
>>>
>>>
>>> --
>>> Jeffrey Benjamin Brown
>>>
>>>
>>> _______________________________________________
>>> Beginners mailing list
>>> Beginners@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>>
>> _______________________________________________
>> Beginners mailing list
>> Beginners@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
> _______________________________________________
> Beginners mailing list
> Beginners@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners