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 |
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 |
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 |
In reply to this post by Lennart Augustsson
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 |
In reply to this post by Sittampalam, Ganesh
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 |
In reply to this post by John Goerzen-3
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 |
In reply to this post by Thomas DuBuisson
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 |
In reply to this post by Lennart Augustsson
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 |
In reply to this post by John Goerzen-3
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 |
In reply to this post by Lennart Augustsson
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 |
In reply to this post by Sittampalam, Ganesh
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 |
In reply to this post by Lennart Augustsson
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 |
In reply to this post by Ross Mellgren
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 |
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 |
In reply to this post by Lennart Augustsson
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 |
In reply to this post by Ross Mellgren
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 |
In reply to this post by John Goerzen-3
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 |
In reply to this post by Ross Mellgren
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 |
In reply to this post by John Goerzen-3
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 |
In reply to this post by Ross Mellgren
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 |
Free forum by Nabble | Edit this page |