Comments from OCaml Hacker Brian Hurt

[John Goerzen-3]

Hi folks,

Don Stewart noticed this blog post on Haskell by Brian Hurt, an OCaml
hacker:

http://enfranchisedmind.com/blog/2009/01/15/random-thoughts-on-haskell/

It's a great post, and I encourage people to read it.  I'd like to
highlight one particular paragraph:


  One thing that does annoy me about Haskell- naming. Say you've
  noticed a common pattern, a lot of data structures are similar to
  the difference list I described above, in that they have an empty
  state and the ability to append things onto the end. Now, for
  various reasons, you want to give this pattern a name using on
  Haskell's tools for expressing common idioms as general patterns
  (type classes, in this case). What name do you give it? I'd be
  inclined to call it something like "Appendable". But no, Haskell
  calls this pattern a "Monoid". Yep, that's all a monoid is-
  something with an empty state and the ability to append things to
  the end. Well, it's a little more general than that, but not
  much. Simon Peyton Jones once commented that the biggest mistake
  Haskell made was to call them "monads" instead of "warm, fluffy
  things". Well, Haskell is exacerbating that mistake. Haskell
  developers, stop letting the category theorists name
  things. Please. I beg of you.

I'd like to echo that sentiment!

He went on to add:

  If you?re not a category theorists, and you're learning (or thinking
  of learning) Haskell, don't get scared off by names like "monoid" or
  "functor". And ignore anyone who starts their explanation with
  references to category theory- you don't need to know category
  theory, and I don't think it helps.

I'd echo that one too.

-- John
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Lennart Augustsson]

I have replied on his blog, but I'll repeat the gist of it here.
Why is there a fear of using existing terminology that is exact?
Why do people want to invent new words when there are already existing
ones with the exact meaning that you want?
If I see Monoid I know what it is, if I didn't know I could just look
on Wikipedia.
If I see Appendable I can guess what it might be, but exactly what does it mean?

  -- Lennart

On Thu, Jan 15, 2009 at 3:34 PM, John Goerzen <[hidden email]> wrote:

> Hi folks,
>
> Don Stewart noticed this blog post on Haskell by Brian Hurt, an OCaml
> hacker:
>
> http://enfranchisedmind.com/blog/2009/01/15/random-thoughts-on-haskell/
>
> It's a great post, and I encourage people to read it.  I'd like to
> highlight one particular paragraph:
>
>
>  One thing that does annoy me about Haskell- naming. Say you've
>  noticed a common pattern, a lot of data structures are similar to
>  the difference list I described above, in that they have an empty
>  state and the ability to append things onto the end. Now, for
>  various reasons, you want to give this pattern a name using on
>  Haskell's tools for expressing common idioms as general patterns
>  (type classes, in this case). What name do you give it? I'd be
>  inclined to call it something like "Appendable". But no, Haskell
>  calls this pattern a "Monoid". Yep, that's all a monoid is-
>  something with an empty state and the ability to append things to
>  the end. Well, it's a little more general than that, but not
>  much. Simon Peyton Jones once commented that the biggest mistake
>  Haskell made was to call them "monads" instead of "warm, fluffy
>  things". Well, Haskell is exacerbating that mistake. Haskell
>  developers, stop letting the category theorists name
>  things. Please. I beg of you.
>
> I'd like to echo that sentiment!
>
> He went on to add:
>
>  If you?re not a category theorists, and you're learning (or thinking
>  of learning) Haskell, don't get scared off by names like "monoid" or
>  "functor". And ignore anyone who starts their explanation with
>  references to category theory- you don't need to know category
>  theory, and I don't think it helps.
>
> I'd echo that one too.
>
> -- John
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Sittampalam, Ganesh]

Lennart Augustsson wrote:
> I have replied on his blog, but I'll repeat the gist of it here.
> Why is there a fear of using existing terminology that is exact?
> Why do people want to invent new words when there are already
> existing ones with the exact meaning that you want? If I see Monoid I
> know what it is, if I didn't know I could just look on Wikipedia.
> If I see Appendable I can guess what it might be, but exactly what
> does it mean?

I would suggest that having to look things up slows people down
and might distract them from learning other, perhaps more useful,
things about the language.

Ganesh

==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[John Goerzen-3]

Lennart Augustsson wrote:
> I have replied on his blog, but I'll repeat the gist of it here.
> Why is there a fear of using existing terminology that is exact?
> Why do people want to invent new words when there are already existing
> ones with the exact meaning that you want?
> If I see Monoid I know what it is, if I didn't know I could just look
> on Wikipedia.
> If I see Appendable I can guess what it might be, but exactly what does it mean?

Picture someone that doesn't yet know Haskell.

If I see Appendable I can guess what it might be.  If I see "monoid", I
have no clue whatsoever, because I've never heard of a monoid before.

Using existing terminology isn't helpful if the people using the
language have never heard of it.

Wikipedia's first sentence about monoids is:

  In abstract algebra, a branch of mathematics, a monoid is an algebraic
  structure with a single, associative binary operation and an identity
  element.

Which is *not* intuitive to someone that comes from a background in....
 any other programming language.

A lot of communities have the "not invented here" disease -- they don't
like to touch things that other people have developed.  We seem to have
the "not named here" disease -- we don't want to give things a sensible
name for a programming language that is actually useful.

Here's another, less egregious, example: isInfixOf.  I would have called
that function "contains" or something.  Plenty of other languages have
functions that do the same thing, and I can't think of one that names it
anything like "isInfixOf".

If you're learning Haskell, which communicates the idea more clearly:

 * Appendable

or

 * Monoid

I can immediately figure out what the first one means.  With the second,
I could refer to the GHC documentation, which does not describe what a
Monoid does.  Or read a wikipedia article about a branch of mathematics
and try to figure out how it applies to Haskell.

The GHC docs for something called Appendable could very easily state
that it's a monoid.  (And the docs for Monoid ought to spell out what it
is in simple terms, not by linking to a 14-year-old paper.)

I guess the bottom line question is: who is Haskell for?  Category
theorists, programmers, or both?  I'd love it to be for both, but I've
got to admit that Brian has a point that it is trending to the first in
some areas.

-- John
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Thomas DuBuisson]

On Thu, Jan 15, 2009 at 4:12 PM, Sittampalam, Ganesh
<[hidden email]> wrote:

> Lennart Augustsson wrote:
>> I have replied on his blog, but I'll repeat the gist of it here.
>> Why is there a fear of using existing terminology that is exact?
>> Why do people want to invent new words when there are already
>> existing ones with the exact meaning that you want? If I see Monoid I
>> know what it is, if I didn't know I could just look on Wikipedia.
>> If I see Appendable I can guess what it might be, but exactly what
>> does it mean?
>
> I would suggest that having to look things up slows people down
> and might distract them from learning other, perhaps more useful,
> things about the language.

Exactly.  For example, the entry for monoid on Wikipedia starts:
"In abstract algebra, a branch of mathematics, a monoid is an
algebraic structure with a single, associative binary operation and an
identity element."

I've had some set theory, but most programmers I know have not.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Lennart Augustsson]

Why do people think that you should be able to understand everything
without ever looking things up?
I'll get back to my example from the comment on the blog post.  If I
see 'ghee' in a cook book I'll check what it is (if I don't know).  It
has a precise meaning and next time I'll know.  Inventing a new word
for it serves no purpose, but to confuse people.
Parts of Computer Science seem to love to invent new words for
existing concepts.  Again, I think this just confuses people in the
long run.  Or use existing words in a different way (like 'functor' in
C++.)

When it comes to 'isInfixOf', I think that is a particularely stupid
name.  As you point out, there are existing names for this function.
I would probably have picked something like isSubstringOf instead of
inventing something that is totally non-standard.

I'm not saying Haskell always gets naming right, all I want is to
reuse words that exist instead of inventing new ones.  (And 'monoid'
is not category theory, it's very basic (abstract) algebra.)  I don't
know any category theory, but if someone tells me that blah is an
endomorphism I'm happy to call it that, knowing that I have a name
that anyone can figure out with just a little effort.

  -- Lennart

On Thu, Jan 15, 2009 at 4:15 PM, John Goerzen <[hidden email]> wrote:

> Lennart Augustsson wrote:
>> I have replied on his blog, but I'll repeat the gist of it here.
>> Why is there a fear of using existing terminology that is exact?
>> Why do people want to invent new words when there are already existing
>> ones with the exact meaning that you want?
>> If I see Monoid I know what it is, if I didn't know I could just look
>> on Wikipedia.
>> If I see Appendable I can guess what it might be, but exactly what does it mean?
>
> Picture someone that doesn't yet know Haskell.
>
> If I see Appendable I can guess what it might be.  If I see "monoid", I
> have no clue whatsoever, because I've never heard of a monoid before.
>
> Using existing terminology isn't helpful if the people using the
> language have never heard of it.
>
> Wikipedia's first sentence about monoids is:
>
>  In abstract algebra, a branch of mathematics, a monoid is an algebraic
>  structure with a single, associative binary operation and an identity
>  element.
>
> Which is *not* intuitive to someone that comes from a background in....
>  any other programming language.
>
> A lot of communities have the "not invented here" disease -- they don't
> like to touch things that other people have developed.  We seem to have
> the "not named here" disease -- we don't want to give things a sensible
> name for a programming language that is actually useful.
>
> Here's another, less egregious, example: isInfixOf.  I would have called
> that function "contains" or something.  Plenty of other languages have
> functions that do the same thing, and I can't think of one that names it
> anything like "isInfixOf".
>
> If you're learning Haskell, which communicates the idea more clearly:
>
>  * Appendable
>
> or
>
>  * Monoid
>
> I can immediately figure out what the first one means.  With the second,
> I could refer to the GHC documentation, which does not describe what a
> Monoid does.  Or read a wikipedia article about a branch of mathematics
> and try to figure out how it applies to Haskell.
>
> The GHC docs for something called Appendable could very easily state
> that it's a monoid.  (And the docs for Monoid ought to spell out what it
> is in simple terms, not by linking to a 14-year-old paper.)
>
> I guess the bottom line question is: who is Haskell for?  Category
> theorists, programmers, or both?  I'd love it to be for both, but I've
> got to admit that Brian has a point that it is trending to the first in
> some areas.
>
> -- John
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Lennart Augustsson]

Most people don't understand pure functional programming either.  Does
that mean we should introduce unrestricted side effects in Haskell?

  -- Lennart

On Thu, Jan 15, 2009 at 4:22 PM, Thomas DuBuisson
<[hidden email]> wrote:

> On Thu, Jan 15, 2009 at 4:12 PM, Sittampalam, Ganesh
> <[hidden email]> wrote:
>> Lennart Augustsson wrote:
>>> I have replied on his blog, but I'll repeat the gist of it here.
>>> Why is there a fear of using existing terminology that is exact?
>>> Why do people want to invent new words when there are already
>>> existing ones with the exact meaning that you want? If I see Monoid I
>>> know what it is, if I didn't know I could just look on Wikipedia.
>>> If I see Appendable I can guess what it might be, but exactly what
>>> does it mean?
>>
>> I would suggest that having to look things up slows people down
>> and might distract them from learning other, perhaps more useful,
>> things about the language.
>
> Exactly.  For example, the entry for monoid on Wikipedia starts:
> "In abstract algebra, a branch of mathematics, a monoid is an
> algebraic structure with a single, associative binary operation and an
> identity element."
>
> I've had some set theory, but most programmers I know have not.
>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Sittampalam, Ganesh]

Lennart Augustsson wrote:
> a name that anyone can figure out with just a little effort.

I think the problem is that all these pieces of "little effort"
soon mount up. It's not just the cost of looking it up, but also
of remembering it the next time and so on. It's fine when you
only encounter the occasional unfamiliar term, but a barrage of
them all at once can be quite disorienting.

Ganesh

==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Wouter Swierstra]

At the risk of painting my own bikeshed...

> If you're learning Haskell, which communicates the idea more clearly:
>
> * Appendable
>
> or
>
> * Monoid

Would you call function composition (on endofunctions) "appending"?  
The join of a monad? A semi-colon (as in sequencing two imperative  
statements)? How do you append two numbers? Addition, multiplication,  
or something else entirely?

All these operations are monoidal, i.e., are associative and have both  
left and right identities. If that's exactly what they have in common,  
why invent a new name? "Appendable" may carry some intuition, but it  
is not precise and sometimes quite misleading.

> I guess the bottom line question is: who is Haskell for?  Category
> theorists, programmers, or both?  I'd love it to be for both, but I've
> got to admit that Brian has a point that it is trending to the first  
> in
> some areas.


One of my grievances about Haskell is the occasional disregard for  
existing terminology. "Stream Fusion" is about lazy lists/co-lists,  
not streams; "type families" mean something entirely different to type  
theorists. This kind of misnomer is even more confusing than a name  
that doesn't mean anything (at least, until you learn more category  
theory).

   Wouter



This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Ross Mellgren]

For what it's worth, many (most/all?) programmers I know in person  
don't have the slightest clue about Category Theory and they may have  
known about abstract algebra once upon a time but certainly don't  
remember any of it now. They usually understand the concepts perfectly  
well enough but by "lay terms" or by no particular name at all.

Personally, I don't mind it too much if the generic typeclasses are  
named using extremely accurate terms like Monoid, but saying that  
someone should then look up the abstract math concept and try to map  
this to something very concrete and simple such as a string seems like  
wasted effort.

Usually when encountering something like "Monoid" (if I didn't already  
know it), I'd look it up in the library docs. The problem I've had  
with this tactic is twofold:

First, the docs for the typeclass usually don't give any practical  
examples, so sometimes it's hard to be sure that the "append" in  
"mappend" means what you think it means.

Second is that there appears to be no way to document an _instance_.  
It would be really handy if there were even a single line under  
"Instances > Monoid ([] a)" that explained how the type class was  
implemented for the list type. As it is, if you know what a Monoid is  
already, it's easy to figure out how it would be implemented. If you  
don't, you're either stuck reading a bunch of pages on the generic  
math term monoid and then finally realizing that it means  
"appendable" (and other similar things), or grovelling through the  
library source code seeing how the instance is implemented.

My 2 cents,

-Ross


On Jan 15, 2009, at 11:36 AM, Lennart Augustsson wrote:

> Most people don't understand pure functional programming either.  Does
> that mean we should introduce unrestricted side effects in Haskell?
>
>  -- Lennart
>
> On Thu, Jan 15, 2009 at 4:22 PM, Thomas DuBuisson
> <[hidden email]> wrote:
>> On Thu, Jan 15, 2009 at 4:12 PM, Sittampalam, Ganesh
>> <[hidden email]> wrote:
>>> Lennart Augustsson wrote:
>>>> I have replied on his blog, but I'll repeat the gist of it here.
>>>> Why is there a fear of using existing terminology that is exact?
>>>> Why do people want to invent new words when there are already
>>>> existing ones with the exact meaning that you want? If I see  
>>>> Monoid I
>>>> know what it is, if I didn't know I could just look on Wikipedia.
>>>> If I see Appendable I can guess what it might be, but exactly what
>>>> does it mean?
>>>
>>> I would suggest that having to look things up slows people down
>>> and might distract them from learning other, perhaps more useful,
>>> things about the language.
>>
>> Exactly.  For example, the entry for monoid on Wikipedia starts:
>> "In abstract algebra, a branch of mathematics, a monoid is an
>> algebraic structure with a single, associative binary operation and  
>> an
>> identity element."
>>
>> I've had some set theory, but most programmers I know have not.
>>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Lennart Augustsson]

I won't deny that Haskell has a large number of unfamiliar term if
you've only seen Java before.
But I don't think that giving them all happy fuzzy names will help
people in the long run.

  -- Lennart

On Thu, Jan 15, 2009 at 4:40 PM, Sittampalam, Ganesh
<[hidden email]> wrote:

> Lennart Augustsson wrote:
>> a name that anyone can figure out with just a little effort.
>
> I think the problem is that all these pieces of "little effort"
> soon mount up. It's not just the cost of looking it up, but also
> of remembering it the next time and so on. It's fine when you
> only encounter the occasional unfamiliar term, but a barrage of
> them all at once can be quite disorienting.
>
> Ganesh
>
> ==============================================================================
> Please access the attached hyperlink for an important electronic communications disclaimer:
>
> http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
> ==============================================================================
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[John Goerzen-3]

Lennart Augustsson wrote:
> Why do people think that you should be able to understand everything
> without ever looking things up?

I don't.  But looking things up has to be helpful.  In all to many
cases, looking things up means clicking the link to someone's old
academic paper or some article about abstract math in Wikipedia.  It
does not answer the questions:

 * Why is this in Haskell?

 * Why would I want to use it?

 * How does it benefit me?

 * How do I use it in Haskell?

If the docs for things like Monoids were more newbie-friendly, I
wouldn't gripe about it as much.

Though if all we're talking about is naming, I would still maintain that
newbie-friendly naming is a win.  We can always say "HEY MATHEMETICIANS:
APPENDABLE MEANS MONOID" in the haddock docs ;-)

Much as I dislike Java's penchant for 200-character names for things,
I'm not sure Monoid is more descriptive than
SomeSortOfGenericThingThatYouCanAppendStuffToClassTemplateAbstractInterfaceThingy
:-)

-- John
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Lennart Augustsson]

By no means do I suggest that Wikipedia should replace Haskell library
documentation.
I think the libraries should be documented in a mostly stand-alone way
(i.e., no references to old papers etc.).  In the case of Monoid, a
few lines of text is enough to convey the meaning of it and gives an
example.

  -- Lennart

On Thu, Jan 15, 2009 at 4:46 PM, Ross Mellgren <[hidden email]> wrote:

> For what it's worth, many (most/all?) programmers I know in person don't
> have the slightest clue about Category Theory and they may have known about
> abstract algebra once upon a time but certainly don't remember any of it
> now. They usually understand the concepts perfectly well enough but by "lay
> terms" or by no particular name at all.
>
> Personally, I don't mind it too much if the generic typeclasses are named
> using extremely accurate terms like Monoid, but saying that someone should
> then look up the abstract math concept and try to map this to something very
> concrete and simple such as a string seems like wasted effort.
>
> Usually when encountering something like "Monoid" (if I didn't already know
> it), I'd look it up in the library docs. The problem I've had with this
> tactic is twofold:
>
> First, the docs for the typeclass usually don't give any practical examples,
> so sometimes it's hard to be sure that the "append" in "mappend" means what
> you think it means.
>
> Second is that there appears to be no way to document an _instance_. It
> would be really handy if there were even a single line under "Instances >
> Monoid ([] a)" that explained how the type class was implemented for the
> list type. As it is, if you know what a Monoid is already, it's easy to
> figure out how it would be implemented. If you don't, you're either stuck
> reading a bunch of pages on the generic math term monoid and then finally
> realizing that it means "appendable" (and other similar things), or
> grovelling through the library source code seeing how the instance is
> implemented.
>
> My 2 cents,
>
> -Ross
>
>
> On Jan 15, 2009, at 11:36 AM, Lennart Augustsson wrote:
>
>> Most people don't understand pure functional programming either.  Does
>> that mean we should introduce unrestricted side effects in Haskell?
>>
>>  -- Lennart
>>
>> On Thu, Jan 15, 2009 at 4:22 PM, Thomas DuBuisson
>> <[hidden email]> wrote:
>>>
>>> On Thu, Jan 15, 2009 at 4:12 PM, Sittampalam, Ganesh
>>> <[hidden email]> wrote:
>>>>
>>>> Lennart Augustsson wrote:
>>>>>
>>>>> I have replied on his blog, but I'll repeat the gist of it here.
>>>>> Why is there a fear of using existing terminology that is exact?
>>>>> Why do people want to invent new words when there are already
>>>>> existing ones with the exact meaning that you want? If I see Monoid I
>>>>> know what it is, if I didn't know I could just look on Wikipedia.
>>>>> If I see Appendable I can guess what it might be, but exactly what
>>>>> does it mean?
>>>>
>>>> I would suggest that having to look things up slows people down
>>>> and might distract them from learning other, perhaps more useful,
>>>> things about the language.
>>>
>>> Exactly.  For example, the entry for monoid on Wikipedia starts:
>>> "In abstract algebra, a branch of mathematics, a monoid is an
>>> algebraic structure with a single, associative binary operation and an
>>> identity element."
>>>
>>> I've had some set theory, but most programmers I know have not.
>>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Ross Mellgren]

Of course not, the wikipedians would probably have your head for  
notability guidelines or something ;-)

But seriously, I would have saved many hours of my life and probably  
many future ones if type class instances were documented and showed up  
in the haddock docs.

-Ross

On Jan 15, 2009, at 11:53 AM, Lennart Augustsson wrote:

> By no means do I suggest that Wikipedia should replace Haskell library
> documentation.
> I think the libraries should be documented in a mostly stand-alone way
> (i.e., no references to old papers etc.).  In the case of Monoid, a
> few lines of text is enough to convey the meaning of it and gives an
> example.
>
>  -- Lennart
>
> On Thu, Jan 15, 2009 at 4:46 PM, Ross Mellgren <rmm-
> [hidden email]> wrote:
>> For what it's worth, many (most/all?) programmers I know in person  
>> don't
>> have the slightest clue about Category Theory and they may have  
>> known about
>> abstract algebra once upon a time but certainly don't remember any  
>> of it
>> now. They usually understand the concepts perfectly well enough but  
>> by "lay
>> terms" or by no particular name at all.
>>
>> Personally, I don't mind it too much if the generic typeclasses are  
>> named
>> using extremely accurate terms like Monoid, but saying that someone  
>> should
>> then look up the abstract math concept and try to map this to  
>> something very
>> concrete and simple such as a string seems like wasted effort.
>>
>> Usually when encountering something like "Monoid" (if I didn't  
>> already know
>> it), I'd look it up in the library docs. The problem I've had with  
>> this
>> tactic is twofold:
>>
>> First, the docs for the typeclass usually don't give any practical  
>> examples,
>> so sometimes it's hard to be sure that the "append" in "mappend"  
>> means what
>> you think it means.
>>
>> Second is that there appears to be no way to document an  
>> _instance_. It
>> would be really handy if there were even a single line under  
>> "Instances >
>> Monoid ([] a)" that explained how the type class was implemented  
>> for the
>> list type. As it is, if you know what a Monoid is already, it's  
>> easy to
>> figure out how it would be implemented. If you don't, you're either  
>> stuck
>> reading a bunch of pages on the generic math term monoid and then  
>> finally
>> realizing that it means "appendable" (and other similar things), or
>> grovelling through the library source code seeing how the instance is
>> implemented.
>>
>> My 2 cents,
>>
>> -Ross
>>
>>
>> On Jan 15, 2009, at 11:36 AM, Lennart Augustsson wrote:
>>
>>> Most people don't understand pure functional programming either.  
>>> Does
>>> that mean we should introduce unrestricted side effects in Haskell?
>>>
>>> -- Lennart
>>>
>>> On Thu, Jan 15, 2009 at 4:22 PM, Thomas DuBuisson
>>> <[hidden email]> wrote:
>>>>
>>>> On Thu, Jan 15, 2009 at 4:12 PM, Sittampalam, Ganesh
>>>> <[hidden email]> wrote:
>>>>>
>>>>> Lennart Augustsson wrote:
>>>>>>
>>>>>> I have replied on his blog, but I'll repeat the gist of it here.
>>>>>> Why is there a fear of using existing terminology that is exact?
>>>>>> Why do people want to invent new words when there are already
>>>>>> existing ones with the exact meaning that you want? If I see  
>>>>>> Monoid I
>>>>>> know what it is, if I didn't know I could just look on Wikipedia.
>>>>>> If I see Appendable I can guess what it might be, but exactly  
>>>>>> what
>>>>>> does it mean?
>>>>>
>>>>> I would suggest that having to look things up slows people down
>>>>> and might distract them from learning other, perhaps more useful,
>>>>> things about the language.
>>>>
>>>> Exactly.  For example, the entry for monoid on Wikipedia starts:
>>>> "In abstract algebra, a branch of mathematics, a monoid is an
>>>> algebraic structure with a single, associative binary operation  
>>>> and an
>>>> identity element."
>>>>
>>>> I've had some set theory, but most programmers I know have not.
>>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> [hidden email]
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[John Goerzen-3]

Lennart Augustsson wrote:
> Most people don't understand pure functional programming either.  Does
> that mean we should introduce unrestricted side effects in Haskell?

The key is to introduce concepts to them in terms they can understand.

You introduce it one way to experienced abstract mathematicians, and a
completely different way to experienced Perl hackers.  I wouldn't expect
a mathematician to grok Perl, and I wouldn't expect $PERL_HACKER to grok
abstract math.  People have different backgrounds to draw upon, and we
are under-serving one community.

-- John
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Creighton Hogg-4]

On Thu, Jan 15, 2009 at 10:46 AM, Ross Mellgren <[hidden email]> wrote:
<snip>

> Usually when encountering something like "Monoid" (if I didn't already know
> it), I'd look it up in the library docs. The problem I've had with this
> tactic is twofold:
>
> First, the docs for the typeclass usually don't give any practical examples,
> so sometimes it's hard to be sure that the "append" in "mappend" means what
> you think it means.
>
> Second is that there appears to be no way to document an _instance_. It
> would be really handy if there were even a single line under "Instances >
> Monoid ([] a)" that explained how the type class was implemented for the
> list type. As it is, if you know what a Monoid is already, it's easy to
> figure out how it would be implemented. If you don't, you're either stuck
> reading a bunch of pages on the generic math term monoid and then finally
> realizing that it means "appendable" (and other similar things), or
> grovelling through the library source code seeing how the instance is
> implemented.

I think you have a good point regarding documentation.  Usually what I
end up doing is just going into ghci & testing out the instances with
some trivial cases to make sure I have good intuition for how it's
going to work.  I don't think this a problem with the term 'monoid'
though, but just a very generic problem with documentation.  I have to
do the same thing to understand an instance of Foldable despite how
literal the name is.  I don't know if it's very practical, but I like
the idea of haddock generating either links to the source of the
instance or some kind of expandable block that will show you the
literal code.

Cheers,
Creighton
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Lennart Augustsson]

I think the documentation should be reasonably newbie-friendly too.
But that doesn't mean we should call Monoid Appendable.
Appendable is just misleading, since Monoid is more general than appending.

  -- Lennart

On Thu, Jan 15, 2009 at 4:51 PM, John Goerzen <[hidden email]> wrote:

> Lennart Augustsson wrote:
>> Why do people think that you should be able to understand everything
>> without ever looking things up?
>
> I don't.  But looking things up has to be helpful.  In all to many
> cases, looking things up means clicking the link to someone's old
> academic paper or some article about abstract math in Wikipedia.  It
> does not answer the questions:
>
>  * Why is this in Haskell?
>
>  * Why would I want to use it?
>
>  * How does it benefit me?
>
>  * How do I use it in Haskell?
>
> If the docs for things like Monoids were more newbie-friendly, I
> wouldn't gripe about it as much.
>
> Though if all we're talking about is naming, I would still maintain that
> newbie-friendly naming is a win.  We can always say "HEY MATHEMETICIANS:
> APPENDABLE MEANS MONOID" in the haddock docs ;-)
>
> Much as I dislike Java's penchant for 200-character names for things,
> I'm not sure Monoid is more descriptive than
> SomeSortOfGenericThingThatYouCanAppendStuffToClassTemplateAbstractInterfaceThingy
> :-)
>
> -- John
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Lennart Augustsson]

I'm totally with you on the instance documentation.  I wish haddock allowed it.

On Thu, Jan 15, 2009 at 4:56 PM, Ross Mellgren <[hidden email]> wrote:
> Of course not, the wikipedians would probably have your head for notability
> guidelines or something ;-)
>
> But seriously, I would have saved many hours of my life and probably many
> future ones if type class instances were documented and showed up in the
> haddock docs.
>
> -Ross
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Justin Bogner]

John Goerzen <[hidden email]> writes:
> Wikipedia's first sentence about monoids is:
>
>   In abstract algebra, a branch of mathematics, a monoid is an algebraic
>   structure with a single, associative binary operation and an identity
>   element.
>
> Which is *not* intuitive to someone that comes from a background in....
>  any other programming language.
>

Instead of Wikipedia, why not try a dictionary? Looking up monoid using
dictionary.com:

  An operator * and a value x form a monoid if * is
  associative and x is its left and right identity.

On the other hand, appendable doesn't seem to be a word, and while you
can infer that it means "something that can be appended to", that's only
half of the story...

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Justin Bogner]

Ross Mellgren <[hidden email]> writes:
> Usually when encountering something like "Monoid" (if I didn't already
> know it), I'd look it up in the library docs. The problem I've had
> with this tactic is twofold:
>
> First, the docs for the typeclass usually don't give any practical
> examples, so sometimes it's hard to be sure that the "append" in
> "mappend" means what you think it means.

I second this, many of the docs are sorely lacking examples (and there
are of course docs that simply reference a paper, which is usually too
long to be helpful in the short term...)

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe