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 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

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 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

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 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 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 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

On Fri, Feb 26, 2016 at 2:08 PM, Michael Orlitzky wrote:

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

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: map (f . g . h) xs to map (\x -> f $ g $ h x) xs On Fri, Feb 26, 2016 at 10:17 PM, Rustom Mody wrote:

On Fri, Feb 26, 2016 at 11:11 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

And better if you read it in the right (ie left to right order)

boxes = map group >>> group >>> map cols >> ungroup >>> map ungroup (From Control.Arrow)

Even better if the 3-char clunky >>> is reduced to the 1-char ⋙ map group ⋙ group ⋙ map cols ⋙ ungroup ⋙ map ungroup (From Control.Arrow.Unicode) [Those who find this unnatural/difficult/arcane/etc may like to check out Unix-pipes (or English :-) ]

Some wishful thinking in the same direction (uses python but python is not really relevant) : http://blog.languager.org/2014/04/unicoded-python.html Which to some extent I found works in Haskell : http://blog.languager.org/2014/05/unicode-in-haskell-source.html If only Haskell would go further!!

_______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

-- Jeffrey Benjamin Brown

2¢ from a Haskell newbie, who would be delighted to be instructed or corrected: 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. 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 https://en.wikipedia.org/wiki/Maxwell%27s_equations .) 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. 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: *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.* 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 http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html and http://codon.com/refactoring-ruby-with-monads . I'd be very interested to know whether there examples of this technique for more advanced Haskell code. Thanks, Joel On Sat, Feb 27, 2016 at 9:24 PM, Rustom Mody wrote:

On Sun, Feb 28, 2016 at 2:26 AM, Jeffrey Brown wrote:

...

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:

map (f . g . h) xs

to

map (\x -> f $ g $ h x) xs

Not quite a fair comparison How about? [ f (g (h x)) | x <- xs ]

_______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

-- Beauty of style and harmony and grace and good rhythm depend on simplicity. - Plato

An even more convenient (when applicable) guide to pronunciation: https://wiki.haskell.org/Pronunciation On Sun, Feb 28, 2016 at 4:51 PM, Jeffrey Brown wrote:

That will work in the special case of lists, but there are all sorts of other things you might want to map across.

On Sat, Feb 27, 2016 at 7:24 PM, Rustom Mody wrote:

...

On Sun, Feb 28, 2016 at 2:26 AM, Jeffrey Brown wrote:

...

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:

map (f . g . h) xs

to

map (\x -> f $ g $ h x) xs

Not quite a fair comparison How about? [ f (g (h x)) | x <- xs ]

_______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

-- Jeffrey Benjamin Brown

-- Jeffrey Benjamin Brown

On 02/27/2016 08:35 PM, Henk-Jan van Tuyl wrote:

...

Even better if the 3-char clunky >>> is reduced to the 1-char ⋙ map group ⋙ group ⋙ map cols ⋙ ungroup ⋙ map ungroup (From Control.Arrow.Unicode)

You can also use & from Data.Function (since base 4.8.0.0) map group & group & map cols & ungroup & map ungroup

I would love to hear the elevator pitch for making "and" mean "backwards function application". Might as well go full retard: boxes m = m & ((⋘ ungroup . map cols <<< group >>> map group) $ map ungroup) As you can see, it gets more clear the more operators you use. Note that (&) isn't backwards composition -- it's backwards application. So it's analogous to "$" and not the "." operator. You can just google "&" to find that out though.

If you want to know how to pronounce an infix, GHCI and Hackage can very often solve the problem for you. For instance: > :i <$> (<$>) :: Functor f => (a -> b) -> f a -> f b -- Defined in ‘Data.Functor’ infixl 4 <$> > If you then lookup Data.Functor on Hackage, you'll find in the description of <$> "An infix synonym for fmap." Even if there's no comment provided, you can from there view source; often you'll find a one-word definition like "(>>=) = bind". On Fri, Feb 26, 2016 at 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

-- Jeffrey Benjamin Brown