|
|
1234
... 12
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
1234
... 12
|
Locked
