<br><br><div class="gmail_quote">On Sat, Jan 17, 2009 at 7:33 AM, Lennart Augustsson <span dir="ltr"><<a href="mailto:lennart@augustsson.net">lennart@augustsson.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Thinking that Functor allows you to apply a function to all elements<br>
in a collection is a good intuitive understanding. But fmap also<br>
allows applying a function on "elements" of things that can't really<br>
be called collections, e.g., the continuation monad.</blockquote><div><br></div><div>I hadn't even thought about fmap for continuations... interesting! </div><div><br></div><div>It falls out of the logic though doesn't it? </div>
<div><br></div><div>I'm not one to throw all the cool mathematical and logical thinking out for "simpler terms" or not covering the full usefulness of certain abstractions.</div><div><br></div><div>I know Haskell allows for lazy evaluation (as an implementation of non-strictness) but Haskell programmers are NOT allowed to be lazy :-)</div>
<div><br></div><div>Try learning the terms that are there... and ask for help if you need help... most of us are pretty helpful! </div><div><br></div><div>Improving documentation can pretty much *always* be done on any project, and it looks like that's coming out of this long thread that won't die, so kudos to the ones being the gadflies in this instance. It really looked at first like a long troll, but I think something very useful is going to come out of this!</div>
<div><br></div><div>Dave</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<font color="#888888"><br>
-- Lennart<br>
</font><div><div></div><div class="Wj3C7c"><br>
On Sat, Jan 17, 2009 at 11:17 AM, Andrew Coppin<br>
<<a href="mailto:andrewcoppin@btinternet.com">andrewcoppin@btinternet.com</a>> wrote:<br>
> Cory Knapp wrote:<br>
>><br>
>> Actually, that was part of my point: When I mention Haskell to people, and<br>
>> when I start describing it, they're generally frightened enough by the focus<br>
>> on pure code and lazy evaluation-- add to this the inherently abstract<br>
>> nature, and we can name typeclasses "cuddlyKitten", and the language is<br>
>> still going to scare J. R. Programmer. By "inherently mathematical nature",<br>
>> I didn't mean names like "monoid" and "functor", I meant *concepts* like<br>
>> monoid and functor. Not that either of them are actually terribly difficult;<br>
>> the problem is that they are terribly abstract. That draws a lot of people<br>
>> (especially mathematicians), but most people who aren' drawn by that are<br>
>> hugely put off-- whatever the name is. So, I guess my point is that the name<br>
>> is irrelevant: the language is going to intimidate a lot of people who are<br>
>> intimidated by the vocabulary.<br>
><br>
> Oh, I don't know. I have no idea what the mathematical definition of<br>
> "functor" is, but as far as I can tell, the Haskell typeclass merely allows<br>
> you to apply a function simultaneously to all elements of a collection.<br>
> That's pretty concrete - and trivial. If it weren't for the seemingly<br>
> cryptic name, nobody would think twice about it. (Not sure exactly what<br>
> you'd call it though...)<br>
><br>
> A monoid is a rather more vague concept. (And I'm still not really sure why<br>
> it's useful on its own. Maybe I just haven't had need of it yet?)<br>
><br>
> I think, as somebody suggested about "monad", the name does tend to inspire<br>
> a feeling of "hey, this must be really complicated" so that even after<br>
> you've understood it, you end up wondering whether there's still something<br>
> more to it than that.<br>
><br>
> But yes, some people are definitely put off by the whole "abstraction of<br>
> abstractions of abstraction" thing. I think we probably just need some more<br>
> concrete examples to weight it down and make it seem like something<br>
> applicable to the real world.<br>
><br>
> (Thus far, I have convinced exactly *one* person to start learning Haskell.<br>
> This person being something of a maths nerd, their main complaint was not<br>
> about naming or abstraction, but about the "implicitness" of the language,<br>
> and the extreme difficulty of visually parsing it. Perhaps not surprising<br>
> comming from a professional C++ programmer...)<br>
><br>
>> At the same time, I think everyone is arguing *for* better documentation.<br>
>> And you're probably right: better documentation will bring the abstract<br>
>> nonsense down to earth somewhat.<br>
><br>
> Amen!<br>
><br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
><br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br>