Comments from OCaml Hacker Brian Hurt

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
237 messages Options
1 ... 56789101112
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Conal Elliott
Thanks, Bob!  I'm with on both counts: Monad is misrepresented as central in code composition; and (Monad m) => (a -> m b) -> (m a -> m b) is a much nicer type (for monadic extension), only in part because it encourages retraining away from sequential thinking.  I encountered this nicer formulation only recently, and am glad to finally understand why I've been so uncomfortable with the type of (>>=).

  - Conal

2009/1/15 Thomas Davie <[hidden email]>

On 15 Jan 2009, at 16:34, John Goerzen 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:

[snip]
Sorry, I'm not going to refer to that paragraph, instead, I'm going to point out how depressing it is, that the message we're getting across to new haskellers is that "Monads, and variations on monads and extensions to monads and operations on monads are the primary way Haskell combines code-".  We have loads of beautiful ways of combining code (not least ofc, simple application), why is it than Monad is getting singled out as the one that we must use for everything?  

My personal suspicion on this one is that Monad is the one that makes concessions to imperative programmers, by on of its main combinators (>>=) having the type (>>=) :: (Monad m) => m a -> (a -> m b) -> m b, and not the much nicer type (>>=) :: (Monad m) => (a -> m b) -> (m a -> m b).

Bob



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Comments from OCaml Hacker Brian Hurt

Conal Elliott
In reply to this post by Dougal Stanton
Well-put.  Thanks!      - Conal

On Fri, Jan 16, 2009 at 1:52 AM, Dougal Stanton <[hidden email]> wrote:
On Thu, Jan 15, 2009 at 11:54 PM, ChrisK <[hidden email]> wrote:

>
> So the original article, which coined 'Appendable', did so without much
> thought in the middle of a long post.  But it does show the thinking was
> about collections and there is one ONE instance of Monoid at
>
> http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Monoid.html#t%3AMonoid
>
> that is about a collection (Monoid ([] a)) that has a split operation.

The blind man at the back takes firm hold of the tail and says, "But
why do we need to call it an *elephant*? No-one knows what that is.
Everyone knows what a rope is, so we should just call it a rope."

And that is how the elephant came to be labelled a rope in all the guide books.

:-)

Cheers,

D
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Heinrich Apfelmus
In reply to this post by David Virebayre
david48 wrote:

> I don't care about the name, it's ok for me that the name
> mathematicians defined is used, but there are about two categories of
> people using haskell and
> I would love that each concept would be adequately documented for everyone:
> - real-world oriented programming documentation with usefulness and
> examples for the non mathematician
> - the mathematics concepts and research papers for the mathematicians
> for those who want/need to go further
>
> As someone mentionned, the documentation can't really be done by
> someone that doesn't fully grok the concepts involved.

Good account of the current documentation situation.

Hm, what about the option of opening Bird's "Introduction on Functional
Programming using Haskell" in the section about fold? Monoid is on page
62 in the translated copy I've got here.

Does Hutton's book mention them? Real World Haskell?


I don't think that I would try to learn a programming language, for
example Python, without obtaining a paper book on it.


Regards,
H. Apfelmus

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Anton van Straaten
In reply to this post by Andrew Coppin
Andrew Coppin wrote:
> Abstraction is a great thing to have. I'd just prefer it to not look so
> intimidating;

What makes it look intimidating?

If the answer is "it looks intimidating because the documentation
consists of nothing more than a mathematical term, without a definition,
and a reference to a paper", then I agree with you, and it seems so does
most everyone else.

But if the intimidation factor is coming from preconceptions like "it's
mathy, therefore it's scary"; or "it's an unfamiliar term, therefore
it's scary", then I think that's something that the reader needs to work
on, not the designers and documenters of Haskell.

Computer programming is full of terms that need to be learned, and if
anything terms like "monoid" are fantastically useful because they're so
precisely defined, and are part of a larger well-defined universe.

I would have thought that any "true programmer" (like a true Scotsman)
could appreciate the separation of concerns and factoring that's gone
into abstract algebra.  The idea that it's not relevant to programming
(an implication that was made earlier) misses a bigger picture.  How
could a collection of very general structures associated with general
operations *not* be relevant to programming?

Given that mathematicians have spent centuries honing these useful
structures, and given that plenty of applications for them in
programming have been identified, it would virtually be a crime not to
use them where they make sense.

(A crime against... humanity?  I look forward to the trials at The Hague
of errant programming language and library designers.)

> the majority of these abstractions aren't actually
> "complicated" in any way, once you learn what they are...

Which underscores my question - what's the source of the intimidation, then?

> If you're going to implement an abstraction for monoids, you might as
> well call it "monoid". On that I agree.

Excellent.

> I still think "appendable" (where it really *is* used only for
> appendable collections) is a more useful abstraction to have, since it's
> more specific. Generalising things is nice, but if you generalise things
> too far you end up with something too vague to be of practical use.

That's only one side of the story.

Quite a few examples of monoid use has been given in this thread.  How
many of them are actually uses of Appendable, I wonder?  There's an
equal and opposite risk of under-generalizing here: if you design
something to take an Appendable argument, and if Appendable precludes
other kinds of "non-appendable" monoids, you may be precluding certain
argument types that would otherwise be perfectly reasonable, and
building in restrictions to your code for no good reason - restrictions
that don't relate to the actual requirements of the code.

Of course, if you're just saying you want Appendable as an alias for
Monoid, that's reasonable (I mentioned that possibility in another
message), but a similar effect might be achieved by documentation that
points out that appendability is one application for monoids.

A more suitable "friendly" synonym for "monoid" might be "combinable",
which can more easily be defended: a binary operation combines its
arguments by definition, since it turns two arguments into one result.

But again, it would make more sense to observe in the documentation that
monoids are combinable things, for various reasons that others have
already addressed.

I like the reasons that Manuel Chakravarty gave - in part, "the language
and the community favours drilling down to the core of a problem and
exposing its essence in the bright light of mathematical precision".  If
anyone finds that scary, my advice to them is to wear sunglasses until
they get used to it.

In practice, what that means is don't fuss over the fact that there's a
lot of unfamiliar knowledge that seems important -- yes, it is
important, but you can use Haskell quite well without knowing it all.  I
speak from experience, since I'm not a mathematician, let alone a
category theorist.

Anton

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Anton van Straaten
In reply to this post by Andrew Coppin
Andrew Coppin wrote:

> Duncan Coutts wrote:
>> [Monoids are] used quite a lot in Cabal. Package databases are monoids.
>> Configuration files are monoids. Command line flags and sets of command
>> line flags are monoids. Package build information is a monoid.
>>  
>
> OK, well then my next question would be "in what way is defining
> configuration files as a monoid superior to, uh, not defining them as a
> monoid?" What does it allow you to do that you couldn't otherwise? I'm
> not seeing any obvious advantage, but you presumably did this for a
> reason...

It makes those things generically combinable.

Anton

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Andrew Coppin
In reply to this post by Cory Knapp
Cory Knapp wrote:
> As far as I know, one of the draws of Haskell is the inherent
> mathematical nature of it.

It's also simultaneously one of the biggest things that puts people off.

Perhaps as we can curb this with sufficient documentation, as others
have suggested.

> But there's a deeper problem here, one that can't be resolved inside
> the Haskell community. The problem is that the "Math?! Scary! Gross!"
> attitude that's so pervasive in our society is hardly less pervasive
> in the computer subculture.

No arguments here!

However, that at least *is* completely beyond our power to alter.
Unfortunately.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Andrew Coppin
In reply to this post by Anton van Straaten
Anton van Straaten wrote:

> Andrew Coppin wrote:
>> Abstraction is a great thing to have. I'd just prefer it to not look
>> so intimidating;
>
> What makes it look intimidating?
>
> If the answer is "it looks intimidating because the documentation
> consists of nothing more than a mathematical term, without a
> definition, and a reference to a paper", then I agree with you, and it
> seems so does most everyone else.
>
> But if the intimidation factor is coming from preconceptions like
> "it's mathy, therefore it's scary"; or "it's an unfamiliar term,
> therefore it's scary", then I think that's something that the reader
> needs to work on, not the designers and documenters of Haskell.

I guess you're right.

A problem I see a lot of [and other people have mentioned this] is that
a lot of documentation presents highly abstracted things, and gives *no
hint* of why on earth these might possibly be useful for something.
(E.g., "coarbitrary". Wuh??) Perhaps fixing this *would* help make
Haskell more accessible. (The "other" problem of course is that what
documentation that does exist is scattered all over the place...)

I still think existential quantification is a step too far though. :-P

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Niklas Broberg
> I still think existential quantification is a step too far though. :-P

Seriously, existential quantification is a REALLY simple concept, that
you would learn week two (or maybe three) in any introductory course
on logic. In fact, I would argue that far more people probably know
what existential quantification is than that know what a monoid is.
:-)

Cheers,

/Niklas
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Anton van Straaten
Niklas Broberg wrote:
>> I still think existential quantification is a step too far though. :-P
>
> Seriously, existential quantification is a REALLY simple concept, that
> you would learn week two (or maybe three) in any introductory course
> on logic. In fact, I would argue that far more people probably know
> what existential quantification is than that know what a monoid is.
> :-)

Andrew's core objection here seems reasonable to me.  It was this:

 > {-# LANGUAGE ExistentialQuantification #-} is an absurd name and
 > should be changed to something that, at a minimum, tells you it's
 > something to do with the type system.

But I suspect I part company from Andrew in thinking that something like
ExistentiallyQuantifiedTypes would be a perfectly fine alternative.

Anton

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Bugzilla from jonathanccast@fastmail.fm
On Fri, 2009-01-16 at 18:14 -0500, Anton van Straaten wrote:

> Niklas Broberg wrote:
> >> I still think existential quantification is a step too far though. :-P
> >
> > Seriously, existential quantification is a REALLY simple concept, that
> > you would learn week two (or maybe three) in any introductory course
> > on logic. In fact, I would argue that far more people probably know
> > what existential quantification is than that know what a monoid is.
> > :-)
>
> Andrew's core objection here seems reasonable to me.  It was this:
>
>  > {-# LANGUAGE ExistentialQuantification #-} is an absurd name and
>  > should be changed to something that, at a minimum, tells you it's
>  > something to do with the type system.
>
> But I suspect I part company from Andrew in thinking that something like
> ExistentiallyQuantifiedTypes would be a perfectly fine alternative.

+1

(Although shouldn't it really be ExistentiallyQuantifiedConstructorTypes
or something?  If GHC ever actually adds first-class existentials, what
is Cabal going to call *that* then?)

jcc


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Niklas Broberg
In reply to this post by Anton van Straaten
On Sat, Jan 17, 2009 at 12:14 AM, Anton van Straaten
<[hidden email]> wrote:

>>> I still think existential quantification is a step too far though. :-P
>>
>> Seriously, existential quantification is a REALLY simple concept, that
>> you would learn week two (or maybe three) in any introductory course
>> on logic. In fact, I would argue that far more people probably know
>> what existential quantification is than that know what a monoid is.
>> :-)
>
> Andrew's core objection here seems reasonable to me.  It was this:
>
>> {-# LANGUAGE ExistentialQuantification #-} is an absurd name and
>> should be changed to something that, at a minimum, tells you it's
>> something to do with the type system.
>
> But I suspect I part company from Andrew in thinking that something like
> ExistentiallyQuantifiedTypes would be a perfectly fine alternative.

Well, I definitely agree to that, but that's not what he wrote in the
post I answered. My point was that existential quantification is
nowhere near scary.

But yes - making the Types part explicit is certainly not a bad idea.
+1 for ExistentiallyQuantifiedTypes.

Cheers,

/Niklas
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Derek Elkins
In reply to this post by Bugzilla from jonathanccast@fastmail.fm
On Fri, 2009-01-16 at 15:21 -0800, Jonathan Cast wrote:

> On Fri, 2009-01-16 at 18:14 -0500, Anton van Straaten wrote:
> > Niklas Broberg wrote:
> > >> I still think existential quantification is a step too far though. :-P
> > >
> > > Seriously, existential quantification is a REALLY simple concept, that
> > > you would learn week two (or maybe three) in any introductory course
> > > on logic. In fact, I would argue that far more people probably know
> > > what existential quantification is than that know what a monoid is.
> > > :-)
> >
> > Andrew's core objection here seems reasonable to me.  It was this:
> >
> >  > {-# LANGUAGE ExistentialQuantification #-} is an absurd name and
> >  > should be changed to something that, at a minimum, tells you it's
> >  > something to do with the type system.
> >
> > But I suspect I part company from Andrew in thinking that something like
> > ExistentiallyQuantifiedTypes would be a perfectly fine alternative.
>
> +1

This focus on names is ridiculous.  I agree that good names are
beneficial, but they don't have to encode everything about the referent
into themselves.  Haskell is called "Haskell" not
"StaticallyTypedPurelyFunctionalProgrammingLanguage."  In this
particular case, it's absurd.  In this case the name is only of mnemonic
value, other than that it could be called FraggleRock.  Regardless of
the name you are going to have to look up what it refers to (in the
user's guide), or, having already done that earlier, just know what it
means.

> (Although shouldn't it really be ExistentiallyQuantifiedConstructorTypes
> or something?  If GHC ever actually adds first-class existentials, what
> is Cabal going to call *that* then?)

FreeExistentials.  FirstClassExistentials would also be reasonable.
Though renaming the current LANGUAGE tag to
LocalExistentialQuantification would be better.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Documentation [Comments from OCaml Hacker Brian Hurt]

Dan Piponi-2
In reply to this post by Paul Moore-2
On Fri, Jan 16, 2009 at 12:09 PM, Paul Moore <[hidden email]> wrote:

> How about "associativity means that how you pair up the operations
> does not affect the result"?

I think a better way is this: If you have an element of a monoid, a,
there are two ways to combine it with another element, on the left or
on the right. You get

a `mappend` x
or
x `mappend` a.

Now suppose you're going to combine a with x on the left and y on the
right. Associativity means it doesn't matter which you do first.

You can think of each element of a monoid as having two sides. The
idea is that the left side and right side are independent things that
don't interfere with each other. For example, adding some stuff at the
beginning of a list, and adding some stuff at the end of a list, don't
affect each other, and it doesn't matter which you do first.

That's the idea that associativity captures.
--
Dan
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Cory Knapp
In reply to this post by Andrew Coppin
Andrew Coppin wrote:
> Cory Knapp wrote:
>> As far as I know, one of the draws of Haskell is the inherent
>> mathematical nature of it.
>
> It's also simultaneously one of the biggest things that puts people off.
>
> Perhaps as we can curb this with sufficient documentation, as others
> have suggested.
>
Actually, that was part of my point: When I mention Haskell to people,
and when I start describing it, they're generally frightened enough by
the focus on pure code and lazy evaluation-- add to this the inherently
abstract nature, and we can name typeclasses "cuddlyKitten", and the
language is still going to scare J. R. Programmer. By "inherently
mathematical nature", I didn't mean names like "monoid" and "functor", I
meant *concepts* like monoid and functor. Not that either of them are
actually terribly difficult; the problem is that they are terribly
abstract. That draws a lot of people (especially mathematicians), but
most people who aren' drawn by that are hugely put off-- whatever the
name is. So, I guess my point is that the name is irrelevant: the
language is going to intimidate a lot of people who are intimidated by
the vocabulary.

At the same time, I think everyone is arguing *for* better
documentation. And you're probably right: better documentation will
bring the abstract nonsense down to earth somewhat.

>> But there's a deeper problem here, one that can't be resolved inside
>> the Haskell community. The problem is that the "Math?! Scary! Gross!"
>> attitude that's so pervasive in our society is hardly less pervasive
>> in the computer subculture.
>
> No arguments here!
>
> However, that at least *is* completely beyond our power to alter.
> Unfortunately.
>
Indeed.

Cheers,
Cory
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Documentation [Comments from OCaml Hacker Brian Hurt]

Cory Knapp
In reply to this post by Dan Piponi-2
Dan Piponi wrote:

> On Fri, Jan 16, 2009 at 12:09 PM, Paul Moore <[hidden email]> wrote:
>
>  
>> How about "associativity means that how you pair up the operations
>> does not affect the result"?
>>    
>
> I think a better way is this: If you have an element of a monoid, a,
> there are two ways to combine it with another element, on the left or
> on the right. You get
>
> a `mappend` x
> or
> x `mappend` a.
>
> Now suppose you're going to combine a with x on the left and y on the
> right. Associativity means it doesn't matter which you do first.
>
> You can think of each element of a monoid as having two sides. The
> idea is that the left side and right side are independent things that
> don't interfere with each other. For example, adding some stuff at the
> beginning of a list, and adding some stuff at the end of a list, don't
> affect each other, and it doesn't matter which you do first.
>
> That's the idea that associativity captures.
> --
> Dan
>  
Indeed, that's the idea that associativity captures; but explicitly
pointing out that the left and the right side are their own bubbles is a
bit misleading: addition is associative, but there is no "left and
right." I think a better wording is:

"
If you have an element of a monoid, a, there are two ways to combine it
with another element, on the left or on the right. You get

a `mappend` x
or
x `mappend` a.

Now suppose you're going to combine a with x on the left and y on the
right. Associativity means it doesn't matter which you do first.

So
x `mappend` (a `mappend` y) = (x `mappend` a) `mappend` y, but as we've
pointed out,
a `mappend` x
is not necessarily the same as
x `mappend` a
although a specific monoid might have them be equal, for example Int
(where mappend is *).


Is that better?

Cory
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: Comments from OCaml Hacker Brian Hurt

David Virebayre
In reply to this post by Bulat Ziganshin-2
On Fri, Jan 16, 2009 at 3:10 PM, Bulat Ziganshin
<[hidden email]> wrote:
> Hello david48,
>
> Friday, January 16, 2009, 4:16:51 PM, you wrote:
>
>> Upon reading this thread, I asked myself : what's a monoid ? I had no
>> idea. I read some posts, then google "haskell monoid".
>
> it would be interesting to google "C++ class" or "Lisp function" and
> compare experience :)

The first link for C++ class I find on google is the wikipedia article
which I find understandable, has examples and explanations that relate
to programming.
OTOH, the wikipedia article for monoid is less easy (for me), though
now I can follow the first paragraphs. But I don't find on the page
how/why/where it relates to programming.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

David Virebayre
In reply to this post by Bugzilla from jonathanccast@fastmail.fm
On Fri, Jan 16, 2009 at 4:04 PM, Jonathan Cast
<[hidden email]> wrote:

> On Fri, 2009-01-16 at 14:16 +0100, david48 wrote:
>> Part of the problem is that something like a monoid is so general that
>> I can't wrap my head around why going so far in the abstraction.
>> For example, the writer monad works with a monoid; using the writer
>> monad with strings makes sense because the mappend operation for lists
>> is (++), now why should I care that I can use the writer monad with
>> numbers
>> which it will sum ?
>
> To accumulate a running count, maybe?  A fairly common pattern for
> counting in imperative languages is
>
> int i = 0;
> while (<get a value>) i+= <count of something in value>
>
> Using the writer monad, this turns into
>
> execWriter $ mapM_ (write . countFunction) $ getValues

well thank you for the example, if I may ask something: why would I
need to write a running count this way instead of, for example, a non
monadic fold, which would probably result in clearer and faster code
(IMHO) ?
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Comments from OCaml Hacker Brian Hurt

David Virebayre
In reply to this post by Heinrich Apfelmus
On Fri, Jan 16, 2009 at 10:28 PM, Apfelmus, Heinrich
<[hidden email]> wrote:

> david48 wrote:

>> I don't care about the name, it's ok for me that the name
>> mathematicians defined is used, but there are about two categories of
>> people using haskell and
>> I would love that each concept would be adequately documented for everyone:
>> - real-world oriented programming documentation with usefulness and
>> examples for the non mathematician
>> - the mathematics concepts and research papers for the mathematicians
>> for those who want/need to go further

>> As someone mentionned, the documentation can't really be done by
>> someone that doesn't fully grok the concepts involved.

> Good account of the current documentation situation.

> Hm, what about the option of opening Bird's "Introduction on Functional
> Programming using Haskell" in the section about fold? Monoid is on page
> 62 in the translated copy I've got here.

I don't have this book. I have real world haskell and purely
functional data structures though.

> Does Hutton's book mention them? Real World Haskell?

the first time it is mentionned in RWH according to the index is page
266 where we read
"We forgot to test the Monoid instance"
...
"...of Monoid, which is the class of types that support appending and
empty elements:"

Appending.... :)

On the other hand, on page 320 there is a nice explanation of Monoid,
and on page 380, which isn't mentionned in the index, there might be
the first time one can understand why the writer monad works with
monoids instead of lists: to be able to use better suited data types
for appending.

All of this is still lacking the great why : why/how an abstraction so
generic can be useful.
I'm starting to believe that the only reason to make a datatype an
instance of Monoid is... why not ! since it's not hard to find an
associative operation and a neutral element.

> I don't think that I would try to learn a programming language, for
> example Python, without obtaining a paper book on it.

I would, if the online documentation makes it possible, and then I
would buy a paper book later, to go further or for reference.
That's how I learned Haskell, and much later I've bought my first book.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Andrew Coppin
In reply to this post by Anton van Straaten
Anton van Straaten wrote:

> Niklas Broberg wrote:
>>> I still think existential quantification is a step too far though. :-P
>>
>> Seriously, existential quantification is a REALLY simple concept, that
>> you would learn week two (or maybe three) in any introductory course
>> on logic. In fact, I would argue that far more people probably know
>> what existential quantification is than that know what a monoid is.
>> :-)
>
> Andrew's core objection here seems reasonable to me.  It was this:
>
> > {-# LANGUAGE ExistentialQuantification #-} is an absurd name and
> > should be changed to something that, at a minimum, tells you it's
> > something to do with the type system.
>
> But I suspect I part company from Andrew in thinking that something
> like ExistentiallyQuantifiedTypes would be a perfectly fine alternative.

I would suggest that ExistentiallyQuantifiedTypeVariables would be an
improvement on just ExistentialQuantification - but I'd still prefer the
less cryptic HiddenTypeVariables. (Since, after all, that's all this
actually does.)

Either way, nobody is going to change the name, so why worry?



PS. There exist courses on logic? That could be potentially interesting...

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Andrew Coppin
In reply to this post by Cory Knapp
Cory Knapp wrote:

> Actually, that was part of my point: When I mention Haskell to people,
> and when I start describing it, they're generally frightened enough by
> the focus on pure code and lazy evaluation-- add to this the
> inherently abstract nature, and we can name typeclasses
> "cuddlyKitten", and the language is still going to scare J. R.
> Programmer. By "inherently mathematical nature", I didn't mean names
> like "monoid" and "functor", I meant *concepts* like monoid and
> functor. Not that either of them are actually terribly difficult; the
> problem is that they are terribly abstract. That draws a lot of people
> (especially mathematicians), but most people who aren' drawn by that
> are hugely put off-- whatever the name is. So, I guess my point is
> that the name is irrelevant: the language is going to intimidate a lot
> of people who are intimidated by the vocabulary.

Oh, I don't know. I have no idea what the mathematical definition of
"functor" is, but as far as I can tell, the Haskell typeclass merely
allows you to apply a function simultaneously to all elements of a
collection. That's pretty concrete - and trivial. If it weren't for the
seemingly cryptic name, nobody would think twice about it. (Not sure
exactly what you'd call it though...)

A monoid is a rather more vague concept. (And I'm still not really sure
why it's useful on its own. Maybe I just haven't had need of it yet?)

I think, as somebody suggested about "monad", the name does tend to
inspire a feeling of "hey, this must be really complicated" so that even
after you've understood it, you end up wondering whether there's still
something more to it than that.

But yes, some people are definitely put off by the whole "abstraction of
abstractions of abstraction" thing. I think we probably just need some
more concrete examples to weight it down and make it seem like something
applicable to the real world.

(Thus far, I have convinced exactly *one* person to start learning
Haskell. This person being something of a maths nerd, their main
complaint was not about naming or abstraction, but about the
"implicitness" of the language, and the extreme difficulty of visually
parsing it. Perhaps not surprising comming from a professional C++
programmer...)

> At the same time, I think everyone is arguing *for* better
> documentation. And you're probably right: better documentation will
> bring the abstract nonsense down to earth somewhat.

Amen!

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