Comments from OCaml Hacker Brian Hurt

[David Menendez-2]

On Thu, Jan 15, 2009 at 5:32 PM, Andrew Coppin
<[hidden email]> wrote:
>
> As an aside, the integers form two different monoids. Haskell can't [easily]
> handle that. Does anybody know of a language that can?

Some of the ML-derived languages can do that. Essentially, your code
takes another module which implements a monoid as an argument.

The catch is that you have to explicitly provide the monoid
implementation in order to use your code.

--
Dave Menendez <[hidden email]>
<http://www.eyrie.org/~zednenem/>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Manlio Perillo-3]

John Goerzen ha scritto:

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

I'm fine with current names.

However I would like to see better documentation, and examples.

You can't just have in the documentation:
this is xxx from yyy branch of mathematics, see this paper.

You should explain how (and why) to use xxx.

 > [...]


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

[Max Rabkin-2]

On Thu, Jan 15, 2009 at 3:16 PM, Cale Gibbard <[hidden email]> wrote:
> However, "Appendable" carries baggage with it which is highly
> misleading. Consider, for instance, the monoid of rational numbers
> under multiplication (which, by the way, is quite useful with the
> writer transformed list monad for dealing with probabilities) -- you
> can claim that multiplication here is a sort of "appending", perhaps,
> but it's not really appropriate.

It's rather funny that there's a mathematical sense in which all
monoid operations *are* appending. The free monoid on a set has
appending as its operation, and the free monoid is initial in the
category of monoids on that set (by definition), so all monoid
operations are appending, modulo some equivalence relation.

:)

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

On Thu, 2009-01-15 at 15:25 -0800, Max Rabkin wrote:

> On Thu, Jan 15, 2009 at 3:16 PM, Cale Gibbard <[hidden email]> wrote:
> > However, "Appendable" carries baggage with it which is highly
> > misleading. Consider, for instance, the monoid of rational numbers
> > under multiplication (which, by the way, is quite useful with the
> > writer transformed list monad for dealing with probabilities) -- you
> > can claim that multiplication here is a sort of "appending", perhaps,
> > but it's not really appropriate.
>
> It's rather funny that there's a mathematical sense in which all
> monoid operations *are* appending. The free monoid on a set has
> appending as its operation, and the free monoid is initial in the
> category of monoids on that set (by definition), so all monoid
> operations are appending, modulo some equivalence relation.

Right.  So we start explaining that to new Haskellers.  We already have
participants in this discussion who can never quite remember where the
term Monad comes from; and now we need them to remember some complicated
argument about quotients of free monoids justifying the term `Append'?

jcc


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

[Dan Doel]

On Thursday 15 January 2009 6:21:28 pm David Menendez wrote:

> On Thu, Jan 15, 2009 at 5:32 PM, Andrew Coppin
>
> <[hidden email]> wrote:
> > As an aside, the integers form two different monoids. Haskell can't
> > [easily] handle that. Does anybody know of a language that can?
>
> Some of the ML-derived languages can do that. Essentially, your code
> takes another module which implements a monoid as an argument.
>
> The catch is that you have to explicitly provide the monoid
> implementation in order to use your code.

You can do that in Haskell, as well, although it will end up uglier than ML.
You can write your own dictionary type:

  data Monoid a = Monoid { unit :: a , bin :: m -> m -> m }

And pass that around:

  twice :: Monoid m -> m -> m
  twice mon m = bin mon m m

And even manually simulate locally opening the dictionary with a where clause

  twice mon m = m ++ m
   where (++) = bin mon

This is, after all, what GHC translates type classes into behind the scenes
(although that isn't necessarily how they must be implemented).

Some folks even argue that type classes are overused and this style should be
significantly more common.

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

[Cale Gibbard]

2009/1/15 Andrew Coppin <[hidden email]>:
> OK, well then my next question would be "in what say 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...

I can't speak from the perspective of the Cabal developers, but
combining configurations with partial information using a monoid
operation is generally a good way to structure things. Basically, this
would be analogous to the way that the First monoid (or the Last
monoid) works, but across a number of fields. You have an empty or
default configuration which specifies nothing that serves as the
identity, and then a way of layering choices together, which is the
monoid operation.

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

[haskell-2]

Thomas DuBuisson wrote:
>> How does forcing them to learn proposed terminology such as `Appendable'
>> help here?  Learners of Haskell do still need to learn what the new word
>> means.
>
> The contention is that 'Appendable' is an intuitive naming that people
> will already have a rudimentary grasp of.  This as opposed to Monoid,
> which absolutely requires looking up for the average coder.

Intuition tells me:

* 'Appendable' add an element to the back of a (finite) linear collection.
* There is a 'Prependable' somewhere that add the element to the front.
* There is an inverse 'pop' or 'deque' operation nearby.

Absolutely none of those things are true.  Let's try for 'Mergeable'

* mconcat joins two collections, not a collection and an element.
* Is should be a split operation.

The above is true for the list instance, but false in general.  Look at the
instances already given that violate the "collection" idea:

> Monoid Any
> Monoid All
> Monoid (Last a)
> Monoid (First a)
> Num a => Monoid (Product a)
> Num a => Monoid (Sum a)

And I don't even see an (Ord a)=>(Max a) or a Min instance.

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.

ONE.

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

[Derek Elkins]

On Thu, 2009-01-15 at 14:11 -0600, John Goerzen wrote:

> On Thu, Jan 15, 2009 at 07:46:02PM +0000, Andrew Coppin wrote:
> > John Goerzen wrote:
> >
> > If we *must* insist on using the most obscure possible name for  
> > everything, can we at least write some documentation that doesn't  
> > require a PhD to comprehend?? (Anybody who attempts to argue that  
> > "monoid" is not actually an obscure term has clearly lost contact with  
> > the real world.)
>
> Several people have suggested this, and I think it would go a long way
> towards solving the problem.  The problem is: this documentation can
> really only be written by those that understand the concepts,
> understand how they are used practically, and have the time and
> inclination to submit patches.  Experience suggests there may be no
> such people out there :-)
>
> > As somebody else said, it basically comes down to this: Who the hell is  
> > Haskell actually "for"? If it's seriously intended to be used by  
> > programmers, things need to change. And if things aren't going to  
> > change, then let's all stop pretending that Haskell actually cares about  
> > real programmers.
>
> It might surprise you to see me say this, but I don't see this
> discussion as necessarily a weakness.  I know of no other language
> community out there that has such a strong participation of both
> academics and applied users.  This is a great strength.  And, of
> course, Haskell's roots are firmly in academia.  
>
> I think there there is a ton of interest in Haskell from the, ahem,
> "real world" programmer types.  In fact, it seems to me that's where
> Haskell's recent growth has been.  There are a lot of things showing
> up on Hackage relating to networking, Unicode encoding, databases, web
> apps, and the like.
>
> The nice thing about Haskell is that you get to put the theory in
> front of a lot of people that would like to use it to solve immediate
> programming problems.  But they will only use it if you can explain it
> in terms they understand.

There are plenty of "real world" programmer types who are using these
scarily named things, Monoid, Monad, Functor, Existential
Quantification.  Programmers such as you*.  Despite poor documentation,
which everyone agrees could be improved, they've somehow managed to
understand these things anyway.  My impression is that to most of them
Monoids, Functors, and Monads are Just Another Interface and Existential
Quantification is Just Another Language Feature.  There are poorly
documented interfaces in every language**.  Any "real world" programmer
has some (plenty...) of experience dealing with this issue.  These
programmers do what they need to do to get stuff done.  Again, somehow
they learn how to use these things without waiting for "us" to provide
an "explanation" in "terms they can understand;" too busy trying to get
stuff done.

>
> There are a number of efforts in that direction: various websites,
> articles, books, libraries, etc.  And I think the efforts are
> succeeding.  But that doesn't mean there is no room for improvement.

No one doubts that there is room for improvement.  However, the
direction is better documentation, not different names.  Better names is
fine, but I have not heard any remotely convincing alternative for any
of the above terms.

* Or me for that matter.  I'm not an academic now and certainly wasn't
when I started learning Haskell.  I didn't know what a monoid was, had
never heard of category theory or monads or functors.  I was using
monads and functors and monoids in less than a month after I started
using Haskell.

** Heck, papers and decades worth of mathematical texts at almost every
level is a heck of a lot more documentation than most "poorly
documented" interfaces have.

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

[Derek Elkins]

On Thu, 2009-01-15 at 21:59 +0000, Thomas DuBuisson wrote:
> > How does forcing them to learn proposed terminology such as `Appendable'
> > help here?  Learners of Haskell do still need to learn what the new word
> > means.
>
> The contention is that 'Appendable' is an intuitive naming that people
> will already have a rudimentary grasp of.  This as opposed to Monoid,
> which absolutely requires looking up for the average coder.

In programming, -every- name requires looking up or some other way of
checking meaning.  Other than perhaps arithmetic operators (and I have
had that bite me), I have -never- in any language written code using a
name without having some assurance that it actually meant what I thought
it meant.  Usually you have to "look something up" to even know a name
exists no matter how "intuitive" it turns out to be.

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

[Derek Elkins]

On Thu, 2009-01-15 at 18:21 -0500, Cale Gibbard wrote:
> While you're absolutely correct and I agree with you, to be fair,
> essentially all mathematicians have a sense of "rigourisability"
> (whether they recognise it or not), which is a peculiar standard that
> they apply to everything they hear or read. The level of rigour at
> which mathematicians communicate is designed not to bore the listener
> with details that they could easily supply for themselves, being an
> intelligent mathematician, and not a mechanical abstraction.

Indeed.  One way to describe "rigorizable" is that it is (ideally) just
enough precision to be unambiguous.  Programmers don't have that luxury
and thus clarity and hence communication suffer, which was exactly my
point.

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

[John Lato-2]

Manlio Perillo wrote:

>
> I'm fine with current names.
>
> However I would like to see better documentation, and examples.
>
> You can't just have in the documentation:
> this is xxx from yyy branch of mathematics, see this paper.
>
> You should explain how (and why) to use xxx.
>

Absolutely this!  I would rather have to look up Monoid than see
Appendable used for operations that don't fit my notion of appending.
I don't care much what things are called as long as it's accurate.
Even so, I typically find Haskell's documentation to be not very
helpful, because it's aimed towards category theorists.  That is,
Haskell documentation often seems to take the approach "The reader is
familiar with [branch of abstract mathematics], so knows all these
concepts.  The job of the documentation is to show how standard
terminology from [branch of abstract math] is written in Haskell".

The problem with this is that most people aren't familiar with general
abstract nonsense, and this documentation is useless for those, i.e.
most, people.  In fact, most people don't care about how abstract
nonsense is written in Haskell.  They care about solving their
particular problems, and are only interested in abstract nonsense to
the sense that it can be useful in solving those problems.
Overwhelmingly the documentation does not show how particular concepts
apply to actual programming problems, or any concrete problems at all.

Here is the current complete documentation for Data.Monoid 'mappend',
which happens to be a good example of which I speak:

    An associative operation

That could mean anything.  There are lots of associative operations.
Should I believe the name that somehow this operation is append-like?
If so, and I'm using a list instance, where are items appended to?  Is
it an append onto the tail of the list, or is it really a cons?  I
would expect the documentation to cover this, but it doesn't.  Far too
often the documentation fails to provide this sort of useful,
practical information.

This is the problem faced by an abstract-nonsense unaware user:  I
want to accomplish [some task].  Some blogger wrote that [monoids,
functors, arrows, etc.] provide a good solution.  But when I look up
[monoids, functors, etc.] in [some academic paper], it doesn't show
how these concepts apply to the problem at hand, or indeed any
programming problem at all.  In fact, I can't even understand what the
doc says without first learning about [even more abstract stuff].  So
now the user needs to develop a strong background in [some abstract
topic] he/she doesn't care about just to figure out *if* that abstract
topic could possibly be useful.  At this point most users will give
up.  If instead they had access to documentation that says "[Monoids]
are useful programming abstractions because they can solve problems A,
B, and C in these manners, and incidentally they can do all this other
stuff too", the same users would not only stick with Haskell longer,
they would increase their theoretical awareness at the same time.  I
think even the most elitist Haskell users would think this is a good
outcome.

Of course this better documentation would need to be written.
Somebody upthread (Duncan?) suggested that suitable individuals may
not exist, and I agree with that.  Of people who understand the
material well enough to document it, many are busy doing other work,
and many have no interest or are ideologically opposed to writing
documentation of this type.

This situation reminds me very much of a particularly well-known
article by Milton Babbitt, "Who Cares If You Listen."  I expect that
many Haskellers would find it interesting at the least.

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

[John Goerzen-3]

Derek Elkins wrote:

> No one doubts that there is room for improvement.  However, the
> direction is better documentation, not different names.  Better names is
> fine, but I have not heard any remotely convincing alternative for any
> of the above terms.

After thinking about it, I think you are right.  But, there is a problem
-- nobody is stepping up to write that documentation.  If we can't get
it, then perhaps we ought to fall back on better names.

If we *can* get it, all the better, because these things need good docs,
regardless of what they're called.

I can see it now: a monoid by any other name would smell as sweet...

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

[Luke Palmer-2]

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

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

 * Appendable

or

 * Monoid

But Appendable is wrong. 

merge :: Ord a => [a] -> [a] -> [a]
merge [] ys = ys
merge xs [] = xs
merge (x:xs) (y:ys) | x <= y = x : merge xs (y:ys)
                              | otherwise = y : merge (x:xs) ys

newtype MergeList a = MergeList [a]

instance (Ord a) => Monoid (MergeList a) where
    mempty = MergeList []
    mappend (MergeList xs) (MergeList ys) = MergeList (merge xs ys)

This is a perfectly good monoid -- one I have used -- but in no sense would I call MergeList "appendable".

Also, in what sense is mappend on Endo appending?

I just realized that the name "mappend" sucks :-).  (++) would be great!

In any case, to me being a Monoid is about having an associative operator, not about "appending".  The only fitting terms I can think of are equally scary ones such as "semigroup".

Which is worse: naming things with scary category names, as in "monad" and "monoid", or naming things with approachable popular names that are wrong (wrt. to their popular usage), as in "class" and "instance".

In the former case, the opinion becomes "Haskell is hard -- what the hell is a monad?"; in the latter it becomes "Haskell sucks -- it's class system is totally stupid" because we are violating people's intuitions, rather than providing them with none whatsoever.

In a lot of cases there is a nice middle ground.  Cases where (1) we can find an intuitive word that does not have a popular CS meaning, or (2) where the popular CS meaning is actually correct ("integer"?).  But eg. programming with monads changes the way you think; we cannot rewire people's brains just-in-time with a word.

I like the word Monad.  It makes people know they have to work hard to understand them. 

Luke

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

[Michael Giagnocavo]

>Your talk of undergraduate courses to concat two lists isn't grounded
>in any kind of reality, muddies the waters, and probably scares people
>away from Haskell by giving the impression that it's much harder than
>it is.

I've been studying Haskell a bit to understand and learn more about functional programming (I'm using F#). I have to say, the scariest thing I've faced was exactly what you say. Everything I read built "monads" up to be this ungraspable thing like quantum mechanics. Even after I actually understood it well enough, I kept thinking I must be missing something because there's so much fuss about it.

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

[Luke Palmer-2]

On Thu, Jan 15, 2009 at 7:02 PM, Michael Giagnocavo <[hidden email]> wrote:

>Your talk of undergraduate courses to concat two lists isn't grounded
>in any kind of reality, muddies the waters, and probably scares people
>away from Haskell by giving the impression that it's much harder than
>it is.

I've been studying Haskell a bit to understand and learn more about functional programming (I'm using F#). I have to say, the scariest thing I've faced was exactly what you say. Everything I read built "monads" up to be this ungraspable thing like quantum mechanics.

Yeah, monad is on the same level as quantum mechanics.  Both are equally simple and popularly construed as ungraspable.

(However to grasp monads easily you need a background in FP; to grasp QM easily you need a background in linear algebra)

Luke

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

[Dan Weston]

Richard Feinman once said: "if someone says he understands quantum
mechanics, he doesn't understand quantum mechanics".

But what did he know...

Luke Palmer wrote:

> On Thu, Jan 15, 2009 at 7:02 PM, Michael Giagnocavo <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>      >Your talk of undergraduate courses to concat two lists isn't grounded
>      >in any kind of reality, muddies the waters, and probably scares people
>      >away from Haskell by giving the impression that it's much harder than
>      >it is.
>
>     I've been studying Haskell a bit to understand and learn more about
>     functional programming (I'm using F#). I have to say, the scariest
>     thing I've faced was exactly what you say. Everything I read built
>     "monads" up to be this ungraspable thing like quantum mechanics.
>
>
> Yeah, monad is on the same level as quantum mechanics.  Both are equally
> simple and popularly construed as ungraspable.
>
> (However to grasp monads easily you need a background in FP; to grasp QM
> easily you need a background in linear algebra)
>
> Luke
>

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

[Bertram Felgenhauer-2]

Andrew Wagner wrote:

> I think perhaps the correct question here is not "how many instances of
> Monoid are there?", but "how many functions are written that can use an
> arbitrary Monoid". E.g., the fact that there are a lot of instances of Monad
> doesn't make it useful. There are a lot of instances of Monad because it's
> useful to have instances of Monad. Why? Because of
> http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad.html !
> Look at all the cool stuff you can automagically do with your type just
> because it's an instance of Monad! I think that's the point. What can you do
> with arbitrary Monoids? Not much, as evidenced by
> http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Monoid.html

One example where Monoids (in full generality) are useful is that of
measurements in the Data.Sequence paper (which is sadly not implemented
in the library, although it is used to maintain the length for efficient
indexing),

   http://www.soi.city.ac.uk/~ross/papers/FingerTree.html

The concept applies to any tree that represents an ordered list.

The basic idea is that given a measurement for single elements,

    class Monoid v => Measured a v where
         measure :: a -> v

we can annotate a tree with cached measurements of the corresponding
sequences,

    data Tree a v = Empty | Leaf v a | Node v (Tree a v) (Tree a v)

    measureTree :: Measured a v => Tree a v -> v
    measureTree Empty = mzero
    measureTree (Leaf v _) = v
    measureTree (Node v _ _) = v

which can be calculated easily by smart constructors:

    leaf :: Measured a v => a -> Tree a v
    leaf a = Leaf (measure a) a

    node :: Measured a v => Tree a v -> Tree a v -> Tree a v
    node l r = Node (measureTree l `mappend` measureTree r) l r

Because v is a monoid, the construction satisfies the law

    measureTree = mconcat . map measure . toList

where
    toList Empty = []
    toList (Leaf _ a) = [a]
    toList (Node _ l r) = toList l ++ toList r

All usually efficient tree operations, insertion, deletion, splitting,
concatenation, and so on, will continue to work, if the cached values
are ignored on pattern matching and the smart constructors are used
for constructing the new trees. measure or `mappend` will be called
for each smart constructor use - if they take constant time, the
complexity of the tree operations doesn't change.

Applications include:
  - finding and maintaining the sum of any substring of the sequence.
  - maintaining minimum and maximum of the list elements
  - maintaining the maximal sum of any substring of the sequence
    (this can be done by measuring four values for each subtree:
    1. the sum of all elements of the sequence
    2. the maximum sum of any prefix of the sequence
    3. the maximum sum of any suffix of the sequence
    4. the maximum sum of any substring of the sequence)

I also found the idea useful for
    http://projecteuler.net/index.php?section=problems&id=220

starting out with
    -- L system basis
    class Monoid a => Step a where
        l :: a
        r :: a
        f :: a

and then providing a few instances for Step, one of which was a binary
tree with two measurements.

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

[John A. De Goes]

+1 to that

Regards,

John

On Jan 15, 2009, at 4:10 PM, Cale Gibbard wrote:

> 2009/1/15 Sittampalam, Ganesh <[hidden email]>:
>> Lennart Augustsson wrote:
>>> 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.
>>
>> Then why does it have a member named 'mappend'? :-)
>>
>> Ganesh
>
> Good question. The names of the methods of the Monoid class are  
> inappropriate.
>
> My personal preference would be:
>
> class Monoid m where
>   zero :: m
>   (++) :: m -> m -> m
>
> (in the Prelude of course)
>
> - Cale
> _______________________________________________
> 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

[Cory Knapp]

Perhaps as a math/CS major I'm a bit biased here, but as a haskell
neophyte, I think my opinion is at least somewhat relevant...

The immediate problem is certainly documentation. No one would groan
more than once after hearing a term from abstract math if there was
sufficient Haskell-oriented language. I can say that a monad is an
endo-functor (in this case on Hask) which is the composition of two
natural transformations; the clever parrot I am, I can even understand
most of this... but that doesn't mean anything to me in a Haskell
context; until a new Haskell programmer can find a Hasktionary with
relevant terms in a Haskell context, everything is meaningless-- even
though I can understand (i.e. apply meaning to) the definition of a
monad on Hask, I can't apply the sort of meaning required to program
with a monad without either figuring it out through experience, or
seeing it shown to me in a programmer-relevant way (Or rather, both need
to happen.)

On the other hand, I really, really like getting behind things and
understanding the theory. In C, well, C is the theory-- if I want to go
deeper, I need to learn as much as I can about the way a computer
actually, physically works (why, why, then, even have higher level
languages?) or I need to take a history lesson so I can figure out the
math that helped out... With Haskell, the theory is right there, staring
at me. If the documentation were better, I wouldn't *need* to learn it,
but if my curiosity is piqued, it's right there. Naming monoid
"appendable" kills that-- by trying to make things "warm and fuzzy",
you've weakened one of my strongest motivators for programming
(especially in Haskell), namely how much of a direct application of cool
math it is. I know I'm not the only one.

As far as I know, one of the draws of Haskell is the inherent
mathematical nature of it-- in how many other languages do people write
proofs of correctness because they don't want to write test-cases? The
kind of people who are going to be drawn to a language which allows
[(x,y)| x<-somelist, y<-someotherlist] are overall, a mathy set of
people, and trying to make our terms fuzzy isn't going to change that.
So why not embrace it?

This leads to another point: monoids are probably called monoids for the
same reason monads are monads: they came directly out of higher math.
Someone did sit down trying to name this cool new Haskell idea he had
and then say, "Oh, of course, it's just [insert "obscure" math word
that's used in Haskell]! I'll keep that name." He sat down, and said,
"Oh! Wait if I use [insert "obscure" math word that's used in Haskell]
this problem is simpler." It's named for what it is: a monoid, a monad,
a functor, existential quantification.

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. I shouldn't be more able to discuss abstract
math with a conservatory dropout theater student than with someone who
plans, for a living, to put well-formed formulae onto a finite state
machine. I am.

I don't expect the average programmer to be able to give me a
well-ordering of the reals (with choice, of course), or to prove that
category C satisfying property P must also satisfy property Q; but for
God's sake, they better have a good intuition for basic set theory,
basic graph theory, and most importantly mathematical abstraction. What
is "good coding style" if not making the exact same types of
abstractions that mathematicians make? Again, I don't expect a CS major
to write a good proof, to explain rings to a 13 year old, or actually
"do" real math; but I expect one to be able to read "In abstract
algebra, a branch of mathematics, a monoid is an algebraic structure
with a single, associative binary operation and an identity element. "
and be able to get a basic intuitive idea for what a monad is; with some
thought of course. I would go so far as to say that a programmer should
be able to intuitively understand "a system of objects and associative
arrows", even if they can't "do math" with that... Programmers shouldn't
be allowed to get away with the absolute ignorance of math that at least
75% of the CS majors at my school pass with.

This doesn't mean there isn't a serious problem with Haskell
documentation; it also doesn't mean that everyone should have a minor in
math to be a programmer, but isn't an introductory course in discrete
math required for most CS programs? Then why are programmers so afraid
of basic mathematical definitions? And why do so many wear their
ignorance and fear of math as a badge of honor?

Sorry that this came out as a bit of a rant, but I spend enough time
trying to convince people that math isn't horrid and disgusting...

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

On Thu, 2009-01-15 at 17:06 -0500, Steve Schafer wrote:
> On Thu, 15 Jan 2009 13:21:57 -0800, you wrote:
>
> >Where, in the history of western civilization, has there ever been an
> >engineering discipline whose adherents were permitted to remain ignorant
> >of the basic mathematical terminology and methodology that their
> >enterprise is founded on?
>
> Umm, all of them?

Really.  So the engineer who designed the apartment building I'm in at
the moment didn't know any physics, thought `tensor' was a scary math
term irrelevant to practical, real-world engineering, and will only read
books on engineering that replace the other scary technical term
`vector' with point-direction-value-thingy?  I think I'm going to sleep
under the stars tonight...

> >No one may be a structural engineer, and remain ignorant of physics.  No
> >one may be a chemical engineer, and remain ignorant of chemistry.  Why
> >on earth should any one be permitted to be a software engineer, and
> >remain ignorant of computing science?
>
> Do you know any actual working structural or chemical engineers?

Um, no.  I try to avoid people as much as possible; computers at least
make sense.  Also anything else to do with the real world :)

> Most
> engineering disciplines require a basic grasp of the underlying theory,
> yes, but not much beyond that.

Perhaps I should have said `completely ignorant'?  Or do you think that

  join . join = join . fmap join

is of the same level of theoretical depth as quantum orbital mechanics?

> Pretty much everything else is covered by
> rules (either rules of thumb or published standards).

> Show me an electrical engineer who can explain the physics of a pn
> junction and how it acts as a rectifier, or a civil engineer who can
> explain why the stress/strain curve of a steel beam has the shape that
> it does,

Again, do engineers know *what* stress is?  Do they understand terms
like `tensor'?  Those things are the rough equivalents of terms like
`monoid'.

jcc



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