Comments from OCaml Hacker Brian Hurt

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

RE: Comments from OCaml Hacker Brian Hurt

Sittampalam, Ganesh
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.

Ganesh

==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================

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

Re: Comments from OCaml Hacker Brian Hurt

Justin Bogner
In reply to this post by Lennart Augustsson
"Lennart Augustsson" <[hidden email]> writes:
> By no means do I suggest that Wikipedia should replace Haskell library
> documentation.
> I think the libraries should be documented in a mostly stand-alone way
> (i.e., no references to old papers etc.).  In the case of Monoid, a
> few lines of text is enough to convey the meaning of it and gives an
> example.

I don't think references to old papers are a bad thing (they might be
good papers), but such references should certainly not be a replacement
for a brief explanation and helpful example!

_______________________________________________
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

Andrei Formiga
In reply to this post by Wouter Swierstra
On Thu, Jan 15, 2009 at 1:44 PM, Wouter Swierstra <[hidden email]> wrote:

>
> Would you call function composition (on endofunctions) "appending"? The join
> of a monad? A semi-colon (as in sequencing two imperative statements)? How
> do you append two numbers? Addition, multiplication, or something else
> entirely?
>
> All these operations are monoidal, i.e., are associative and have both left
> and right identities. If that's exactly what they have in common, why invent
> a new name? "Appendable" may carry some intuition, but it is not precise and
> sometimes quite misleading.
>

I think this highlights an interesting point: Haskell is more abstract
than most other languages. While in other languages "Appendable" might
just mean what Brian suggested in his post, "something with an empty
state and the ability to append things to the end", in Haskell it
applies to numbers and everything else that has an associative
operator, that is, everything that is a monoid. So "Appendable" for
numbers would be quite wrong; either it would never be used in
situations where one wanted to "append things to the end" (which is
limiting), or it would be used in these situations, which would be
quite confusing.

I think it is much more important to have good documentation about the
typeclasses (and everything else in the library). This issue was
mentioned recently in a discussion about monads, and the documentation
for the Haskell library is quite uninformative. It would be nice if 1)
people would not be scared of names like "monoid" and "functor" and 2)
the documentation clearly stated what these things are, in a
programming context, preferably with some examples. I think 2 would
mitigate some of the fear mentioned in 1, if newcomers started to
experience things like "hey, that's one funky-named stuff this monoid
thing, but I see here in the documentation that it is quite simple".


--
[]s, Andrei Formiga
_______________________________________________
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

Sittampalam, Ganesh
In reply to this post by Lennart Augustsson
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

==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================

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

Re: Comments from OCaml Hacker Brian Hurt

Don Stewart-2
In reply to this post by John Goerzen-3
jgoerzen:
> 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:

I'd also recommend yesterday's post

    http://intoverflow.wordpress.com/2009/01/13/why-haskell-is-beyond-ready-for-prime-time/
    Why Haskell is beyond ready for prime time

For a few other insights. (Notably, the joy of hoogle/hayoo library
search)
_______________________________________________
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 7:34 AM, John Goerzen <[hidden email]> quoted:

> I'd be inclined to call it something like "Appendable".

But I don't know what Appendable means. Maybe it means

> class Appendable a where
>    append :: a x -> x -> a x

ie. a container x's lets you can add an x to the end

or maybe it means

> class Appendable a where
>    append :: a -> x -> a

ie. something that you can append anything to

or maybe it means

> class Appendable a where
>    append :: a -> a -> a

so you can append any two elements of the same type together.

Why use words that are so vague when there's already word that
unambiguously says what the type class looks like? And even worse, why
use duplicate terminology to make it even harder to see when
mathematicians and computer scientists are talking about the same
thing, so widening the divide between two groups of people who have
much to share.
--
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

Lennart Augustsson
In reply to this post by Sittampalam, Ganesh
Beats me.  As I said, I don't think Haskell gets all the names right. :)

On Thu, Jan 15, 2009 at 5:15 PM, Sittampalam, Ganesh
<[hidden email]> wrote:

> 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
>
> ==============================================================================
> Please access the attached hyperlink for an important electronic communications disclaimer:
>
> http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
> ==============================================================================
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Comments from OCaml Hacker Brian Hurt

Paul Moore-2
In reply to this post by Lennart Augustsson
2009/1/15 Lennart Augustsson <[hidden email]>:
> Why do people think that you should be able to understand everything
> without ever looking things up?

Understand, no, but "have an intuition about", very definitely yes. In
mathematics (and I speak as someone with a mathematical degree, so if
I caricature anyone, please excuse it as failing memory rather than
intent!!!) there's a tendency to invent terminology, rather than use
natural names, because new names don't have unwanted connotations -
it's the need for precision driving things. In programming, the need
is for *communication* and as such, using words with natural - if
imprecise, and occasionally even (slightly) wrong - connotations is
extremely helpful.

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

If a significant proportion of words require me to look them up, my
flow of understanding is lost and I'll either give up, end up with a
muddled impression, or take far longer to understand than the recipe
merits (and so, I'll probably not use that cook book again).

> I'm not saying Haskell always gets naming right, all I want is to
> reuse words that exist instead of inventing new ones.

But you seem to be insisting that mathematical terminology is the
place to reuse from - whereas, in fact, computing might be a better
basis (although computing doesn't insist on the precision that maths
needs, so in any "that's not precisely what I mean" argument,
non-mathematical terminology starts off an a disadvantage, even though
absolute precision may not be the key requirement).

> (And 'monoid' is not category theory, it's very basic (abstract) algebra.)

Well, I did a MSc course in mathematics, mostly pure maths including
algebra, set theory and similar areas, and I never came across the
term. Of course, my degree was 25 years ago, so maybe "monoid" is a
term that wasn't invented then ;-))

> I don't
> know any category theory, but if someone tells me that blah is an
> endomorphism I'm happy to call it that, knowing that I have a name
> that anyone can figure out with just a little effort.

But unless you invest time researching, you can't draw any conclusions
from that. If someone tells you it's a mapping, you can infer that it
probably "maps" some things to one another, which gives you a
(minimal, imprecise, and possibly wrong in some corner cases, but
nevertheless useful) indication of what's going on.

Mathematical precision isn't appropriate in all disciplines.

Paul.
_______________________________________________
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 Sittampalam, Ganesh
Sittampalam, Ganesh wrote:
> 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'? :-)

That's a mistake - and in fact, it's a good demonstration of why Monoid
should not be named something like Appendable - because it misleads
people into thinking that the structure is less general than it really is.

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

David Menendez-2
In reply to this post by Ross Mellgren
On Thu, Jan 15, 2009 at 11:46 AM, Ross Mellgren <[hidden email]> wrote:
>
> Usually when encountering something like "Monoid" (if I didn't already know
> it), I'd look it up in the library docs. The problem I've had with this
> tactic is twofold:
>
> First, the docs for the typeclass usually don't give any practical examples,
> so sometimes it's hard to be sure that the "append" in "mappend" means what
> you think it means.

The documentation for Monoid is embarrassingly brief.

"The monoid class. A minimal complete definition must supply mempty
and mappend, and these should satisfy the monoid laws."

It doesn't even list the monoid laws!

> Second is that there appears to be no way to document an _instance_. It
> would be really handy if there were even a single line under "Instances >
> Monoid ([] a)" that explained how the type class was implemented for the
> list type. As it is, if you know what a Monoid is already, it's easy to
> figure out how it would be implemented.

Not necessarily. Any instance of MonadPlus (or Alternative) has at
least two reasonable Monoid instances: (mplus, mzero) and (liftM2
mappend, return mempty). [] uses the first and Maybe uses the second.

I recommend not creating direct instances of Monoid for this reason.
If you want to use Monoid with Int, you have to use Sum Int or Product
Int.

--
Dave Menendez <[hidden email]>
<http://www.eyrie.org/~zednenem/>
_______________________________________________
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

Lennart Augustsson
In reply to this post by Paul Moore-2
That's very true.  But programming is one where mathematical precision
is needed, even if you want to call it something else.

On Thu, Jan 15, 2009 at 6:04 PM, Paul Moore <[hidden email]> wrote:
>
> Mathematical precision isn't appropriate in all disciplines.
>
_______________________________________________
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 John Goerzen-3
John Goerzen wrote:
> Though if all we're talking about is naming, I would still maintain that
> newbie-friendly naming is a win.  We can always say "HEY MATHEMETICIANS:
> APPENDABLE MEANS MONOID" in the haddock docs ;-)

This is backwards.

The real problem here is that most people coming from other languages
aren't used to working with structures as abstract as monoids, and a
natural first instinct is to try to un-abstract them, in this case via
the suggested renaming.  The thought process tends to be something like
"I didn't have this problem in language X, Haskell must be doing
something wrong."

This instinct is not appropriate in the Haskell context.  (Although as
others have noted, the documentation doesn't do much to help guide
people through this.)

One of the most mind-bogglingly important features of Haskell is that it
  is actually possible to make effective use of structures such as
monoids in real code.  In most languages, you wouldn't even try this.

But if you're going to create a zoo of abstract structures like monoids,
with the aim of being able to use them as very general building blocks,
the last thing you should be doing is naming them according to
particular applications they have.  This goes against the goal of
abstracting in the first place, and will ultimately be confusing and
misleading.  (As I pointed out in another comment, the
misleadingly-named 'mappend' is an example of this.)

If there's an existing name for the exact structure in question, it
makes sense to use that name.  If you're unfamiliar with the structure,
then you're going to need to learn a name for it anyway - why not learn
a name by which it is already known in other contexts?

The main counter to the latter question is "I want to give it a new name
in order to connote an intended use," but unless the connotation in
question is as general as the structure being named, this is a mistake.

This issue is not unique to structures from abstract algebra & category
theory.  It can arise any time you have a very polymorphic function, for
example.  It can often make sense to provide a more specifically named
and typed alias for a very general function, to make its use more
natural and/or constrained in a particular context, e.g.:

   specificName :: SpecificType1 -> SpecificType2
   specificName = moreGeneralFunction

Similarly, in the case of monoid, we need to be able to do this, at
least conceptually:

   Appendable = Monoid

...possibly with some additional constraints.  In other words, "HEY
PROGRAMMERS: YOU CAN USE MONOID AS AN APPENDABLE THINGY (AMONG OTHER
THINGS)".

This is perhaps an argument for a class alias mechanism, such as the one
described at: http://repetae.net/recent/out/classalias.html

But in the absence of such a mechanism, we shouldn't succumb to the
temptation to confuse abstractions with their applications.

> Much as I dislike Java's penchant for 200-character names for things,
> I'm not sure Monoid is more descriptive than
> SomeSortOfGenericThingThatYouCanAppendStuffToClassTemplateAbstractInterfaceThingy
> :-)

Usable descriptive names for very abstract structures are just not
possible in general, except by agreeing on names, which can ultimately
come to seem descriptive.  For example, there's nothing fundamentally
descriptive about the word "append".

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

Ross Mellgren
In reply to this post by David Menendez-2
On Jan 15, 2009, at 1:21 PM, David Menendez wrote:

> On Thu, Jan 15, 2009 at 11:46 AM, Ross Mellgren <rmm-
> [hidden email]> wrote:
>> Second is that there appears to be no way to document an  
>> _instance_. It
>> would be really handy if there were even a single line under  
>> "Instances >
>> Monoid ([] a)" that explained how the type class was implemented  
>> for the
>> list type. As it is, if you know what a Monoid is already, it's  
>> easy to
>> figure out how it would be implemented.
>
> Not necessarily. Any instance of MonadPlus (or Alternative) has at
> least two reasonable Monoid instances: (mplus, mzero) and (liftM2
> mappend, return mempty). [] uses the first and Maybe uses the second.

Sorry my brain apparently misfired writing the original email. What I  
meant to say is that for the Monoid instance on [a] it's fairly easy  
(knowing what a Monoid is) to figure out how it's implemented, but  
that's not true for other classes or instances.

That is to say, I agree with you, and intended to up front ;-)

-Ross

_______________________________________________
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 Lennart Augustsson
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"? 

When I started learning Haskell I also found it insane that strange terminology was used everywhere... But every time I try to find a better name, the name is too specific for the situation at hand. Just like Appendable is a good name for specific instances of Monoid

In F# they renamed Monads to Workflows for the same reason. I find this just as confusing since a Monad has nothing to do with "work" and maybe a little bit with a single threaded "flow"... I would have hoped that we could all stick to the same terminology that was invented a long time ago...

Since Haskell is mainly for computer scientists, changing all of this to make it more accessible to newcomers might lead to the mistake: "if you try to please the whole world, you please nobody". 

I mainly think the problem is not the name, but the lack of many tiny examples demonstrating typical use cases for each concept.

On Thu, Jan 15, 2009 at 7:27 PM, Lennart Augustsson <[hidden email]> wrote:
That's very true.  But programming is one where mathematical precision
is needed, even if you want to call it something else.

On Thu, Jan 15, 2009 at 6:04 PM, Paul Moore <[hidden email]> wrote:
>
> Mathematical precision isn't appropriate in all disciplines.
>
_______________________________________________
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 John Goerzen-3
>>>>> "John" == John Goerzen <[hidden email]> writes:

John> I guess the bottom line question is: who is Haskell for?  Category
John> theorists, programmers, or both?  I'd love it to be for both, but
John> I've got to admit that Brian has a point that it is trending to
John> the first in some areas.

Thank you for so nicely put it together...


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 John Goerzen-3
John Goerzen wrote:

>   Haskell
>   developers, stop letting the category theorists name
>   things. Please. I beg of you.
>
> I'd like to echo that sentiment!
>
> He went on to add:
>
>   If you?re not a category theorists, and you're learning (or thinking
>   of learning) Haskell, don't get scared off by names like "monoid" or
>   "functor". And ignore anyone who starts their explanation with
>   references to category theory- you don't need to know category
>   theory, and I don't think it helps.
>
> I'd echo that one too.
>  

I am constantly shocked and saddened at the Haskell community's attitude
here. It seems to boil down to "Why should we make it easier to learn
Haskell? If people aren't prepaired to learn abstract algebra, category
theory, predicate logic and type system theory, why should we bother to
help them?" So much for the famously helpful Haskell community.

I am seriously beginning to wonder if the people using Haskell actually
realise what regular programmers do and don't know about. (You may
recall my recent straw poll where 80% of the programmer nerds I asked
had no clue what a "coroutine" is or what "existential quantification"
means.)

Notice that "monoid" sounds almost *exactly* like "monad". And yet, what
you use them for is wildly unrelated. In a similar vein, who here can
tell me off the top of their head what the difference between an
epimorphism and a hylomorphism is? I've got a brick-thick group theory
book sat right next to me and *I* can't even remember! Best of all, if
Joe Programmer makes any attempt to look these terms up, the information
they get will be almost completely useless for the purposes of writing
code or reading somebody else's.

I was especially amused by the assertion that "existential
quantification" is a more precise term than "type variable hiding". (The
former doesn't even tell you that the feature in question is related to
the type system! Even the few people in my poll who knew of the term
couldn't figure out how it might be related to Haskell. And one guy
argued that "forall" should denote universal rather than existential
quantification...) The sad thing is, it's not actually complicated. The
documentation just makes it seem like it is! :-(

Databases are based on the relational algebra. But that doesn't seem to
stop them from coming up with names for things that normal humans can
understand without first taking a course in relational algebra. (Does
the Oracle user guide state that "a relation is simply a subset of the
extended Cartesian product of the respective domains of its attributes"?
No, I don't *think* so! It says "Oracle manages tables which are made up
of rows..." Technically less precise, but vastly easier to comprehend.)
Why can't we do the same?

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

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.

Sorry if this sounds like just another clueless rant, but I'm really
getting frustrated about all this. Nobody seems to think there's
actually a problem here, despite the incontravertible fact that there is...



PS. As a small aside... Is the Monoid class actually used *anywhere* in
all of Haskell? Surely saying that something is a monoid is so vague as
to be unhelpful. "The most you can say about almost everything is
practically nothing" and all that. All it means is that the type in
question has a function that happens to take 2 arguments, and this
function happens to have an identity value. How is this information
useful? Surely what you'd want to know is what that function *does*?!
And since a given type can only be a Monoid instance in one way,
wouldn't passing the function and its identity in as parameters be
simpler anyway? The integers form at least two different monoids AFAIK...

_______________________________________________
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 Ross Mellgren
> For what it's worth, many (most/all?) programmers I know in person  
> don't have the slightest clue about Category Theory and they may  
> have known about abstract algebra once upon a time but certainly  
> don't remember any of it now. They usually understand the concepts  
> perfectly well enough but by "lay terms" or by no particular name at  
> all.

One of my friend once said "... and by 'programmer' I mean 'category  
theory specialist'".
_______________________________________________
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

John Goerzen-3
In reply to this post by Andrew Coppin
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 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.

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

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


On Thu, Jan 15, 2009 at 7:46 PM, Andrew Coppin <[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!).


--
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862

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

Duncan

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