Comments from OCaml Hacker Brian Hurt

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

Re: Comments from OCaml Hacker Brian Hurt

Don Stewart-2
duncan.coutts:

> On Thu, 2009-01-15 at 19:46 +0000, Andrew Coppin wrote:
>
> > PS. As a small aside... Is the Monoid class actually used *anywhere* in
> > all of Haskell?
>
> Yes.
>
> They're 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.
>
> It is also used in the Foldable class which is a nice interface for
> traversing/visiting structures. Binary serialisation is also a monoid.

Also, xmonad configuration hooks are monoidal. So all those xmonad users
gluing together keybindings are using the Monoid class.

-- Don
_______________________________________________
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 Wagner
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

On Thu, Jan 15, 2009 at 3:51 PM, Don Stewart <[hidden email]> wrote:
duncan.coutts:
> On Thu, 2009-01-15 at 19:46 +0000, Andrew Coppin wrote:
>
> > PS. As a small aside... Is the Monoid class actually used *anywhere* in
> > all of Haskell?
>
> Yes.
>
> They're 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.
>
> It is also used in the Foldable class which is a nice interface for
> traversing/visiting structures. Binary serialisation is also a monoid.

Also, xmonad configuration hooks are monoidal. So all those xmonad users
gluing together keybindings are using the Monoid class.

-- Don
_______________________________________________
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

Peter Verswyvelen-2
In reply to this post by Don Stewart-2
Graphic composition using painters algorithm can be seen as a monoid.

data Graphic = Empty 
                    | Graphic `Over` Graphic
                    | Ellipse Bounds
                    | ....

instance Monoid Graphic where
    mempty = Empty
    mappend = Over

So all functions that operate on monoids can be used on Graphic as well, like mconcat that converts a [Graphic] into a Graphic


On Thu, Jan 15, 2009 at 9:51 PM, Don Stewart <[hidden email]> wrote:
duncan.coutts:
> On Thu, 2009-01-15 at 19:46 +0000, Andrew Coppin wrote:
>
> > PS. As a small aside... Is the Monoid class actually used *anywhere* in
> > all of Haskell?
>
> Yes.
>
> They're 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.
>
> It is also used in the Foldable class which is a nice interface for
> traversing/visiting structures. Binary serialisation is also a monoid.

Also, xmonad configuration hooks are monoidal. So all those xmonad users
gluing together keybindings are using the Monoid class.

-- Don
_______________________________________________
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

Gour-3
In reply to this post by Andrew Coppin
>>>>> "Andrew" == Andrew Coppin <[hidden email]> writes:

Andrew> If we *must* insist on using the most obscure possible name for
Andrew> everything, can we at least write some documentation that
Andrew> doesn't require a PhD to comprehend?? (Anybody who attempts to
Andrew> argue that "monoid" is not actually an obscure term has clearly
Andrew> lost contact with the real world.)

*thumb up*

Let the elitists enjoy in obscure terminology, but pls. write docs for
programmers (with examples included).


Sincerely,
Gour


--

Gour  | Zagreb, Croatia  | GPG key: C6E7162D
----------------------------------------------------------------

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

attachment0 (202 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Andrew Coppin
In reply to this post by Sebastian Sylvan-2
Sebastian Sylvan wrote:

>
>
> On Thu, Jan 15, 2009 at 7:46 PM, Andrew Coppin
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     The sad thing is, it's not actually complicated. The documentation
>     just makes it seem like it is! :-(
>
>
> This is so true for a heck of a lot of things. Existential
> quantification being just one of them. Loads of things in Haskell have
> big powerful (but scary) names which I really think intimidate people,
> the situation isn't helped when a lot of tutorials use the theoretical
> basis for the construct as a starting point, rather then actually
> describing the construct from the perspective of a programmer first
> (see Monads).
> Haskell really isn't that difficult compared to other languages, but
> people still get the impression that you need to be a big brain on a
> stick to use it, terminology is certainly part of the equation.
>
> This doesn't mean that making up new words is always better, but we
> should certainly strive to exploit any opportunity to clarify the
> issue and (this means that haddock comments and language
> books/tutorials shouldn't refer to academic papers first and foremost,
> but use common English and practical examples to describe what's being
> used, and academic nerds can consult the footnotes for their fill of
> papers containing pages of squiggly symbols!).

I basically agree with most of what you just said.

I'm not sure having a Monoid class is actually useful for anything - but
if we must have it, there seems to be little better possible name for
something so vague.

{-# 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. (Ideally it would also be pronouncible.) Of
course, nobody will take any notice, since changing this would induce
mass breakage for all the millions of LoC that already use the old name.

I think "documenting" a package by saying "read this academic paper"
should be banned. (Most especially if the paper in question isn't even
available online and can only be obtained from a reputable university
library!!) For example, I was looking at one of the monad transformers
(I don't even remember which one now), and the Haddoc contained some
type signatures and a line saying "read this paper". The paper in
question mentioned the transformer in passing as a 5-line example of how
to use polymorphism, but *still* without explaining how to actually use
it! (I.e., the paper was about polymorphism, and this transformer was
just a quick example.) What the hell??

I presume I can call "more documentation please!" without upsetting even
the most ardant category theory millitant... ;-)

Unfortunately, it's not going to write itself, and I have no idea how to
solve the problem. (That is, even if I wrote some better documentation
myself, I don't know how to submit it to get it into the official
package documentation. E.g., Parsec has a great tutorial document, but
the Haddoc pages are barren. It'd be easy to fix, but I don't know how
to submit the updates.)


_______________________________________________
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

Dan Piponi-2
In reply to this post by John Goerzen-3
On Thu, Jan 15, 2009 at 12:11 PM, John Goerzen <[hidden email]> wrote:
> On Thu, Jan 15, 2009 at 07:46:02PM +0000, Andrew Coppin wrote:
>> John Goerzen wrote:
>>
>> can we at least write some documentation that doesn't
>> require a PhD to comprehend?
> Several people have suggested this, and I think it would go a long way
> towards solving the problem.

That sounds like a good plan. Which precise bit of documentation
should I update? Make a new wiki page? Put it in here:
http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Monoid.html
--
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

Andrew Coppin
In reply to this post by Duncan Coutts
Duncan Coutts wrote:

> On Thu, 2009-01-15 at 19:46 +0000, Andrew Coppin wrote:
>
>  
>> PS. As a small aside... Is the Monoid class actually used *anywhere* in
>> all of Haskell?
>>    
>
> Yes.
>
> They're 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 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...

> It is also used in the Foldable class which is a nice interface for
> traversing/visiting structures. Binary serialisation is also a monoid.
>  

Foldable I'm vaguely familiar with. Its utility is more apparent.

_______________________________________________
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
In reply to this post by John Goerzen-3
On Thu, 2009-01-15 at 09:34 -0600, 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:
>
>
>   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!

No.  Never.  We will fight in the mailing lists.  We will fight in the
blog posts.  We will never surrender.

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?  Why should software engineering be the lone
exception?

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?

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

David Leimbach
In reply to this post by Duncan Coutts


On Thu, Jan 15, 2009 at 12:38 PM, Duncan Coutts <[hidden email]> wrote:
On Thu, 2009-01-15 at 19:46 +0000, Andrew Coppin wrote:

> PS. As a small aside... Is the Monoid class actually used *anywhere* in
> all of Haskell?

Yes.

They're 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.

It is also used in the Foldable class which is a nice interface for
traversing/visiting structures. Binary serialisation is also a monoid.

The Writer Monad requires that you give it a Monoid for it to do its work properly.
 

Duncan

_______________________________________________
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

MigMit
In reply to this post by Andrew Coppin
> Notice that "monoid" sounds almost *exactly* like "monad". And yet,  
> what you use them for is wildly unrelated.

Well, monads are monoids. I remember explaining you that...
_______________________________________________
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 Bugzilla from jonathanccast@fastmail.fm
Jonathan Cast 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?  Why should software engineering be the lone
> exception?
>
> 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?
>  

Indeed. Because abstract alebra is highly relevant to computer
programming. Oh, wait...

Many people complain that too many "database experts" don't know the
first thing about basic normalisation rules, SQL injection attacks, why
you shouldn't use cursors, and so forth. But almost nobody complains
that database experts don't know set theory or relational alebra. Why
should proramming be any different?

Don't get me wrong, there are mathematical concepts that are relevant to
computing, and we should encourage people to learn about them. But you
really *should not* need to do an undergraduate course in mathematical
theory just to work out how to concat two lists. That's absurd. Some
kind of balance needs to be found.

_______________________________________________
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

Thorkil Naur
In reply to this post by Peter Verswyvelen-2
Hello,

On Thursday 15 January 2009 19:59, Peter Verswyvelen wrote:

> It is rather funny. When we are young kids, we learn weird symbols like
> A B C  a b c 1  2  3
>
> which we accept after a while.
>
> Then we get to learn more complex symbols like
>
> ! ? + - /
>
> and that takes some time to get used to, but eventually, that works too.
>
> But Functor, Monoid or Monad, that we cannot accept anymore. Why, because
> these are not intuitive? Are the symbols above "intuitive"?

I think there is a simple explanation of this: Consider the amount of time you
spent, as a young kid, to learn to get used to these funny 1, 2, a, b, x, y,
+, - and so on. I haven't got the exact schedules from school, but my
impression is that we are talking about hours and hours of drill and
practice, over weeks, months, years. I mean, do you show your small children
(say, 5 years old) how to write numbers to represent, say, the number of
oranges in a bowl and then they comprehend after, say, a couple of minutes?
Or half an hour?

No. Learning to get used to such things, let alone use them effectively to
solve common problems, takes time. And also, of course, intense and qualified
guidance, in some form.

So, to learn to become familiar and effective in using new and complex
concepts, we should just accept that it sometimes may take a while. And
that's it. It is all a matter of practice, exposure, and guidance.

> ...

Best regards
Thorkil
_______________________________________________
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

dvogel
In reply to this post by Lennart Augustsson
Lennart Augustsson wrote:

> Why do people think that you should be able to understand everything
> without ever looking things up?
> I'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++.)
>  
ghee is ghee. There are variations of ghee, but when a cookbook calls
for ghee, just about any variation will work fine. Furthermore, whenever
a cookbook calls for ghee, you are making food. Conversely a monoid is
an algebraic structure. A Monoid (the type class) is an abstraction used
to ensure that a particular variation of a monoid is actually
representative of a monoid. There are many variations (:i Monoid shows
17 instances). Most are used for different purposes and few are
interchangeable for a given purpose.

Inventing new words definitely serves a purpose; it is a form of
abstraction. We need new words to manage conceptual complexity just as
we build abstractions to manage code complexity. In fact, Monoid was
once a new word that was invented to serve that very purpose.

I don't think the solution to this problem is to rename it to
Appendable. I think the "solution" is to allow programmers to alias
Monoid as Appendable similar to the way you can alias a module when you
imort it. The details of that solution would be very difficult to
introduce though.

Drew P. Vogel



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

signature.asc (258 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Bugzilla from jonathanccast@fastmail.fm
In reply to this post by John Goerzen-3
On Thu, 2009-01-15 at 10:56 -0600, John Goerzen wrote:

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

False.  We are failing to meet the un-realistic expectations of advanced
Perl/Python/Ruby/C/C++/Java/any other imperative language programmers as
to the ease with which they should be able to learn Haskell.

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

Bugzilla from jonathanccast@fastmail.fm
In reply to this post by Sittampalam, Ganesh
On Thu, 2009-01-15 at 17:13 +0000, Sittampalam, Ganesh wrote:
> Lennart Augustsson wrote:
> > Most people don't understand pure functional programming either.
> > Does that mean we should introduce unrestricted side effects in
> > Haskell?  
>
> No, just that we should seek to minimise the new stuff they have
> to get to grips with.

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.

(Or are you suggesting we should aim for programmers to be able to use
Haskell (or just certain libraries?) without learning it first?)

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

Bugzilla from jonathanccast@fastmail.fm
In reply to this post by Andrew Coppin
On Thu, 2009-01-15 at 21:17 +0000, Andrew Coppin wrote:

> Sebastian Sylvan wrote:
> >
> >
> > On Thu, Jan 15, 2009 at 7:46 PM, Andrew Coppin
> > <[hidden email] <mailto:[hidden email]>> wrote:
> >
> >     The sad thing is, it's not actually complicated. The documentation
> >     just makes it seem like it is! :-(
> >
> >
> > This is so true for a heck of a lot of things. Existential
> > quantification being just one of them. Loads of things in Haskell have
> > big powerful (but scary) names which I really think intimidate people,
> > the situation isn't helped when a lot of tutorials use the theoretical
> > basis for the construct as a starting point, rather then actually
> > describing the construct from the perspective of a programmer first
> > (see Monads).
> > Haskell really isn't that difficult compared to other languages, but
> > people still get the impression that you need to be a big brain on a
> > stick to use it, terminology is certainly part of the equation.
> >
> > This doesn't mean that making up new words is always better, but we
> > should certainly strive to exploit any opportunity to clarify the
> > issue and (this means that haddock comments and language
> > books/tutorials shouldn't refer to academic papers first and foremost,
> > but use common English and practical examples to describe what's being
> > used, and academic nerds can consult the footnotes for their fill of
> > papers containing pages of squiggly symbols!).
>
> I basically agree with most of what you just said.
>
> I'm not sure having a Monoid class is actually useful for anything - but
> if we must have it, there seems to be little better possible name for
> something so vague.
>
> {-# 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. (Ideally it would also be pronouncible.) Of
> course, nobody will take any notice, since changing this would induce
> mass breakage for all the millions of LoC that already use the old name.
>
> I think "documenting" a package by saying "read this academic paper"
> should be banned. (Most especially if the paper in question isn't even
> available online and can only be obtained from a reputable university
> library!!) For example, I was looking at one of the monad transformers
> (I don't even remember which one now), and the Haddoc contained some
> type signatures and a line saying "read this paper". The paper in
> question mentioned the transformer in passing as a 5-line example of how
> to use polymorphism, but *still* without explaining how to actually use
> it! (I.e., the paper was about polymorphism, and this transformer was
> just a quick example.) What the hell??
>
> I presume I can call "more documentation please!" without upsetting even
> the most ardant category theory millitant... ;-)

But you don't seem to be capable of separating your valid complaints
from your invalid ones.  Everyone wants the Haddock documentation to be
maximally useful.  But the should never be a confusion between
*defining* a term used in a library and *choosing* that term.  They are
simply different activities, and neither can be a substitute for the
other.

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

Thomas DuBuisson
In reply to this post by Bugzilla from jonathanccast@fastmail.fm
> 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.
_______________________________________________
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
In reply to this post by Andrew Coppin
On Thu, 2009-01-15 at 21:29 +0000, Andrew Coppin wrote:

> Jonathan Cast 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?  Why should software engineering be the lone
> > exception?
> >
> > 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?

> Indeed. Because abstract alebra is highly relevant to computer
> programming. Oh, wait...

Beg pardon?  That was an argument?  I'm sorry, but I can't infer your
middle term.

> Many people complain that too many "database experts" don't know the
> first thing about basic normalisation rules, SQL injection attacks, why
> you shouldn't use cursors, and so forth. But almost nobody complains
> that database experts don't know set theory or relational alebra.

I didn't know this.  I intend to start.  But, in any case, you picked
your counter-example *from within software engineering*, at least as
broadly understood.  My claim is that the computer industry as a whole
is *sick*, that we are simply going about this enterprise of dealing
with these (memory-limited) universal Turing machines (= implementations
of lambda calculus = universal recursive functions) *wrong*.  More cases
of this, within the computer industry, re-enforces my claim, rather than
weakening it.

> Don't get me wrong, there are mathematical concepts that are relevant to
> computing,

You mean like monads?  

>  and we should encourage people to learn about them. But you
> really *should not* need to do an undergraduate course in mathematical
> theory just to work out how to concat two lists.

Look, if you want (++), you know where to find it.  Or are you
complaining that you shouldn't have to study mathematics to understand
what (++) and, say, the choice operation on events, have in common?

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

Bugzilla from jonathanccast@fastmail.fm
In reply to this post by Thomas DuBuisson
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.

But this contention is false.

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

Duncan Coutts
In reply to this post by Andrew Wagner
On Thu, 2009-01-15 at 16:03 -0500, 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

Data.Foldable has several functions that use an arbitrary monoid.

A new API I've been working on for manipulating cabal files uses a tree
of values of any monoid type.

Sets of installation paths is a monoid and is parametrised by another
monoid type (so we can have both sets of file paths and path templates).
A similar point applies for package indexes.

Most of the utility functions for handling command line arguments in
Cabal are parameterised by the monoid, because different command line
flags are different kinds of monoid. Some are list monoids, others are
first / last style monoids.


But it's not just the ability to write generic functions that is
relevant. By making a type an instance of Monoid instead of exporting
emptyFoo, joinFoo functions it makes the API clearer because it shows
that we are re-using an existing familiar concept rather than inventing
a new one. It also means the user already knows that joinFoo must be
associative and have unit emptyFoo without having to read the
documentation.

Duncan

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