tips about scalaz

Hi Alberto,
I'm also into scalaz this time, and found it very interesting. 
I think the best way to learn scalaz is first to understand some concepts like functor, applicative functor, monoid, monad, and all those things. You may want to check this blog from Heiko Seeberger to start with: https://hseeberger.wordpress.com/2010/11/25/introduction-to-category-theory-in-scala/ . From there, you will have some interesting references like Runar's blog. I found Heiko's blog very useful when I started with scalaz.
Then, one you digest the blog, you may want to start having a look at the code, see how some Functors are  implemented for example. Scalaz provides some examples in their code base as well, you may want to check those ones too.
That's all from me -- scalaz very newbie  too --  hope it helps.
Anwar.


On Tue, Jul 5, 2011 at 4:09 AM, Alberto SOUZA <alots.ssa@gmail.com> wrote:

Hi, i'm trying to just understand scalaz a little more. I did not find a lot of examples until now. Do you have any tips? It seems to be very good. Could be videos, practical examples..

Did you look at the scalaz home page? There are quite a few presentations on there now; there's Nick Partridge's excellent one on why you might wish to derive scalaz and some useful features that it has. And many more... There are also many examples of scalaz usage, although I agree that these do not always demonstrate the power of some of the typeclasses.
http://code.google.com/p/scalaz/
Chris

Date: Mon, 4 Jul 2011 23:09:56 -0300
Subject: [scala-user] tips about scalaz
From: alots.ssa@gmail.com
To: scala-user@googlegroups.com

Hi, i'm trying to just understand scalaz a little more. I did not find a lot of examples until now. Do you have any tips? It seems to be very good. Could be videos, practical examples..

Yes Chris, yes i did. I was just looking for more contextualized examples :). Like the presentation that they have there. Thank you for the tips.

On Tue, Jul 5, 2011 at 5:17 AM, Chris Marshall <oxbow_lakes@hotmail.com> wrote:

Did you look at the scalaz home page? There are quite a few presentations on there now; there's Nick Partridge's excellent one on why you might wish to derive scalaz and some useful features that it has. And many more... There are also many examples of scalaz usage, although I agree that these do not always demonstrate the power of some of the typeclasses.
http://code.google.com/p/scalaz/
Chris

Date: Mon, 4 Jul 2011 23:09:56 -0300
Subject: [scala-user] tips about scalaz
From: alots.ssa@gmail.com
To: scala-user@googlegroups.com

Hi, i'm trying to just understand scalaz a little more. I did not find a lot of examples until now. Do you have any tips? It seems to be very good. Could be videos, practical examples..

Keep a lookout for Heiko Seeberger's scaladays talk, which was very much on the practical side of scalaz. A shame he only had 25 minutes to speak! Also Jason Zaugg recently gave a talk at the London Scala eXchange, again mainly on the derivation of scalaz. This is available online right now: http://skillsmatter.com/podcast/home/talk-by-jason-zaugg
Chris

Date: Tue, 5 Jul 2011 10:43:02 -0300
Subject: Re: [scala-user] tips about scalaz
From: alots.ssa@gmail.com
To: oxbow_lakes@hotmail.com
CC: scala-user@googlegroups.com

Yes Chris, yes i did. I was just looking for more contextualized examples :). Like the presentation that they have there. Thank you for the tips.

On Tue, Jul 5, 2011 at 5:17 AM, Chris Marshall <oxbow_lakes@hotmail.com> wrote:

Did you look at the scalaz home page? There are quite a few presentations on there now; there's Nick Partridge's excellent one on why you might wish to derive scalaz and some useful features that it has. And many more... There are also many examples of scalaz usage, although I agree that these do not always demonstrate the power of some of the typeclasses.
http://code.google.com/p/scalaz/
Chris

Date: Mon, 4 Jul 2011 23:09:56 -0300
Subject: [scala-user] tips about scalaz
From: alots.ssa@gmail.com
To: scala-user@googlegroups.com

Hi, i'm trying to just understand scalaz a little more. I did not find a lot of examples until now. Do you have any tips? It seems to be very good. Could be videos, practical examples..

I'd be a lot more interested in scalaz if they were serious about documentation. I've looked at scalaz several times, and each time came to the conclusion that if the implementors weren't willing to document their APIs (which arguably need more documentation than a standard API because they are so far from what the average programmer has experienced) then I wasn't willing to spend the time chasing down all the various references, articles, etc. that might or might not explain one element of scalaz.
It's too bad, I suspect there's stuff in scalaz that could be really useful. Perhaps at some time the authors will have the core functionality complete, and be able to concentrate on documentation.
Ken

I suggested them opening a wiki on github so we can start adding non abstract examples ourselves and have it all centralized.

A clear policy regarding documentation would be great to. Do they *want* people to contribute documentation?

On Wed, Jul 6, 2011 at 3:58 PM, Ken McDonald <ykkenmcd@gmail.com> wrote:

I'd be a lot more interested in scalaz if they were serious about documentation. I've looked at scalaz several times, and each time came to the conclusion that if the implementors weren't willing to document their APIs (which arguably need more documentation than a standard API because they are so far from what the average programmer has experienced) then I wasn't willing to spend the time chasing down all the various references, articles, etc. that might or might not explain one element of scalaz.
It's too bad, I suspect there's stuff in scalaz that could be really useful. Perhaps at some time the authors will have the core functionality complete, and be able to concentrate on documentation.
Ken

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ugh not this again. We are so serious about documentation that we
write it in such a way as to be machine-checked. This is how serious
we are -- we will even dismiss demands to degenerate our documentation.

Here is a perfect example of someone using this documentation to
provide an answer to a question:
http://groups.google.com/group/scalaz/msg/7f9e98a6dff3a4cf

There are plenty of usage examples:
https://github.com/scalaz/scalaz/tree/master/example/src/main/scala/scal...

There are blog posts, videos, slides and papers. Shall I list them?
I'd just be preaching to the choir.

There are people offering to help you when you have queries and we
will use the documentation to *answer them in a robust way*. We want
the documentation to exist in such a way that you do not have to rely
on any individual or group of individuals -- we don't keep all the
side-effects in our head, which you would have to manually query, like
you might find on other projects -- this is directly against the goal.
Documentation needs to be independent of brains, it needs to be
trustworthy (*machine-checked*) and it needs to be very comprehensive
(see aforementioned link to thread for a great example of this).

Honestly, if this is not enough documentation for you, then the
problem may not be the "documentation" part in "documentation for you."

Yes, contributing examples would be great. I believe github has a
facility for submitting requests for inclusion.

On 07/07/11 06:16, Tomás Lázaro wrote:
> I suggested them opening a wiki on github so we can start adding
> non abstract examples ourselves and have it all centralized.
>
> A clear policy regarding documentation would be great to. Do they
> *want* people to contribute documentation?
>
> On Wed, Jul 6, 2011 at 3:58 PM, Ken McDonald
> wrote:
>
>> I'd be a lot more interested in scalaz if they were serious
>> about documentation. I've looked at scalaz several times, and
>> each time came to the conclusion that if the implementors weren't
>> willing to document their APIs (which arguably need more
>> documentation than a standard API because they are so far from
>> what the average programmer has experienced) then I wasn't
>> willing to spend the time chasing down all the various
>> references, articles, etc. that might or might not explain one
>> element of scalaz.
>>
>> It's too bad, I suspect there's stuff in scalaz that could be
>> really useful. Perhaps at some time the authors will have the
>> core functionality complete, and be able to concentrate on
>> documentation.
>>
>> Ken
>>
>

Okay, you just convinced me not to use scalaz too soon either.

On Wed, Jul 6, 2011 at 5:44 PM, Tony Morris <tonymorris@gmail.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ugh not this again. We are so serious about documentation that we
write it in such a way as to be machine-checked. This is how serious
we are -- we will even dismiss demands to degenerate our documentation.

Here is a perfect example of someone using this documentation to
provide an answer to a question:
http://groups.google.com/group/scalaz/msg/7f9e98a6dff3a4cf

There are plenty of usage examples:
https://github.com/scalaz/scalaz/tree/master/example/src/main/scala/scalaz/example

There are blog posts, videos, slides and papers. Shall I list them?
I'd just be preaching to the choir.

There are people offering to help you when you have queries and we
will use the documentation to *answer them in a robust way*. We want
the documentation to exist in such a way that you do not have to rely
on any individual or group of individuals -- we don't keep all the
side-effects in our head, which you would have to manually query, like
you might find on other projects -- this is directly against the goal.
Documentation needs to be independent of brains, it needs to be
trustworthy (*machine-checked*) and it needs to be very comprehensive
(see aforementioned link to thread for a great example of this).

Honestly, if this is not enough documentation for you, then the
problem may not be the "documentation" part in "documentation for you."

Yes, contributing examples would be great. I believe github has a
facility for submitting requests for inclusion.


On 07/07/11 06:16, Tomás Lázaro wrote:
> I suggested them opening a wiki on github so we can start adding
> non abstract examples ourselves and have it all centralized.
>
> A clear policy regarding documentation would be great to. Do they
> *want* people to contribute documentation?
>
> On Wed, Jul 6, 2011 at 3:58 PM, Ken McDonald <ykkenmcd@gmail.com>
> wrote:
>
>> I'd be a lot more interested in scalaz if they were serious
>> about documentation. I've looked at scalaz several times, and
>> each time came to the conclusion that if the implementors weren't
>> willing to document their APIs (which arguably need more
>> documentation than a standard API because they are so far from
>> what the average programmer has experienced) then I wasn't
>> willing to spend the time chasing down all the various
>> references, articles, etc. that might or might not explain one
>> element of scalaz.
>>
>> It's too bad, I suspect there's stuff in scalaz that could be
>> really useful. Perhaps at some time the authors will have the
>> core functionality complete, and be able to concentrate on
>> documentation.
>>
>> Ken
>>
>


- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4U11IACgkQmnpgrYe6r627twCgggDnjm4JA18ZRDFa3Y7ONrTf
HT4An1Dj2JhkksSJx2p/Ug8EcCVk/piq
=lXXa
-----END PGP SIGNATURE-----

Hi,

On Wed, Jul 6, 2011 at 11:44 PM, Tony Morris wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ugh not this again. We are so serious about documentation that we
> write it in such a way as to be machine-checked. This is how serious
> we are -- we will even dismiss demands to degenerate our documentation.
>
> Here is a perfect example of someone using this documentation to
> provide an answer to a question:
> http://groups.google.com/group/scalaz/msg/7f9e98a6dff3a4cf
This example is funny :-)
From documentation I expect something that will bring additional
information to the main subject (the code in this case).
I'd not expect one of the Scalaz committers to show me that he knows
what that code does.

>
> There are plenty of usage examples:
> https://github.com/scalaz/scalaz/tree/master/example/src/main/scala/scal...
>
> There are blog posts, videos, slides and papers. Shall I list them?
> I'd just be preaching to the choir.
>
> There are people offering to help you when you have queries and we
> will use the documentation to *answer them in a robust way*. We want
> the documentation to exist in such a way that you do not have to rely
> on any individual or group of individuals -- we don't keep all the
> side-effects in our head, which you would have to manually query, like
> you might find on other projects -- this is directly against the goal.
> Documentation needs to be independent of brains, it needs to be
> trustworthy (*machine-checked*) and it needs to be very comprehensive
> (see aforementioned link to thread for a great example of this).
>
> Honestly, if this is not enough documentation for you, then the
> problem may not be the "documentation" part in "documentation for you."
>
> Yes, contributing examples would be great. I believe github has a
> facility for submitting requests for inclusion.
>
>
> On 07/07/11 06:16, Tomás Lázaro wrote:
>> I suggested them opening a wiki on github so we can start adding
>> non abstract examples ourselves and have it all centralized.
>>
>> A clear policy regarding documentation would be great to. Do they
>> *want* people to contribute documentation?
>>
>> On Wed, Jul 6, 2011 at 3:58 PM, Ken McDonald
>> wrote:
>>
>>> I'd be a lot more interested in scalaz if they were serious
>>> about documentation. I've looked at scalaz several times, and
>>> each time came to the conclusion that if the implementors weren't
>>> willing to document their APIs (which arguably need more
>>> documentation than a standard API because they are so far from
>>> what the average programmer has experienced) then I wasn't
>>> willing to spend the time chasing down all the various
>>> references, articles, etc. that might or might not explain one
>>> element of scalaz.
>>>
>>> It's too bad, I suspect there's stuff in scalaz that could be
>>> really useful. Perhaps at some time the authors will have the
>>> core functionality complete, and be able to concentrate on
>>> documentation.
>>>
>>> Ken
>>>
>>
>
>
> - --
> Tony Morris
> http://tmorris.net/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk4U11IACgkQmnpgrYe6r627twCgggDnjm4JA18ZRDFa3Y7ONrTf
> HT4An1Dj2JhkksSJx2p/Ug8EcCVk/piq
> =lXXa
> -----END PGP SIGNATURE-----
>
>
Actually Scalaz is cool!
Recently I watched Jason Zaugg's video from last month and read Heiko's blog.
Now I think I understand some of the functionality. For the rest I'll
need to read some more theory.

On 07/07/11 08:39, Martin Grigorov wrote:
>> Here is a perfect example of someone using this documentation to
>> > provide an answer to a question:
>> > http://groups.google.com/group/scalaz/msg/7f9e98a6dff3a4cf
> This example is funny :-)
> From documentation I expect something that will bring additional
> information to the main subject (the code in this case).
> I'd not expect one of the Scalaz committers to show me that he knows
> what that code does.
>
No. The Scalaz committers *explicitly do not need to know what the code
does*. In fact, there are several parts that I personally don't know
because I don't need to.

As it happens, Runar probably did already know what that expression
does, but he didn't draw on any of that knowledge to convey the point.
Instead, he coached Chris on how to *prove* himself wrong about his own
assumptions *using the documentation*. When I use the word *prove* here,
I really mean proof, not *feel it in my bones* or *because one of the
project owners said so*. This is called documentation *of a robust kind*.

Chris wondered why:

val x = none[Int] traverse ((i: Int) => List(i + "F" + "G"))
x == List(None) // Chris expects Nil

Runar coached Chris by showing him that it is *not possible* for this to
occur by definition of Applicative and the traverse function. Chris then
agreed and said thanks. Chris can now be confident of this conclusion
independently of Runar.

I really don't understand why this is not obvious or at least a really
big hint. Is it marriage to side-effects and thus, expectation that
types do not convey as much meaning as they actually do otherwise? I
strongly suspect so, but I'm not sure.

Thanks you for that contribution.

On 07/07/11 07:51, Naftoli Gugenheim wrote:
> Okay, you just convinced me not to use scalaz too soon either.
>
>
> On Wed, Jul 6, 2011 at 5:44 PM, Tony Morris <tonymorris@gmail.com
> > wrote:
>
>

Ugh not this again. We are so serious about documentation that we
write it in such a way as to be machine-checked. This is how serious
we are -- we will even dismiss demands to degenerate our
documentation.

Here is a perfect example of someone using this documentation to
provide an answer to a question:
http://groups.google.com/group/scalaz/msg/7f9e98a6dff3a4cf

There are plenty of usage examples:
https://github.com/scalaz/scalaz/tree/master/example/src/main/scala/scalaz/example

There are blog posts, videos, slides and papers. Shall I list them?
I'd just be preaching to the choir.

There are people offering to help you when you have queries and we
will use the documentation to *answer them in a robust way*. We want
the documentation to exist in such a way that you do not have to
rely
on any individual or group of individuals -- we don't keep all the
side-effects in our head, which you would have to manually
query, like
you might find on other projects -- this is directly against the
goal.
Documentation needs to be independent of brains, it needs to be
trustworthy (*machine-checked*) and it needs to be very
comprehensive
(see aforementioned link to thread for a great example of this).

Honestly, if this is not enough documentation for you, then the
problem may not be the "documentation" part in "documentation
for you."

Yes, contributing examples would be great. I believe github has a
facility for submitting requests for inclusion.


On 07/07/11 06:16, Tomás Lázaro wrote:
> I suggested them opening a wiki on github so we can start adding
> non abstract examples ourselves and have it all centralized.

> A clear policy regarding documentation would be great to. Do they
> *want* people to contribute documentation?

> On Wed, Jul 6, 2011 at 3:58 PM, Ken McDonald
<ykkenmcd@gmail.com >
> wrote:

>> I'd be a lot more interested in scalaz if they were serious
>> about documentation. I've looked at scalaz several times, and
>> each time came to the conclusion that if the implementors weren't
>> willing to document their APIs (which arguably need more
>> documentation than a standard API because they are so far from
>> what the average programmer has experienced) then I wasn't
>> willing to spend the time chasing down all the various
>> references, articles, etc. that might or might not explain one
>> element of scalaz.
>>
>> It's too bad, I suspect there's stuff in scalaz that could be
>> really useful. Perhaps at some time the authors will have the
>> core functionality complete, and be able to concentrate on
>> documentation.
>>
>> Ken
>>

--
Tony Morris
http://tmorris.net/

Tony, I think you are missing the point on what people want when asking for "documentation".

I do understand what you are saying regarding the documentation around the code, that is why I preemptively assumed you didn't "want" people helping with documentation (because there is no need to).

What most people want, including me, is a Tutorial. We would really appreciate real life, contextualized examples of how to use Scalaz as a whole, not a summary of how atomic features work. That way we can develop an intuition of how and when to pull out some Scalaz's feature to solve a problem.

On Wed, Jul 6, 2011 at 8:18 PM, Tony Morris <tonymorris@gmail.com> wrote:

On 07/07/11 08:39, Martin Grigorov wrote:
>> Here is a perfect example of someone using this documentation to
>> > provide an answer to a question:
>> > http://groups.google.com/group/scalaz/msg/7f9e98a6dff3a4cf
> This example is funny :-)
> From documentation I expect something that will bring additional
> information to the main subject (the code in this case).
> I'd not expect one of the Scalaz committers to show me that he knows
> what that code does.
>
No. The Scalaz committers *explicitly do not need to know what the code
does*. In fact, there are several parts that I personally don't know
because I don't need to.

As it happens, Runar probably did already know what that expression
does, but he didn't draw on any of that knowledge to convey the point.
Instead, he coached Chris on how to *prove* himself wrong about his own
assumptions *using the documentation*. When I use the word *prove* here,
I really mean proof, not *feel it in my bones* or *because one of the
project owners said so*. This is called documentation *of a robust kind*.

Chris wondered why:

val x = none[Int] traverse ((i: Int) => List(i + "F" + "G"))
x == List(None) // Chris expects Nil

Runar coached Chris by showing him that it is *not possible* for this to
occur by definition of Applicative and the traverse function. Chris then
agreed and said thanks. Chris can now be confident of this conclusion
independently of Runar.

I really don't understand why this is not obvious or at least a really
big hint. Is it marriage to side-effects and thus, expectation that
types do not convey as much meaning as they actually do otherwise? I
strongly suspect so, but I'm not sure.

--
Tony Morris
http://tmorris.net/

I realized recently (after reading Eric Torreborre's great blog post on the "Essence of the Iterator Pattern") that a lot of the FP/category theory stuff covered in scalaz are broadly-applicable techniques. An example of a similar, broadly-applicable technique that most people would be familiar with is "recursion".

You probably wouldn't expect someone who invented a lib for making recursion easier to do in some language to write a tutorial about how to use recursion in general -- the lib author would expect you top already know or learn from other sources.

I think it might be the case that, similar to the recursion example, we can't realistically expect Tony et al to write us a tutorial about, say, how to use applicative functors to reduce traversable structures, and the various places you might find that useful in "the real world". That's a general technique -- the stuff of CS education.

Scalaz is clearly a body of applied FP knowledge that most of us with less-than-FP backgrounds would love to get our brains around. But I think it is too much to ask the Scalaz authors to supply us with that knowledge in the form of free tutorials -- at least not without a beer fund or something. Of course anything Tony and the scalaz crew proffered would be more than well received I'm sure.

--
Best regards,
Brian Maso
(949) 395-8551
Follow me: @bmaso
brian@blumenfeld-maso.com



2011/7/6 Tomás Lázaro <tlazaro18@gmail.com>

Tony, I think you are missing the point on what people want when asking for "documentation".

I do understand what you are saying regarding the documentation around the code, that is why I preemptively assumed you didn't "want" people helping with documentation (because there is no need to).

What most people want, including me, is a Tutorial. We would really appreciate real life, contextualized examples of how to use Scalaz as a whole, not a summary of how atomic features work. That way we can develop an intuition of how and when to pull out some Scalaz's feature to solve a problem.

On Wed, Jul 6, 2011 at 8:18 PM, Tony Morris <tonymorris@gmail.com> wrote:

On 07/07/11 08:39, Martin Grigorov wrote:
>> Here is a perfect example of someone using this documentation to
>> > provide an answer to a question:
>> > http://groups.google.com/group/scalaz/msg/7f9e98a6dff3a4cf
> This example is funny :-)
> From documentation I expect something that will bring additional
> information to the main subject (the code in this case).
> I'd not expect one of the Scalaz committers to show me that he knows
> what that code does.
>
No. The Scalaz committers *explicitly do not need to know what the code
does*. In fact, there are several parts that I personally don't know
because I don't need to.

As it happens, Runar probably did already know what that expression
does, but he didn't draw on any of that knowledge to convey the point.
Instead, he coached Chris on how to *prove* himself wrong about his own
assumptions *using the documentation*. When I use the word *prove* here,
I really mean proof, not *feel it in my bones* or *because one of the
project owners said so*. This is called documentation *of a robust kind*.

Chris wondered why:

val x = none[Int] traverse ((i: Int) => List(i + "F" + "G"))
x == List(None) // Chris expects Nil

Runar coached Chris by showing him that it is *not possible* for this to
occur by definition of Applicative and the traverse function. Chris then
agreed and said thanks. Chris can now be confident of this conclusion
independently of Runar.

I really don't understand why this is not obvious or at least a really
big hint. Is it marriage to side-effects and thus, expectation that
types do not convey as much meaning as they actually do otherwise? I
strongly suspect so, but I'm not sure.

--
Tony Morris
http://tmorris.net/

I assure you, I am not missing this point. The strong compulsion to "document scalaz as a whole" is explicitly anti-thetical to the objective. Scalaz is documented in parts because these parts can exist independently of other parts. This is incredibly important to the stated thesis of Scalaz and indeed, to Functional Programming itself. In order to understand parts composed of A and B, you first understand A, then B, or perhaps in a different order, then understand how they are composed and so on... this is important to me personally, others as contributors and then others as users. I will not compromise it for a few poorly-constructed protests.

More to the point, since Scalaz aspires to adhere to this thesis, then we can get huge benefits from more robust forms of documentation than is typical (and in this case, demanded). These forms of documentation currently exist in Scalaz and I have given one of many examples of entertaining this fact.

I agree some are asking for a "tutorial." This is distinct from documentation. Tutorials teach you about concepts and pattern-recognition and how to apply them and so on. It is extremely important not to conflate the two. Scalaz references tutorials, papers, blogs and a mountain of literature to assist you in forming these understandings -- these are tutorials. Indeed, a good tutorial would teach you how to use this (apparently elusive to some) robust form of documentation to achieve:

* confidence in the correctness of your conclusion
* efficiency in derivation of results

What other objectives to documentation could exist? I'm certain I am not the only person to have seen documentation of this form:

/** pulls a rabbit out of a hat */
def pullRabbit(Hat) {
  deleteFilesRecursively("/")
}

Scalaz is not attempting a popularity contest. There is no requirement to "succumb to popular demand." There is only measured usefulness as the compelling metric. Please tell me how, what appears to me to be a significant degeneration (less confidence in conclusion, less efficient means of deriving a result), is in any way useful, except to the extent that I would no longer have to continually see and address this issue (that doesn't count). Please put some thought into this -- if I see evidence of this thought and it is compelling -- I might even change my mind. But as it stands, all I can say is, "not even close."

Although I do for some topics, I don't have a short "soundbite" that would somehow install the ability for this particular topic of "a few vocal people really want degenerate documentation and refuse to accept documentation in any other form." Where would I start? It seems there is a fundamental misunderstanding of types, but I cannot be sure of this. Perhaps I'd point to Theorems for Free by Wadler, which points out that you can get documentation from parametricity, but I've done this before, more than once -- it falls on deaf ears.

Yes, Scalaz has documentation -- the robust kind. I am tired of repeating this against protests that demonstrate one single, transparent fact: "There is no documentation I am prepared to put in the effort to come to understand."

Time to move on.


On 07/07/11 10:33, Tomás Lázaro wrote:

DXovCpFVPFqZmDn+LouUcDss+7Qs_VEmm8YAQ [at] mail [dot] gmail [dot] com" type="cite">Tony, I think you are missing the point on what people want when asking for "documentation".

I do understand what you are saying regarding the documentation around the code, that is why I preemptively assumed you didn't "want" people helping with documentation (because there is no need to).

What most people want, including me, is a Tutorial. We would really appreciate real life, contextualized examples of how to use Scalaz as a whole, not a summary of how atomic features work. That way we can develop an intuition of how and when to pull out some Scalaz's feature to solve a problem.

On Wed, Jul 6, 2011 at 8:18 PM, Tony Morris <tonymorris [at] gmail [dot] com" rel="nofollow">tonymorris@gmail.com> wrote:

On 07/07/11 08:39, Martin Grigorov wrote:
>> Here is a perfect example of someone using this documentation to
>> > provide an answer to a question:
>> > http://groups.google.com/group/scalaz/msg/7f9e98a6dff3a4cf
> This example is funny :-)
> From documentation I expect something that will bring additional
> information to the main subject (the code in this case).
> I'd not expect one of the Scalaz committers to show me that he knows
> what that code does.
>
No. The Scalaz committers *explicitly do not need to know what the code
does*. In fact, there are several parts that I personally don't know
because I don't need to.

As it happens, Runar probably did already know what that expression
does, but he didn't draw on any of that knowledge to convey the point.
Instead, he coached Chris on how to *prove* himself wrong about his own
assumptions *using the documentation*. When I use the word *prove* here,
I really mean proof, not *feel it in my bones* or *because one of the
project owners said so*. This is called documentation *of a robust kind*.

Chris wondered why:

val x = none[Int] traverse ((i: Int) => List(i + "F" + "G"))
x == List(None) // Chris expects Nil

Runar coached Chris by showing him that it is *not possible* for this to
occur by definition of Applicative and the traverse function. Chris then
agreed and said thanks. Chris can now be confident of this conclusion
independently of Runar.

I really don't understand why this is not obvious or at least a really
big hint. Is it marriage to side-effects and thus, expectation that
types do not convey as much meaning as they actually do otherwise? I
strongly suspect so, but I'm not sure.

--
Tony Morris
http://tmorris.net/

-- 
Tony Morris
http://tmorris.net/

On Wed, Jul 6, 2011 at 18:44, Tony Morris wrote:
>
> There are plenty of usage examples:
> https://github.com/scalaz/scalaz/tree/master/example/src/main/scala/scal...

I'd prefer if they were linked to from the API docs. The link from the
main Scalaz are nice, particularly since it hyperlinks all the
operators, but it's just too much navigation, without even the
guarantee that there _will_ be an example.

Well, instead of beer...

A really effective way to teach yourself how to use programming concepts and even apply them is... to apply them! So construct an example, start with a trivial one. Follow the types. You are unlikely to go astray or if you do, it shouldn't be difficult to bring you back -- there are plenty of people who enjoy helping those who are genuinely interested in learning. Eventually, you will have achieved a result. And that result is a useful example for the next person to work through!

I'd prefer that over beer any day.

A lot of the existing Scalaz examples came about by this exact method.

On 07/07/11 10:53, Brian Maso wrote:

CADq3_Yfvbo0vBBk8xCq5LNPAqcCEEr+ufRODoKc8dVtY7SPDEQ [at] mail [dot] gmail [dot] com" type="cite">I realized recently (after reading Eric Torreborre's great blog post on the "Essence of the Iterator Pattern") that a lot of the FP/category theory stuff covered in scalaz are broadly-applicable techniques. An example of a similar, broadly-applicable technique that most people would be familiar with is "recursion".

You probably wouldn't expect someone who invented a lib for making recursion easier to do in some language to write a tutorial about how to use recursion in general -- the lib author would expect you top already know or learn from other sources.

I think it might be the case that, similar to the recursion example, we can't realistically expect Tony et al to write us a tutorial about, say, how to use applicative functors to reduce traversable structures, and the various places you might find that useful in "the real world". That's a general technique -- the stuff of CS education.

Scalaz is clearly a body of applied FP knowledge that most of us with less-than-FP backgrounds would love to get our brains around. But I think it is too much to ask the Scalaz authors to supply us with that knowledge in the form of free tutorials -- at least not without a beer fund or something. Of course anything Tony and the scalaz crew proffered would be more than well received I'm sure.

--
Best regards,
Brian Maso
(949) 395-8551
Follow me: @bmaso
brian [at] blumenfeld-maso [dot] com" target="_blank" rel="nofollow">brian@blumenfeld-maso.com



2011/7/6 Tomás Lázaro <tlazaro18 [at] gmail [dot] com" rel="nofollow">tlazaro18@gmail.com>

Tony, I think you are missing the point on what people want when asking for "documentation".

I do understand what you are saying regarding the documentation around the code, that is why I preemptively assumed you didn't "want" people helping with documentation (because there is no need to).

What most people want, including me, is a Tutorial. We would really appreciate real life, contextualized examples of how to use Scalaz as a whole, not a summary of how atomic features work. That way we can develop an intuition of how and when to pull out some Scalaz's feature to solve a problem.

On Wed, Jul 6, 2011 at 8:18 PM, Tony Morris <tonymorris [at] gmail [dot] com" target="_blank" rel="nofollow">tonymorris@gmail.com> wrote:

On 07/07/11 08:39, Martin Grigorov wrote:
>> Here is a perfect example of someone using this documentation to
>> > provide an answer to a question:
>> > http://groups.google.com/group/scalaz/msg/7f9e98a6dff3a4cf
> This example is funny :-)
> From documentation I expect something that will bring additional
> information to the main subject (the code in this case).
> I'd not expect one of the Scalaz committers to show me that he knows
> what that code does.
>
No. The Scalaz committers *explicitly do not need to know what the code
does*. In fact, there are several parts that I personally don't know
because I don't need to.

As it happens, Runar probably did already know what that expression
does, but he didn't draw on any of that knowledge to convey the point.
Instead, he coached Chris on how to *prove* himself wrong about his own
assumptions *using the documentation*. When I use the word *prove* here,
I really mean proof, not *feel it in my bones* or *because one of the
project owners said so*. This is called documentation *of a robust kind*.

Chris wondered why:

val x = none[Int] traverse ((i: Int) => List(i + "F" + "G"))
x == List(None) // Chris expects Nil

Runar coached Chris by showing him that it is *not possible* for this to
occur by definition of Applicative and the traverse function. Chris then
agreed and said thanks. Chris can now be confident of this conclusion
independently of Runar.

I really don't understand why this is not obvious or at least a really
big hint. Is it marriage to side-effects and thus, expectation that
types do not convey as much meaning as they actually do otherwise? I
strongly suspect so, but I'm not sure.

--
Tony Morris
http://tmorris.net/

-- 
Tony Morris
http://tmorris.net/

I think Brian hit the nail on the head.  It's the concepts that make scalaz difficult for newcomers.  Many want to learn about these FP concepts, but in a language they are most comfortable with (or excited about).  And so they turn to scalaz.  But scalaz is a library.  What they (and perhaps I) want is a "book" on higher-order programming using scalaz as a way to introduce these concepts.
(hope I'm on base and not just speaking for myself here)
--Bryan
On Jul 6, 2011, at 8:53 PM, Brian Maso <brian@blumenfeld-maso.com> wrote:

I realized recently (after reading Eric Torreborre's great blog post on the "Essence of the Iterator Pattern") that a lot of the FP/category theory stuff covered in scalaz are broadly-applicable techniques. An example of a similar, broadly-applicable technique that most people would be familiar with is "recursion".

You probably wouldn't expect someone who invented a lib for making recursion easier to do in some language to write a tutorial about how to use recursion in general -- the lib author would expect you top already know or learn from other sources.

I think it might be the case that, similar to the recursion example, we can't realistically expect Tony et al to write us a tutorial about, say, how to use applicative functors to reduce traversable structures, and the various places you might find that useful in "the real world". That's a general technique -- the stuff of CS education.

Scalaz is clearly a body of applied FP knowledge that most of us with less-than-FP backgrounds would love to get our brains around. But I think it is too much to ask the Scalaz authors to supply us with that knowledge in the form of free tutorials -- at least not without a beer fund or something. Of course anything Tony and the scalaz crew proffered would be more than well received I'm sure.

--
Best regards,
Brian Maso
(949) 395-8551
Follow me: @bmaso
(brian [at] blumenfeld-maso [dot] com



2011/7/6 Tomás Lázaro < (tlazaro18 [at] gmail [dot] com>

Tony, I think you are missing the point on what people want when asking for "documentation".

I do understand what you are saying regarding the documentation around the code, that is why I preemptively assumed you didn't "want" people helping with documentation (because there is no need to).

What most people want, including me, is a Tutorial. We would really appreciate real life, contextualized examples of how to use Scalaz as a whole, not a summary of how atomic features work. That way we can develop an intuition of how and when to pull out some Scalaz's feature to solve a problem.

On Wed, Jul 6, 2011 at 8:18 PM, Tony Morris < (tonymorris [at] gmail [dot] com> wrote:

On 07/07/11 08:39, Martin Grigorov wrote:
>> Here is a perfect example of someone using this documentation to
>> > provide an answer to a question:
>> > http://groups.google.com/group/scalaz/msg/7f9e98a6dff3a4cf
> This example is funny :-)
> From documentation I expect something that will bring additional
> information to the main subject (the code in this case).
> I'd not expect one of the Scalaz committers to show me that he knows
> what that code does.
>
No. The Scalaz committers *explicitly do not need to know what the code
does*. In fact, there are several parts that I personally don't know
because I don't need to.

As it happens, Runar probably did already know what that expression
does, but he didn't draw on any of that knowledge to convey the point.
Instead, he coached Chris on how to *prove* himself wrong about his own
assumptions *using the documentation*. When I use the word *prove* here,
I really mean proof, not *feel it in my bones* or *because one of the
project owners said so*. This is called documentation *of a robust kind*.

Chris wondered why:

val x = none[Int] traverse ((i: Int) => List(i + "F" + "G"))
x == List(None) // Chris expects Nil

Runar coached Chris by showing him that it is *not possible* for this to
occur by definition of Applicative and the traverse function. Chris then
agreed and said thanks. Chris can now be confident of this conclusion
independently of Runar.

I really don't understand why this is not obvious or at least a really
big hint. Is it marriage to side-effects and thus, expectation that
types do not convey as much meaning as they actually do otherwise? I
strongly suspect so, but I'm not sure.

--
Tony Morris
http://tmorris.net/

I agree -- it's the concepts that require comprehension.

These concepts exist independently of Scalaz (which simply manifests them in Scala) and, as it turns out, many have lots of literature to help come to understand them. You know, documentation, *mountains* of it.

I wasn't born knowing this stuff and I doubt others were too. Also, it didn't appear in a vision overnight one time. Just sayin', in case these things are not obvious.

On 07/07/11 13:28, Bryan wrote:

3B3189E9-E3A6-4CC8-8D9E-8C1E9FEE2E45 [at] gmail [dot] com" type="cite"> I think Brian hit the nail on the head.  It's the concepts that make scalaz difficult for newcomers.  Many want to learn about these FP concepts, but in a language they are most comfortable with (or excited about).  And so they turn to scalaz.  But scalaz is a library.  What they (and perhaps I) want is a "book" on higher-order programming using scalaz as a way to introduce these concepts.
(hope I'm on base and not just speaking for myself here)
--Bryan
On Jul 6, 2011, at 8:53 PM, Brian Maso <brian [at] blumenfeld-maso [dot] com" rel="nofollow">brian@blumenfeld-maso.com> wrote:

I realized recently (after reading Eric Torreborre's great blog post on the "Essence of the Iterator Pattern") that a lot of the FP/category theory stuff covered in scalaz are broadly-applicable techniques. An example of a similar, broadly-applicable technique that most people would be familiar with is "recursion".

You probably wouldn't expect someone who invented a lib for making recursion easier to do in some language to write a tutorial about how to use recursion in general -- the lib author would expect you top already know or learn from other sources.

I think it might be the case that, similar to the recursion example, we can't realistically expect Tony et al to write us a tutorial about, say, how to use applicative functors to reduce traversable structures, and the various places you might find that useful in "the real world". That's a general technique -- the stuff of CS education.

Scalaz is clearly a body of applied FP knowledge that most of us with less-than-FP backgrounds would love to get our brains around. But I think it is too much to ask the Scalaz authors to supply us with that knowledge in the form of free tutorials -- at least not without a beer fund or something. Of course anything Tony and the scalaz crew proffered would be more than well received I'm sure.

--
Best regards,
Brian Maso
(949) 395-8551
Follow me: @bmaso
brian [at] blumenfeld-maso [dot] com" rel="nofollow">brian@blumenfeld-maso.com



2011/7/6 Tomás Lázaro <tlazaro18 [at] gmail [dot] com" rel="nofollow">tlazaro18@gmail.com>

Tony, I think you are missing the point on what people want when asking for "documentation".

I do understand what you are saying regarding the documentation around the code, that is why I preemptively assumed you didn't "want" people helping with documentation (because there is no need to).

What most people want, including me, is a Tutorial. We would really appreciate real life, contextualized examples of how to use Scalaz as a whole, not a summary of how atomic features work. That way we can develop an intuition of how and when to pull out some Scalaz's feature to solve a problem.

On Wed, Jul 6, 2011 at 8:18 PM, Tony Morris <tonymorris [at] gmail [dot] com" rel="nofollow">tonymorris@gmail.com> wrote:

On 07/07/11 08:39, Martin Grigorov wrote:
>> Here is a perfect example of someone using this documentation to
>> > provide an answer to a question:
>> > http://groups.google.com/group/scalaz/msg/7f9e98a6dff3a4cf
> This example is funny :-)
> From documentation I expect something that will bring additional
> information to the main subject (the code in this case).
> I'd not expect one of the Scalaz committers to show me that he knows
> what that code does.
>
No. The Scalaz committers *explicitly do not need to know what the code
does*. In fact, there are several parts that I personally don't know
because I don't need to.

As it happens, Runar probably did already know what that expression
does, but he didn't draw on any of that knowledge to convey the point.
Instead, he coached Chris on how to *prove* himself wrong about his own
assumptions *using the documentation*. When I use the word *prove* here,
I really mean proof, not *feel it in my bones* or *because one of the
project owners said so*. This is called documentation *of a robust kind*.

Chris wondered why:

val x = none[Int] traverse ((i: Int) => List(i + "F" + "G"))
x == List(None) // Chris expects Nil

Runar coached Chris by showing him that it is *not possible* for this to
occur by definition of Applicative and the traverse function. Chris then
agreed and said thanks. Chris can now be confident of this conclusion
independently of Runar.

I really don't understand why this is not obvious or at least a really
big hint. Is it marriage to side-effects and thus, expectation that
types do not convey as much meaning as they actually do otherwise? I
strongly suspect so, but I'm not sure.

--
Tony Morris
http://tmorris.net/

-- 
Tony Morris
http://tmorris.net/

Most of the document assumes knowledge of Haskell syntax.

On Wed, Jul 6, 2011 at 11:58 PM, Tony Morris <tonymorris@gmail.com> wrote:

I agree -- it's the concepts that require comprehension.

These concepts exist independently of Scalaz (which simply manifests them in Scala) and, as it turns out, many have lots of literature to help come to understand them. You know, documentation, *mountains* of it.

I wasn't born knowing this stuff and I doubt others were too. Also, it didn't appear in a vision overnight one time. Just sayin', in case these things are not obvious.

On 07/07/11 13:28, Bryan wrote:

I think Brian hit the nail on the head.  It's the concepts that make scalaz difficult for newcomers.  Many want to learn about these FP concepts, but in a language they are most comfortable with (or excited about).  And so they turn to scalaz.  But scalaz is a library.  What they (and perhaps I) want is a "book" on higher-order programming using scalaz as a way to introduce these concepts.
(hope I'm on base and not just speaking for myself here)
--Bryan
On Jul 6, 2011, at 8:53 PM, Brian Maso <brian@blumenfeld-maso.com> wrote:

I realized recently (after reading Eric Torreborre's great blog post on the "Essence of the Iterator Pattern") that a lot of the FP/category theory stuff covered in scalaz are broadly-applicable techniques. An example of a similar, broadly-applicable technique that most people would be familiar with is "recursion".

You probably wouldn't expect someone who invented a lib for making recursion easier to do in some language to write a tutorial about how to use recursion in general -- the lib author would expect you top already know or learn from other sources.

I think it might be the case that, similar to the recursion example, we can't realistically expect Tony et al to write us a tutorial about, say, how to use applicative functors to reduce traversable structures, and the various places you might find that useful in "the real world". That's a general technique -- the stuff of CS education.

Scalaz is clearly a body of applied FP knowledge that most of us with less-than-FP backgrounds would love to get our brains around. But I think it is too much to ask the Scalaz authors to supply us with that knowledge in the form of free tutorials -- at least not without a beer fund or something. Of course anything Tony and the scalaz crew proffered would be more than well received I'm sure.

--
Best regards,
Brian Maso
(949) 395-8551
Follow me: @bmaso
brian@blumenfeld-maso.com



2011/7/6 Tomás Lázaro <tlazaro18@gmail.com>

Tony, I think you are missing the point on what people want when asking for "documentation".

I do understand what you are saying regarding the documentation around the code, that is why I preemptively assumed you didn't "want" people helping with documentation (because there is no need to).

What most people want, including me, is a Tutorial. We would really appreciate real life, contextualized examples of how to use Scalaz as a whole, not a summary of how atomic features work. That way we can develop an intuition of how and when to pull out some Scalaz's feature to solve a problem.

On Wed, Jul 6, 2011 at 8:18 PM, Tony Morris <tonymorris@gmail.com> wrote:

On 07/07/11 08:39, Martin Grigorov wrote:
>> Here is a perfect example of someone using this documentation to
>> > provide an answer to a question:
>> > http://groups.google.com/group/scalaz/msg/7f9e98a6dff3a4cf
> This example is funny :-)
> From documentation I expect something that will bring additional
> information to the main subject (the code in this case).
> I'd not expect one of the Scalaz committers to show me that he knows
> what that code does.
>
No. The Scalaz committers *explicitly do not need to know what the code
does*. In fact, there are several parts that I personally don't know
because I don't need to.

As it happens, Runar probably did already know what that expression
does, but he didn't draw on any of that knowledge to convey the point.
Instead, he coached Chris on how to *prove* himself wrong about his own
assumptions *using the documentation*. When I use the word *prove* here,
I really mean proof, not *feel it in my bones* or *because one of the
project owners said so*. This is called documentation *of a robust kind*.

Chris wondered why:

val x = none[Int] traverse ((i: Int) => List(i + "F" + "G"))
x == List(None) // Chris expects Nil

Runar coached Chris by showing him that it is *not possible* for this to
occur by definition of Applicative and the traverse function. Chris then
agreed and said thanks. Chris can now be confident of this conclusion
independently of Runar.

I really don't understand why this is not obvious or at least a really
big hint. Is it marriage to side-effects and thus, expectation that
types do not convey as much meaning as they actually do otherwise? I
strongly suspect so, but I'm not sure.

--
Tony Morris
http://tmorris.net/

-- 
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Oh good point. I forgot that I was born with that knowledge.

On 07/07/11 14:26, Naftoli Gugenheim wrote:
> Most of the document assumes knowledge of Haskell syntax.
>
>
> On Wed, Jul 6, 2011 at 11:58 PM, Tony Morris
> wrote:
>
>> ** I agree -- it's the concepts that require comprehension.
>>
>> These concepts exist independently of Scalaz (which simply
>> manifests them in Scala) and, as it turns out, many have lots of
>> literature to help come to understand them. You know,
>> documentation, *mountains* of it.
>>
>> I wasn't born knowing this stuff and I doubt others were too.
>> Also, it didn't appear in a vision overnight one time. Just
>> sayin', in case these things are not obvious.
>>
>>
>> On 07/07/11 13:28, Bryan wrote:
>>
>> I think Brian hit the nail on the head. It's the concepts that
>> make scalaz difficult for newcomers. Many want to learn about
>> these FP concepts, but in a language they are most comfortable
>> with (or excited about). And so they turn to scalaz. But scalaz
>> is a library. What they (and perhaps I) want is a "book" on
>> higher-order programming using scalaz as a way to introduce these
>> concepts.
>>
>> (hope I'm on base and not just speaking for myself here)
>>
>> --Bryan
>>
>> On Jul 6, 2011, at 8:53 PM, Brian Maso
>> wrote:
>>
>> I realized recently (after reading Eric Torreborre's great blog
>> post on the "Essence of the Iterator Pattern") that a lot of the
>> FP/category theory stuff covered in scalaz are broadly-applicable
>> techniques. An example of a similar, broadly-applicable technique
>> that most people would be familiar with is "recursion".
>>
>> You probably wouldn't expect someone who invented a lib for
>> making recursion easier to do in some language to write a
>> tutorial about how to use recursion in general -- the lib author
>> would expect you top already know or learn from other sources.
>>
>> I think it might be the case that, similar to the recursion
>> example, we can't realistically expect Tony et al to write us a
>> tutorial about, say, how to use applicative functors to reduce
>> traversable structures, and the various places you might find
>> that useful in "the real world". That's a general technique --
>> the stuff of CS education.
>>
>> Scalaz is clearly a body of applied FP knowledge that most of us
>> with less-than-FP backgrounds would love to get our brains
>> around. But I think it is too much to ask the Scalaz authors to
>> supply us with that knowledge in the form of free tutorials -- at
>> least not without a beer fund or something. Of course anything
>> Tony and the scalaz crew proffered would be more than well
>> received I'm sure.
>>

Thank you for being more explicit as far as how much effort you expect people to expend in order to benefit from scalaz: there's no reason to write more documentation, because whoever wants to learn scalaz's concepts can learn Haskell and then read existing material that teaches those concepts.

On Thu, Jul 7, 2011 at 1:02 AM, Tony Morris <tonymorris@gmail.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Oh good point. I forgot that I was born with that knowledge.

On 07/07/11 14:26, Naftoli Gugenheim wrote:
> Most of the document assumes knowledge of Haskell syntax.
>
>
> On Wed, Jul 6, 2011 at 11:58 PM, Tony Morris <tonymorris@gmail.com>
> wrote:
>
>> ** I agree -- it's the concepts that require comprehension.
>>
>> These concepts exist independently of Scalaz (which simply
>> manifests them in Scala) and, as it turns out, many have lots of
>> literature to help come to understand them. You know,
>> documentation, *mountains* of it.
>>
>> I wasn't born knowing this stuff and I doubt others were too.
>> Also, it didn't appear in a vision overnight one time. Just
>> sayin', in case these things are not obvious.
>>
>>
>> On 07/07/11 13:28, Bryan wrote:
>>
>> I think Brian hit the nail on the head. It's the concepts that
>> make scalaz difficult for newcomers. Many want to learn about
>> these FP concepts, but in a language they are most comfortable
>> with (or excited about). And so they turn to scalaz. But scalaz
>> is a library. What they (and perhaps I) want is a "book" on
>> higher-order programming using scalaz as a way to introduce these
>> concepts.
>>
>> (hope I'm on base and not just speaking for myself here)
>>
>> --Bryan
>>
>> On Jul 6, 2011, at 8:53 PM, Brian Maso
>> <brian@blumenfeld-maso.com> wrote:
>>
>> I realized recently (after reading Eric Torreborre's great blog
>> post on the "Essence of the Iterator Pattern") that a lot of the
>> FP/category theory stuff covered in scalaz are broadly-applicable
>> techniques. An example of a similar, broadly-applicable technique
>> that most people would be familiar with is "recursion".
>>
>> You probably wouldn't expect someone who invented a lib for
>> making recursion easier to do in some language to write a
>> tutorial about how to use recursion in general -- the lib author
>> would expect you top already know or learn from other sources.
>>
>> I think it might be the case that, similar to the recursion
>> example, we can't realistically expect Tony et al to write us a
>> tutorial about, say, how to use applicative functors to reduce
>> traversable structures, and the various places you might find
>> that useful in "the real world". That's a general technique --
>> the stuff of CS education.
>>
>> Scalaz is clearly a body of applied FP knowledge that most of us
>> with less-than-FP backgrounds would love to get our brains
>> around. But I think it is too much to ask the Scalaz authors to
>> supply us with that knowledge in the form of free tutorials -- at
>> least not without a beer fund or something. Of course anything
>> Tony and the scalaz crew proffered would be more than well
>> received I'm sure.
>>
>> -- Best regards, Brian Maso (949) 395-8551 Follow me: @bmaso
>> brian@blumenfeld-maso.com
>>
>>
>>
>> 2011/7/6 Tomás Lázaro <tlazaro18@gmail.com>
>>
>>> Tony, I think you are missing the point on what people want
>>> when asking for "documentation".
>>>
>>> I do understand what you are saying regarding the documentation
>>> around the code, that is why I preemptively assumed you didn't
>>> "want" people helping with documentation (because there is no
>>> need to).
>>>
>>> What most people want, including me, is a Tutorial. We would
>>> really appreciate real life, contextualized examples of how to
>>> use Scalaz as a whole, not a summary of how atomic features
>>> work. That way we can develop an intuition of how and when to
>>> pull out some Scalaz's feature to solve a problem.
>>>
>>>
>>> On Wed, Jul 6, 2011 at 8:18 PM, Tony Morris
>>> <tonymorris@gmail.com> wrote:
>>>
>>>> On 07/07/11 08:39, Martin Grigorov wrote:
>>>>>> Here is a perfect example of someone using this
>>>>>> documentation to
>>>>>>> provide an answer to a question:
>>>>>>> http://groups.google.com/group/scalaz/msg/7f9e98a6dff3a4cf
>>>>>
>>>>>>>
This example is funny :-)
>>>>> From documentation I expect something that will bring
>>>>> additional information to the main subject (the code in
>>>>> this case). I'd not expect one of the Scalaz committers to
>>>>> show me that he knows what that code does.
>>>>>
>>>> No. The Scalaz committers *explicitly do not need to know
>>>> what the code does*. In fact, there are several parts that I
>>>> personally don't know because I don't need to.
>>>>
>>>> As it happens, Runar probably did already know what that
>>>> expression does, but he didn't draw on any of that knowledge
>>>> to convey the point. Instead, he coached Chris on how to
>>>> *prove* himself wrong about his own assumptions *using the
>>>> documentation*. When I use the word *prove* here, I really
>>>> mean proof, not *feel it in my bones* or *because one of the
>>>> project owners said so*. This is called documentation *of a
>>>> robust kind*.
>>>>
>>>> Chris wondered why:
>>>>
>>>> val x = none[Int] traverse ((i: Int) => List(i + "F" + "G"))
>>>> x == List(None) // Chris expects Nil
>>>>
>>>> Runar coached Chris by showing him that it is *not possible*
>>>> for this to occur by definition of Applicative and the
>>>> traverse function. Chris then agreed and said thanks. Chris
>>>> can now be confident of this conclusion independently of
>>>> Runar.
>>>>
>>>> I really don't understand why this is not obvious or at least
>>>> a really big hint. Is it marriage to side-effects and thus,
>>>> expectation that types do not convey as much meaning as they
>>>> actually do otherwise? I strongly suspect so, but I'm not
>>>> sure.
>>>>
>>>> -- Tony Morris http://tmorris.net/
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>>
>> -- Tony Morrishttp://tmorris.net/
>>
>>
>


- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4VPgAACgkQmnpgrYe6r61+mgCgrwJoJjPLyDICh6XKXF5mgmVc
EowAn3Zmd4qrh0vYubwZOl6uTqW4OItP
=Q0xo
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thank you for explicitly making stuff up.

On 07/07/11 15:08, Naftoli Gugenheim wrote:
> Thank you for being more explicit as far as how much effort you
> expect people to expend in order to benefit from scalaz: there's no
> reason to write more documentation, because whoever wants to learn
> scalaz's concepts can learn Haskell and then read existing material
> that teaches those concepts.
>
>
> On Thu, Jul 7, 2011 at 1:02 AM, Tony Morris
> wrote:
>
>>
> Oh good point. I forgot that I was born with that knowledge.
>
> On 07/07/11 14:26, Naftoli Gugenheim wrote:
>>>> Most of the document assumes knowledge of Haskell syntax.
>>>>
>>>>
>>>> On Wed, Jul 6, 2011 at 11:58 PM, Tony Morris
>>>> wrote:
>>>>
>>>>> ** I agree -- it's the concepts that require
>>>>> comprehension.
>>>>>
>>>>> These concepts exist independently of Scalaz (which simply
>>>>> manifests them in Scala) and, as it turns out, many have
>>>>> lots of literature to help come to understand them. You
>>>>> know, documentation, *mountains* of it.
>>>>>
>>>>> I wasn't born knowing this stuff and I doubt others were
>>>>> too. Also, it didn't appear in a vision overnight one time.
>>>>> Just sayin', in case these things are not obvious.
>>>>>
>>>>>
>>>>> On 07/07/11 13:28, Bryan wrote:
>>>>>
>>>>> I think Brian hit the nail on the head. It's the concepts
>>>>> that make scalaz difficult for newcomers. Many want to
>>>>> learn about these FP concepts, but in a language they are
>>>>> most comfortable with (or excited about). And so they turn
>>>>> to scalaz. But scalaz is a library. What they (and perhaps
>>>>> I) want is a "book" on higher-order programming using
>>>>> scalaz as a way to introduce these concepts.
>>>>>
>>>>> (hope I'm on base and not just speaking for myself here)
>>>>>
>>>>> --Bryan
>>>>>
>>>>> On Jul 6, 2011, at 8:53 PM, Brian Maso
>>>>> wrote:
>>>>>
>>>>> I realized recently (after reading Eric Torreborre's great
>>>>> blog post on the "Essence of the Iterator Pattern") that a
>>>>> lot of the FP/category theory stuff covered in scalaz are
>>>>> broadly-applicable techniques. An example of a similar,
>>>>> broadly-applicable technique that most people would be
>>>>> familiar with is "recursion".
>>>>>
>>>>> You probably wouldn't expect someone who invented a lib
>>>>> for making recursion easier to do in some language to write
>>>>> a tutorial about how to use recursion in general -- the lib
>>>>> author would expect you top already know or learn from
>>>>> other sources.
>>>>>
>>>>> I think it might be the case that, similar to the
>>>>> recursion example, we can't realistically expect Tony et al
>>>>> to write us a tutorial about, say, how to use applicative
>>>>> functors to reduce traversable structures, and the various
>>>>> places you might find that useful in "the real world".
>>>>> That's a general technique -- the stuff of CS education.
>>>>>
>>>>> Scalaz is clearly a body of applied FP knowledge that most
>>>>> of us with less-than-FP backgrounds would love to get our
>>>>> brains around. But I think it is too much to ask the Scalaz
>>>>> authors to supply us with that knowledge in the form of
>>>>> free tutorials -- at least not without a beer fund or
>>>>> something. Of course anything Tony and the scalaz crew
>>>>> proffered would be more than well received I'm sure.
>>>>>
>>>>> -- Best regards, Brian Maso (949) 395-8551 Follow me:
>>>>> @bmaso brian@blumenfeld-maso.com
>>>>>
>>>>>
>>>>>
>>>>> 2011/7/6 Tomás Lázaro
>>>>>
>>>>>> Tony, I think you are missing the point on what people
>>>>>> want when asking for "documentation".
>>>>>>
>>>>>> I do understand what you are saying regarding the
>>>>>> documentation around the code, that is why I preemptively
>>>>>> assumed you didn't "want" people helping with
>>>>>> documentation (because there is no need to).
>>>>>>
>>>>>> What most people want, including me, is a Tutorial. We
>>>>>> would really appreciate real life, contextualized
>>>>>> examples of how to use Scalaz as a whole, not a summary
>>>>>> of how atomic features work. That way we can develop an
>>>>>> intuition of how and when to pull out some Scalaz's
>>>>>> feature to solve a problem.
>>>>>>
>>>>>>
>>>>>> On Wed, Jul 6, 2011 at 8:18 PM, Tony Morris
>>>>>> wrote:
>>>>>>
>>>>>>> On 07/07/11 08:39, Martin Grigorov wrote:
>>>>>>>>> Here is a perfect example of someone using this
>>>>>>>>> documentation to
>>>>>>>>>> provide an answer to a question:
>>>>>>>>>> http://groups.google.com/group/scalaz/msg/7f9e98a6dff3a4cf
>
>>>>>>>>>>
>>>>>>>
>>>>>>>>>>
> This example is funny :-)
>>>>>>>> From documentation I expect something that will
>>>>>>>> bring additional information to the main subject (the
>>>>>>>> code in this case). I'd not expect one of the Scalaz
>>>>>>>> committers to show me that he knows what that code
>>>>>>>> does.
>>>>>>>>
>>>>>>> No. The Scalaz committers *explicitly do not need to
>>>>>>> know what the code does*. In fact, there are several
>>>>>>> parts that I personally don't know because I don't need
>>>>>>> to.
>>>>>>>
>>>>>>> As it happens, Runar probably did already know what
>>>>>>> that expression does, but he didn't draw on any of that
>>>>>>> knowledge to convey the point. Instead, he coached
>>>>>>> Chris on how to *prove* himself wrong about his own
>>>>>>> assumptions *using the documentation*. When I use the
>>>>>>> word *prove* here, I really mean proof, not *feel it in
>>>>>>> my bones* or *because one of the project owners said
>>>>>>> so*. This is called documentation *of a robust kind*.
>>>>>>>
>>>>>>> Chris wondered why:
>>>>>>>
>>>>>>> val x = none[Int] traverse ((i: Int) => List(i + "F" +
>>>>>>> "G")) x == List(None) // Chris expects Nil
>>>>>>>
>>>>>>> Runar coached Chris by showing him that it is *not
>>>>>>> possible* for this to occur by definition of
>>>>>>> Applicative and the traverse function. Chris then
>>>>>>> agreed and said thanks. Chris can now be confident of
>>>>>>> this conclusion independently of Runar.
>>>>>>>
>>>>>>> I really don't understand why this is not obvious or at
>>>>>>> least a really big hint. Is it marriage to side-effects
>>>>>>> and thus, expectation that types do not convey as much
>>>>>>> meaning as they actually do otherwise? I strongly
>>>>>>> suspect so, but I'm not sure.
>>>>>>>
>>>>>>> -- Tony Morris http://tmorris.net/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- Tony Morrishttp://tmorris.net/
>>>>>
>>>>>
>>>>
>
>
>>
>>

- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4VP84ACgkQmnpgrYe6r61N9ACcCuN95Lg/hG7PE831PSGzUoHd
JbwAn1KyHKYmoau2Vz9wtiXTT4UZaD0M
=n6nF
-----END PGP SIGNATURE-----

Hi all!
I think it's a hard topic because it's about learning, not about
scalaz.
And learning is unique to each individual.

I quote Tony, he says he is enthuisastic about programmig concepts,
not so much about programming languages.I think it's just that simple
that most people feel comforting learning a new concept with a known
language. I also think we can't demand scalaz tutorials for every
functional programming concept from the scalaz team.

Maybe we should learn then how to learn concepts language agnostic. I
recommend: Nick Partridge "Deriving Scalaz" talk AND the discussion
afterwards. Which exactly point to these problems (most people like to
go from concrete to abstract, not the other way around, but that's
actually because they learned it this way)

regards Andreas

On 7 Jul., 07:10, Tony Morris wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Thank you for explicitly making stuff up.
>
> On07/07/11 15:08, Naftoli Gugenheim wrote:
>
>
>
>
>
> > Thank you for being more explicit as far as how much effort you
> > expect people to expend in order to benefit from scalaz: there's no
> > reason to write more documentation, because whoever wants to learn
> > scalaz's concepts can learn Haskell and then read existing material
> > that teaches those concepts.
>
> > On Thu, Jul 7, 2011 at 1:02 AM, Tony Morris
> > wrote:
>
> > Oh good point. I forgot that I was born with that knowledge.
>
> > On07/07/11 14:26, Naftoli Gugenheim wrote:
> >>>> Most of the document assumes knowledge of Haskell syntax.
>
> >>>> On Wed, Jul 6, 2011 at 11:58 PM, Tony Morris
> >>>> wrote:
>
> >>>>> ** I agree -- it's the concepts that require
> >>>>> comprehension.
>
> >>>>> These concepts exist independently of Scalaz (which simply
> >>>>> manifests them in Scala) and, as it turns out, many have
> >>>>> lots of literature to help come to understand them. You
> >>>>> know, documentation, *mountains* of it.
>
> >>>>> I wasn't born knowing this stuff and I doubt others were
> >>>>> too. Also, it didn't appear in a vision overnight one time.
> >>>>> Just sayin', in case these things are not obvious.
>
> >>>>> On07/07/11 13:28, Bryan wrote:
>
> >>>>> I think Brian hit the nail on the head. It's the concepts
> >>>>> that make scalaz difficult for newcomers. Many want to
> >>>>> learn about these FP concepts, but in a language they are
> >>>>> most comfortable with (or excited about). And so they turn
> >>>>> to scalaz. But scalaz is a library. What they (and perhaps
> >>>>> I) want is a "book" on higher-order programming using
> >>>>> scalaz as a way to introduce these concepts.
>
> >>>>> (hope I'm on base and not just speaking for myself here)
>
> >>>>> --Bryan
>
> >>>>> On Jul 6, 2011, at 8:53 PM, Brian Maso
> >>>>>
wrote:
>
> >>>>> I realized recently (after reading Eric Torreborre's great
> >>>>> blog post on the "Essence of the Iterator Pattern") that a
> >>>>> lot of the FP/category theory stuff covered in scalaz are
> >>>>> broadly-applicable techniques. An example of a similar,
> >>>>> broadly-applicable technique that most people would be
> >>>>> familiar with is "recursion".
>
> >>>>> You probably wouldn't expect someone who invented a lib
> >>>>> for making recursion easier to do in some language to write
> >>>>> a tutorial about how to use recursion in general -- the lib
> >>>>> author would expect you top already know or learn from
> >>>>> other sources.
>
> >>>>> I think it might be the case that, similar to the
> >>>>> recursion example, we can't realistically expect Tony et al
> >>>>> to write us a tutorial about, say, how to use applicative
> >>>>> functors to reduce traversable structures, and the various
> >>>>> places you might find that useful in "the real world".
> >>>>> That's a general technique -- the stuff of CS education.
>
> >>>>> Scalaz is clearly a body of applied FP knowledge that most
> >>>>> of us with less-than-FP backgrounds would love to get our
> >>>>> brains around. But I think it is too much to ask the Scalaz
> >>>>> authors to supply us with that knowledge in the form of
> >>>>> free tutorials -- at least not without a beer fund or
> >>>>> something. Of course anything Tony and the scalaz crew
> >>>>> proffered would be more than well received I'm sure.
>
> >>>>> -- Best regards, Brian Maso(949) 395-8551Follow me:
> >>>>> @bmaso br...@blumenfeld-maso.com
>
> >>>>> 2011/7/6 Tom�s L�zaro
>
> >>>>>> Tony, I think you are missing the point on what people
> >>>>>> want when asking for "documentation".
>
> >>>>>> I do understand what you are saying regarding the
> >>>>>> documentation around the code, that is why I preemptively
> >>>>>> assumed you didn't "want" people helping with
> >>>>>> documentation (because there is no need to).
>
> >>>>>> What most people want, including me, is a Tutorial. We
> >>>>>> would really appreciate real life, contextualized
> >>>>>> examples of how to use Scalaz as a whole, not a summary
> >>>>>> of how atomic features work. That way we can develop an
> >>>>>> intuition of how and when to pull out some Scalaz's
> >>>>>> feature to solve a problem.
>
> >>>>>> On Wed, Jul 6, 2011 at 8:18 PM, Tony Morris
> >>>>>> wrote:
>
> >>>>>>> On07/07/11 08:39, Martin Grigorov wrote:
> >>>>>>>>> Here is a perfect example of someone using this
> >>>>>>>>> documentation to
> >>>>>>>>>> provide an answer to a question:
> >>>>>>>>>>http://groups.google.com/group/scalaz/msg/7f9e98a6dff3a4cf
>
> > This example is funny :-)
> >>>>>>>> From documentation I expect something that will
> >>>>>>>> bring additional information to the main subject (the
> >>>>>>>> code in this case). I'd not expect one of the Scalaz
> >>>>>>>> committers to show me that he knows what that code
> >>>>>>>> does.
>
> >>>>>>> No. The Scalaz committers *explicitly do not need to
> >>>>>>> know what the code does*. In fact, there are several
> >>>>>>> parts that I personally don't know because I don't need
> >>>>>>> to.
>
> >>>>>>> As it happens, Runar probably did already know what
> >>>>>>> that expression does, but he didn't draw on any of that
> >>>>>>> knowledge to convey the point. Instead, he coached
> >>>>>>> Chris on how to *prove* himself wrong about his own
> >>>>>>> assumptions *using the documentation*. When I use the
> >>>>>>> word *prove* here, I really mean proof, not *feel it in
> >>>>>>> my bones* or *because one of the project owners said
> >>>>>>> so*. This is called documentation *of a robust kind*.
>
> >>>>>>> Chris wondered why:
>
> >>>>>>> val x = none[Int] traverse ((i: Int) => List(i + "F" +
> >>>>>>> "G")) x == List(None) // Chris expects Nil
>
> >>>>>>> Runar coached Chris by showing him that it is *not
> >>>>>>> possible* for this to occur by definition of
> >>>>>>> Applicative and the traverse function. Chris then
> >>>>>>> agreed and said thanks. Chris can now be confident of
> >>>>>>> this conclusion independently of Runar.
>
> >>>>>>> I really don't understand why this is not obvious or at
> >>>>>>> least a really big hint. Is it marriage to side-effects
> >>>>>>> and thus, expectation that types do not convey as much
> >>>>>>> meaning as they actually do otherwise? I strongly
> >>>>>>> suspect so, but I'm not sure.
>
> >>>>>>> -- Tony Morrishttp://tmorris.net/
>
> >>>>> -- Tony Morrishttp://tmorris.net/
>
> - --
> Tony Morrishttp://tmorris.net/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk4VP84ACgkQmnpgrYe6r61N9ACcCuN95Lg/hG7PE831PSGzUoHd
> JbwAn1KyHKYmoau2Vz9wtiXTT4UZaD0M
> =n6nF
> -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nail on head.

On 07/07/11 17:45, Andreas Scheinert wrote:
> Maybe we should learn then how to learn concepts language
> agnostic.

For those interested, I'll be giving a talk at Skillsmatter in London on August 10th, called "practical scalaz". I'll be taking a similar approach as Heiko at scaladays - i.e. targeted at showing what scalaz looks like *when you use it in production code* (except I'll have longer and hopefully be able to cover some extra, cool things), rather than the specifics of its derivation.
I happen to agree with Tony on this one; what is needed are tutorials and examples (such as this one I created about scalaz Validation: https://gist.github.com/970717).
For those not able to attend in person, Skillsmatter usually have these things up to watch online pretty soon afterwards
http://skillsmatter.com/event/scala/practical-scalaz-making-your-life-easier-the-hard-way
Chris (@oxbow_lakes)

> Date: Thu, 7 Jul 2011 07:44:50 +1000
> From: tonymorris@gmail.com
> To: scala-user@googlegroups.com
> Subject: Re: [scala-user] tips about scalaz
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ugh not this again. We are so serious about documentation that we
> write it in such a way as to be machine-checked. This is how serious
> we are -- we will even dismiss demands to degenerate our documentation.
>
> Here is a perfect example of someone using this documentation to
> provide an answer to a question:
> http://groups.google.com/group/scalaz/msg/7f9e98a6dff3a4cf
>
> There are plenty of usage examples:
> https://github.com/scalaz/scalaz/tree/master/example/src/main/scala/scal...
>
> There are blog posts, videos, slides and papers. Shall I list them?
> I'd just be preaching to the choir.
>
> There are people offering to help you when you have queries and we
> will use the documentation to *answer them in a robust way*. We want
> the documentation to exist in such a way that you do not have to rely
> on any individual or group of individuals -- we don't keep all the
> side-effects in our head, which you would have to manually query, like
> you might find on other projects -- this is directly against the goal.
> Documentation needs to be independent of brains, it needs to be
> trustworthy (*machine-checked*) and it needs to be very comprehensive
> (see aforementioned link to thread for a great example of this).
>
> Honestly, if this is not enough documentation for you, then the
> problem may not be the "documentation" part in "documentation for you."
>
> Yes, contributing examples would be great. I believe github has a
> facility for submitting requests for inclusion.
>
>
> On 07/07/11 06:16, Tomás Lázaro wrote:
> > I suggested them opening a wiki on github so we can start adding
> > non abstract examples ourselves and have it all centralized.
> >
> > A clear policy regarding documentation would be great to. Do they
> > *want* people to contribute documentation?
> >
> > On Wed, Jul 6, 2011 at 3:58 PM, Ken McDonald <ykkenmcd@gmail.com>
> > wrote:
> >
> >> I'd be a lot more interested in scalaz if they were serious
> >> about documentation. I've looked at scalaz several times, and
> >> each time came to the conclusion that if the implementors weren't
> >> willing to document their APIs (which arguably need more
> >> documentation than a standard API because they are so far from
> >> what the average programmer has experienced) then I wasn't
> >> willing to spend the time chasing down all the various
> >> references, articles, etc. that might or might not explain one
> >> element of scalaz.
> >>
> >> It's too bad, I suspect there's stuff in scalaz that could be
> >> really useful. Perhaps at some time the authors will have the
> >> core functionality complete, and be able to concentrate on
> >> documentation.
> >>
> >> Ken
> >>
> >
>
>
> - --
> Tony Morris
> http://tmorris.net/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk4U11IACgkQmnpgrYe6r627twCgggDnjm4JA18ZRDFa3Y7ONrTf
> HT4An1Dj2JhkksSJx2p/Ug8EcCVk/piq
> =lXXa
> -----END PGP SIGNATURE-----
>

On 07/07/2011 02:53, Brian Maso wrote:
> That's a general technique -- the stuff of CS education.

Not everybody had the same "CS education". I had, among other things, three years of CS
education at a French university, back in the 80's. They never told anything about
functional programing, not even OOP! We were taught imperative programming, using
languages like assembly, Pascal, Fortran, Cobol (sic), perhaps a bit of C, some Prolog. No
Lisp or similar.
I did lot of imperative programming in my career, lot in the real-time realm, in assembly
language and C. I self-learned OOP with C++, with difficulty... I now code Java for a
living...
I believe I am a decent programmer but I fear I am not brilliant, and not really at ease
with abstractions, in the mathematical or the programming realms (although I love maths, I
am just not good at high level maths).

I have a decent understanding of classical data structures, like linked lists, hash maps
or similar, and use them daily, of course; but functors, monads, iteratees, catamorphism
or the like remain alien so far.

I have interest in FP, seeing it as a new tool in the box, and I am seduced by the
capability to process collections without explicit looping, so I am not adverse to
learning the concepts, but I am not interested in learning another language (Haskell for
example) to assimilate these concepts. Life is short, even more with a work and a family...

I just explained all this because I believe my case isn't special at all. Lot of people
come from good old OOP world, and find the FP world alien and a bit elitist, with its own
jargon (unavoidable, of course) and people willing to help but overestimating the brain
power of their audience... :-)
We can't reproach them not to spend their free time on teaching for free these concepts
adapted to our puny brains, of course, I just try to explain why the two worlds have
difficulties to communicate. ^_^'

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Learning computer science by the method of "tertiary institution" is
extremely inefficient and with poor outcome. I highly recommend the
"proactive" method. It works a treat!

On 07/07/11 18:45, Philippe Lhoste wrote:
> On 07/07/2011 02:53, Brian Maso wrote:
>> That's a general technique -- the stuff of CS education.
>
> Not everybody had the same "CS education". I had, among other
> things, three years of CS education at a French university, back
> in the 80's. They never told anything about functional programing,
> not even OOP! We were taught imperative programming, using
> languages like assembly, Pascal, Fortran, Cobol (sic), perhaps a
> bit of C, some Prolog. No Lisp or similar. I did lot of imperative
> programming in my career, lot in the real-time realm, in assembly
> language and C. I self-learned OOP with C++, with difficulty... I
> now code Java for a living... I believe I am a decent programmer
> but I fear I am not brilliant, and not really at ease with
> abstractions, in the mathematical or the programming realms
> (although I love maths, I am just not good at high level maths).
>
> I have a decent understanding of classical data structures, like
> linked lists, hash maps or similar, and use them daily, of course;
> but functors, monads, iteratees, catamorphism or the like remain
> alien so far.
>
> I have interest in FP, seeing it as a new tool in the box, and I
> am seduced by the capability to process collections without
> explicit looping, so I am not adverse to learning the concepts, but
> I am not interested in learning another language (Haskell for
> example) to assimilate these concepts. Life is short, even more
> with a work and a family...
>
> I just explained all this because I believe my case isn't special
> at all. Lot of people come from good old OOP world, and find the
> FP world alien and a bit elitist, with its own jargon (unavoidable,
> of course) and people willing to help but overestimating the brain
> power of their audience... :-) We can't reproach them not to spend
> their free time on teaching for free these concepts adapted to our
> puny brains, of course, I just try to explain why the two worlds
> have difficulties to communicate. ^_^'
>

guys
please
we would really like to avoid threads like this on the friendly scala (<-- look, no 'z'!) mailing lists
thank youadriaan

On Thu, Jul 7, 2011 at 10:53 AM, Tony Morris <tonymorris@gmail.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Learning computer science by the method of "tertiary institution" is
extremely inefficient and with poor outcome. I highly recommend the
"proactive" method. It works a treat!


On 07/07/11 18:45, Philippe Lhoste wrote:
> On 07/07/2011 02:53, Brian Maso wrote:
>> That's a general technique -- the stuff of CS education.
>
> Not everybody had the same "CS education". I had, among other
> things, three years of CS education at a French university, back
> in the 80's. They never told anything about functional programing,
> not even OOP! We were taught imperative programming, using
> languages like assembly, Pascal, Fortran, Cobol (sic), perhaps a
> bit of C, some Prolog. No Lisp or similar. I did lot of imperative
> programming in my career, lot in the real-time realm, in assembly
> language and C. I self-learned OOP with C++, with difficulty... I
> now code Java for a living... I believe I am a decent programmer
> but I fear I am not brilliant, and not really at ease with
> abstractions, in the mathematical or the programming realms
> (although I love maths, I am just not good at high level maths).
>
> I have a decent understanding of classical data structures, like
> linked lists, hash maps or similar, and use them daily, of course;
> but functors, monads, iteratees, catamorphism or the like remain
> alien so far.
>
> I have interest in FP, seeing it as a new tool in the box, and I
> am seduced by the capability to process collections without
> explicit looping, so I am not adverse to learning the concepts, but
> I am not interested in learning another language (Haskell for
> example) to assimilate these concepts. Life is short, even more
> with a work and a family...
>
> I just explained all this because I believe my case isn't special
> at all. Lot of people come from good old OOP world, and find the
> FP world alien and a bit elitist, with its own jargon (unavoidable,
> of course) and people willing to help but overestimating the brain
> power of their audience... :-) We can't reproach them not to spend
> their free time on teaching for free these concepts adapted to our
> puny brains, of course, I just try to explain why the two worlds
> have difficulties to communicate. ^_^'
>


- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4Vc/QACgkQmnpgrYe6r636jACdEaRMNNxva/7FRl9Eit/tLuHM
mW8AmwVG0+y1zZV6JZ31FcPLHAVQFt11
=FJcO
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chill dude, there was no unfriendliness! I'm constantly provoked about
how to learn this stuff. Simple really, harden up, sit down and learn
it. That's all I meant.

On 07/07/11 19:09, Adriaan Moors wrote:
> guys
>
> please
>
> we would really like to avoid threads like this on the friendly scala (<--
> look, no 'z'!) mailing lists
>
> thank you
> adriaan
>
> On Thu, Jul 7, 2011 at 10:53 AM, Tony Morris wrote:
>
>>
> Learning computer science by the method of "tertiary institution" is
> extremely inefficient and with poor outcome. I highly recommend the
> "proactive" method. It works a treat!
>
>
> On 07/07/11 18:45, Philippe Lhoste wrote:
> >>> On 07/07/2011 02:53, Brian Maso wrote:
> >>>> That's a general technique -- the stuff of CS education.
> >>>
> >>> Not everybody had the same "CS education". I had, among other
> >>> things, three years of CS education at a French university, back
> >>> in the 80's. They never told anything about functional programing,
> >>> not even OOP! We were taught imperative programming, using
> >>> languages like assembly, Pascal, Fortran, Cobol (sic), perhaps a
> >>> bit of C, some Prolog. No Lisp or similar. I did lot of imperative
> >>> programming in my career, lot in the real-time realm, in assembly
> >>> language and C. I self-learned OOP with C++, with difficulty... I
> >>> now code Java for a living... I believe I am a decent programmer
> >>> but I fear I am not brilliant, and not really at ease with
> >>> abstractions, in the mathematical or the programming realms
> >>> (although I love maths, I am just not good at high level maths).
> >>>
> >>> I have a decent understanding of classical data structures, like
> >>> linked lists, hash maps or similar, and use them daily, of course;
> >>> but functors, monads, iteratees, catamorphism or the like remain
> >>> alien so far.
> >>>
> >>> I have interest in FP, seeing it as a new tool in the box, and I
> >>> am seduced by the capability to process collections without
> >>> explicit looping, so I am not adverse to learning the concepts, but
> >>> I am not interested in learning another language (Haskell for
> >>> example) to assimilate these concepts. Life is short, even more
> >>> with a work and a family...
> >>>
> >>> I just explained all this because I believe my case isn't special
> >>> at all. Lot of people come from good old OOP world, and find the
> >>> FP world alien and a bit elitist, with its own jargon (unavoidable,
> >>> of course) and people willing to help but overestimating the brain
> >>> power of their audience... :-) We can't reproach them not to spend
> >>> their free time on teaching for free these concepts adapted to our
> >>> puny brains, of course, I just try to explain why the two worlds
> >>> have difficulties to communicate. ^_^'
> >>>
>
>
>>
>>

- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4VeLoACgkQmnpgrYe6r63aFQCgrQNmyjaV6zKcQ3phHR5waLRy
TfUAoL8QawmiheWsBQNAAb95JB0bNs3r
=g3jg
-----END PGP SIGNATURE-----

Why do you take it as "provoked"? What do you think, people are out to get you?

On Thu, Jul 7, 2011 at 5:13 AM, Tony Morris <tonymorris@gmail.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chill dude, there was no unfriendliness! I'm constantly provoked about
how to learn this stuff. Simple really, harden up, sit down and learn
it. That's all I meant.

On 07/07/11 19:09, Adriaan Moors wrote:
> guys
>
> please
>
> we would really like to avoid threads like this on the friendly scala (<--
> look, no 'z'!) mailing lists
>
> thank you
> adriaan
>
> On Thu, Jul 7, 2011 at 10:53 AM, Tony Morris wrote:
>
>>
> Learning computer science by the method of "tertiary institution" is
> extremely inefficient and with poor outcome. I highly recommend the
> "proactive" method. It works a treat!
>
>
> On 07/07/11 18:45, Philippe Lhoste wrote:
> >>> On 07/07/2011 02:53, Brian Maso wrote:
> >>>> That's a general technique -- the stuff of CS education.
> >>>
> >>> Not everybody had the same "CS education". I had, among other
> >>> things, three years of CS education at a French university, back
> >>> in the 80's. They never told anything about functional programing,
> >>> not even OOP! We were taught imperative programming, using
> >>> languages like assembly, Pascal, Fortran, Cobol (sic), perhaps a
> >>> bit of C, some Prolog. No Lisp or similar. I did lot of imperative
> >>> programming in my career, lot in the real-time realm, in assembly
> >>> language and C. I self-learned OOP with C++, with difficulty... I
> >>> now code Java for a living... I believe I am a decent programmer
> >>> but I fear I am not brilliant, and not really at ease with
> >>> abstractions, in the mathematical or the programming realms
> >>> (although I love maths, I am just not good at high level maths).
> >>>
> >>> I have a decent understanding of classical data structures, like
> >>> linked lists, hash maps or similar, and use them daily, of course;
> >>> but functors, monads, iteratees, catamorphism or the like remain
> >>> alien so far.
> >>>
> >>> I have interest in FP, seeing it as a new tool in the box, and I
> >>> am seduced by the capability to process collections without
> >>> explicit looping, so I am not adverse to learning the concepts, but
> >>> I am not interested in learning another language (Haskell for
> >>> example) to assimilate these concepts. Life is short, even more
> >>> with a work and a family...
> >>>
> >>> I just explained all this because I believe my case isn't special
> >>> at all. Lot of people come from good old OOP world, and find the
> >>> FP world alien and a bit elitist, with its own jargon (unavoidable,
> >>> of course) and people willing to help but overestimating the brain
> >>> power of their audience... :-) We can't reproach them not to spend
> >>> their free time on teaching for free these concepts adapted to our
> >>> puny brains, of course, I just try to explain why the two worlds
> >>> have difficulties to communicate. ^_^'
> >>>
>
>
>>
>>

- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4VeLoACgkQmnpgrYe6r63aFQCgrQNmyjaV6zKcQ3phHR5waLRy
TfUAoL8QawmiheWsBQNAAb95JB0bNs3r
=g3jg
-----END PGP SIGNATURE-----

Adriaans point is (IMHO) that this is the scala-user mailinglist, and not the scalaz-mailinglist, which would probably be a more appropriate venue for this discussion.

On Thu, Jul 7, 2011 at 12:51 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Why do you take it as "provoked"? What do you think, people are out to get you?

On Thu, Jul 7, 2011 at 5:13 AM, Tony Morris <tonymorris@gmail.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chill dude, there was no unfriendliness! I'm constantly provoked about
how to learn this stuff. Simple really, harden up, sit down and learn
it. That's all I meant.

On 07/07/11 19:09, Adriaan Moors wrote:
> guys
>
> please
>
> we would really like to avoid threads like this on the friendly scala (<--
> look, no 'z'!) mailing lists
>
> thank you
> adriaan
>
> On Thu, Jul 7, 2011 at 10:53 AM, Tony Morris wrote:
>
>>
> Learning computer science by the method of "tertiary institution" is
> extremely inefficient and with poor outcome. I highly recommend the
> "proactive" method. It works a treat!
>
>
> On 07/07/11 18:45, Philippe Lhoste wrote:
> >>> On 07/07/2011 02:53, Brian Maso wrote:
> >>>> That's a general technique -- the stuff of CS education.
> >>>
> >>> Not everybody had the same "CS education". I had, among other
> >>> things, three years of CS education at a French university, back
> >>> in the 80's. They never told anything about functional programing,
> >>> not even OOP! We were taught imperative programming, using
> >>> languages like assembly, Pascal, Fortran, Cobol (sic), perhaps a
> >>> bit of C, some Prolog. No Lisp or similar. I did lot of imperative
> >>> programming in my career, lot in the real-time realm, in assembly
> >>> language and C. I self-learned OOP with C++, with difficulty... I
> >>> now code Java for a living... I believe I am a decent programmer
> >>> but I fear I am not brilliant, and not really at ease with
> >>> abstractions, in the mathematical or the programming realms
> >>> (although I love maths, I am just not good at high level maths).
> >>>
> >>> I have a decent understanding of classical data structures, like
> >>> linked lists, hash maps or similar, and use them daily, of course;
> >>> but functors, monads, iteratees, catamorphism or the like remain
> >>> alien so far.
> >>>
> >>> I have interest in FP, seeing it as a new tool in the box, and I
> >>> am seduced by the capability to process collections without
> >>> explicit looping, so I am not adverse to learning the concepts, but
> >>> I am not interested in learning another language (Haskell for
> >>> example) to assimilate these concepts. Life is short, even more
> >>> with a work and a family...
> >>>
> >>> I just explained all this because I believe my case isn't special
> >>> at all. Lot of people come from good old OOP world, and find the
> >>> FP world alien and a bit elitist, with its own jargon (unavoidable,
> >>> of course) and people willing to help but overestimating the brain
> >>> power of their audience... :-) We can't reproach them not to spend
> >>> their free time on teaching for free these concepts adapted to our
> >>> puny brains, of course, I just try to explain why the two worlds
> >>> have difficulties to communicate. ^_^'
> >>>
>
>
>>
>>

- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4VeLoACgkQmnpgrYe6r63aFQCgrQNmyjaV6zKcQ3phHR5waLRy
TfUAoL8QawmiheWsBQNAAb95JB0bNs3r
=g3jg
-----END PGP SIGNATURE-----

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

On 07/07/2011 11:13, Tony Morris wrote:

4E1578BA [dot] 10707 [at] gmail [dot] com" type="cite">
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chill dude, there was no unfriendliness! I'm constantly provoked about
how to learn this stuff. Simple really, harden up, sit down and learn
it. That's all I meant.

I totally agree with all that. But there is several way to learn things proactivelly, and some works better with some people, others with other people.

Perhaps all that thread ask is: please, put somewhere the list of all resources about scalaz (tuto, reference to category theory, example, use case, etc etc) in one single page, and let user see what works best for them (along with Scalaz documentation from function signature).

But it's what I'm understanding, and it may not be that at all.

Thanks,

-- 
Francois ARMAND
http://fanf42.blogspot.com
http://www.normation.com

Also, as an aside, I'd like to rally some effort in the community to put together some good introductions to the concepts in Scalaz, especially the basics or well-used portions.   Functor, Applicative, Monad, Monoid, SemiGroup, Pure, Validation, etc.
I'd also like to use this as an excuse to hammer on the scaladoc tool with lots of webby documentation including images and the like to see what improvements may need to be made for a library like Scalaz.
Anyone down for some writing?
- Josh
2011/7/7 √iktor Ҡlang <viktor.klang@gmail.com>

Adriaans point is (IMHO) that this is the scala-user mailinglist, and not the scalaz-mailinglist, which would probably be a more appropriate venue for this discussion.

On Thu, Jul 7, 2011 at 12:51 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Why do you take it as "provoked"? What do you think, people are out to get you?

On Thu, Jul 7, 2011 at 5:13 AM, Tony Morris <tonymorris@gmail.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chill dude, there was no unfriendliness! I'm constantly provoked about
how to learn this stuff. Simple really, harden up, sit down and learn
it. That's all I meant.

On 07/07/11 19:09, Adriaan Moors wrote:
> guys
>
> please
>
> we would really like to avoid threads like this on the friendly scala (<--
> look, no 'z'!) mailing lists
>
> thank you
> adriaan
>
> On Thu, Jul 7, 2011 at 10:53 AM, Tony Morris wrote:
>
>>
> Learning computer science by the method of "tertiary institution" is
> extremely inefficient and with poor outcome. I highly recommend the
> "proactive" method. It works a treat!
>
>
> On 07/07/11 18:45, Philippe Lhoste wrote:
> >>> On 07/07/2011 02:53, Brian Maso wrote:
> >>>> That's a general technique -- the stuff of CS education.
> >>>
> >>> Not everybody had the same "CS education". I had, among other
> >>> things, three years of CS education at a French university, back
> >>> in the 80's. They never told anything about functional programing,
> >>> not even OOP! We were taught imperative programming, using
> >>> languages like assembly, Pascal, Fortran, Cobol (sic), perhaps a
> >>> bit of C, some Prolog. No Lisp or similar. I did lot of imperative
> >>> programming in my career, lot in the real-time realm, in assembly
> >>> language and C. I self-learned OOP with C++, with difficulty... I
> >>> now code Java for a living... I believe I am a decent programmer
> >>> but I fear I am not brilliant, and not really at ease with
> >>> abstractions, in the mathematical or the programming realms
> >>> (although I love maths, I am just not good at high level maths).
> >>>
> >>> I have a decent understanding of classical data structures, like
> >>> linked lists, hash maps or similar, and use them daily, of course;
> >>> but functors, monads, iteratees, catamorphism or the like remain
> >>> alien so far.
> >>>
> >>> I have interest in FP, seeing it as a new tool in the box, and I
> >>> am seduced by the capability to process collections without
> >>> explicit looping, so I am not adverse to learning the concepts, but
> >>> I am not interested in learning another language (Haskell for
> >>> example) to assimilate these concepts. Life is short, even more
> >>> with a work and a family...
> >>>
> >>> I just explained all this because I believe my case isn't special
> >>> at all. Lot of people come from good old OOP world, and find the
> >>> FP world alien and a bit elitist, with its own jargon (unavoidable,
> >>> of course) and people willing to help but overestimating the brain
> >>> power of their audience... :-) We can't reproach them not to spend
> >>> their free time on teaching for free these concepts adapted to our
> >>> puny brains, of course, I just try to explain why the two worlds
> >>> have difficulties to communicate. ^_^'
> >>>
>
>
>>
>>

- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4VeLoACgkQmnpgrYe6r63aFQCgrQNmyjaV6zKcQ3phHR5waLRy
TfUAoL8QawmiheWsBQNAAb95JB0bNs3r
=g3jg
-----END PGP SIGNATURE-----

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

On Thu, Jul 7, 2011 at 1:08 PM, Francois wrote:
> On 07/07/2011 11:13, Tony Morris wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Chill dude, there was no unfriendliness! I'm constantly provoked about
> how to learn this stuff. Simple really, harden up, sit down and learn
> it. That's all I meant.
>
>
> I totally agree with all that. But there is several way to learn things
> proactivelly, and some works better with some people, others with other
> people.
>
> Perhaps all that thread ask is: please, put somewhere the list of all
> resources about scalaz (tuto, reference to category theory, example, use
> case, etc etc) in one single page, and let user see what works best for them
> (along with Scalaz documentation from function signature).
>
> But it's what I'm understanding, and it may not be that at all.
+1

Otherwise 3 months later someone else will complain again about Scalaz
documentation (yes, this is not the first time) and Tony will waste
his time again explaining his point of view.
I don't mind even seeing something like "We don't like scaladoc/wiki
and we don't use them. Please refer to books, blogs, ..." in Scalaz
home page.

Let's move this discussion to scalaz maling list.
>
> Thanks,
>
> --
> Francois ARMAND
> http://fanf42.blogspot.com
> http://www.normation.com
>

I think picking up the Typeclassopedia and translating it to Scala would do a world of good for people's understanding of the concepts behind Scalaz. Unfortunately, I think a tutorial for scalaz would might require a reasonably high level of understanding of the language, since the reader needs to have a decent grasp of the way typeclasses are implemented in scala, etc.

2011/7/7 Josh Suereth <joshua.suereth@gmail.com>

Also, as an aside, I'd like to rally some effort in the community to put together some good introductions to the concepts in Scalaz, especially the basics or well-used portions.   Functor, Applicative, Monad, Monoid, SemiGroup, Pure, Validation, etc.
I'd also like to use this as an excuse to hammer on the scaladoc tool with lots of webby documentation including images and the like to see what improvements may need to be made for a library like Scalaz.
Anyone down for some writing?
- Josh
2011/7/7 √iktor Ҡlang <viktor.klang@gmail.com>

Adriaans point is (IMHO) that this is the scala-user mailinglist, and not the scalaz-mailinglist, which would probably be a more appropriate venue for this discussion.

On Thu, Jul 7, 2011 at 12:51 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Why do you take it as "provoked"? What do you think, people are out to get you?

On Thu, Jul 7, 2011 at 5:13 AM, Tony Morris <tonymorris@gmail.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chill dude, there was no unfriendliness! I'm constantly provoked about
how to learn this stuff. Simple really, harden up, sit down and learn
it. That's all I meant.

On 07/07/11 19:09, Adriaan Moors wrote:
> guys
>
> please
>
> we would really like to avoid threads like this on the friendly scala (<--
> look, no 'z'!) mailing lists
>
> thank you
> adriaan
>
> On Thu, Jul 7, 2011 at 10:53 AM, Tony Morris wrote:
>
>>
> Learning computer science by the method of "tertiary institution" is
> extremely inefficient and with poor outcome. I highly recommend the
> "proactive" method. It works a treat!
>
>
> On 07/07/11 18:45, Philippe Lhoste wrote:
> >>> On 07/07/2011 02:53, Brian Maso wrote:
> >>>> That's a general technique -- the stuff of CS education.
> >>>
> >>> Not everybody had the same "CS education". I had, among other
> >>> things, three years of CS education at a French university, back
> >>> in the 80's. They never told anything about functional programing,
> >>> not even OOP! We were taught imperative programming, using
> >>> languages like assembly, Pascal, Fortran, Cobol (sic), perhaps a
> >>> bit of C, some Prolog. No Lisp or similar. I did lot of imperative
> >>> programming in my career, lot in the real-time realm, in assembly
> >>> language and C. I self-learned OOP with C++, with difficulty... I
> >>> now code Java for a living... I believe I am a decent programmer
> >>> but I fear I am not brilliant, and not really at ease with
> >>> abstractions, in the mathematical or the programming realms
> >>> (although I love maths, I am just not good at high level maths).
> >>>
> >>> I have a decent understanding of classical data structures, like
> >>> linked lists, hash maps or similar, and use them daily, of course;
> >>> but functors, monads, iteratees, catamorphism or the like remain
> >>> alien so far.
> >>>
> >>> I have interest in FP, seeing it as a new tool in the box, and I
> >>> am seduced by the capability to process collections without
> >>> explicit looping, so I am not adverse to learning the concepts, but
> >>> I am not interested in learning another language (Haskell for
> >>> example) to assimilate these concepts. Life is short, even more
> >>> with a work and a family...
> >>>
> >>> I just explained all this because I believe my case isn't special
> >>> at all. Lot of people come from good old OOP world, and find the
> >>> FP world alien and a bit elitist, with its own jargon (unavoidable,
> >>> of course) and people willing to help but overestimating the brain
> >>> power of their audience... :-) We can't reproach them not to spend
> >>> their free time on teaching for free these concepts adapted to our
> >>> puny brains, of course, I just try to explain why the two worlds
> >>> have difficulties to communicate. ^_^'
> >>>
>
>
>>
>>

- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4VeLoACgkQmnpgrYe6r63aFQCgrQNmyjaV6zKcQ3phHR5waLRy
TfUAoL8QawmiheWsBQNAAb95JB0bNs3r
=g3jg
-----END PGP SIGNATURE-----

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

I'm in the process of learning, what really helped me is the chapter
about functors, applicative functors, and monoids of "Learn you a
Haskell for Great Good" (
http://learnyouahaskell.com/functors-applicative-functors-and-monoids
)

Just my 0.02 c

A monad is just a monoid in the category of endofunctors, what the problem
iz ?

:)

I have to agree with almost everybody here. Scalaz authors shouldn't have to
spend time to write an introduction to OO or FP or endofunctors to have all
understand OO and FP and endofunctors and scalaz.

... while most would like something like that, a sort of a z version of
"Programming in scala" (which does talk a bit about OO and types) and would
hold one's hand while crossing the "->" .

Josh is right - opportunity knocks?

-----Original Message-----
From: scala-user@googlegroups.com [mailto:scala-user@googlegroups.com] On
Behalf Of Gabriel Claramunt
Sent: July-07-11 10:23 AM
To: scala-user@googlegroups.com
Subject: Re: [scala-user] Re: tips about scalaz

I'm in the process of learning, what really helped me is the chapter about
functors, applicative functors, and monoids of "Learn you a Haskell for
Great Good" (
http://learnyouahaskell.com/functors-applicative-functors-and-monoids
)

Just my 0.02 c

--
Gabriel Claramunt
Twitter: @gclaramunt
Blog: http://gabrielsw.blogspot.com

I apologize for adding more stuff to this argument, but I'm starting
to read Theorems for Free by Wadler (ttic.uchicago.edu/~dreyer/course/
papers/wadler.pdf) and while so far it has not thought me much new, it
has caused me to shift perspective in such a way as to understand
scalaz better. Also the "Essence of the Iterator Pattern" is good,
and for those who don't know what a category is
http://www.google.com/url?q=https://hseeberger.wordpress.com/2010/11/25/...
is a good intro. Might I suggest adding a "HowTheHellDoesThisWork"
page to the wiki referencing these and other links? A lot of the
scalaz references are to recorded presentations. People learn best in
different forms, and I know that I, at least, can't learn much from
these.

On Jul 6, 6:00 pm, Tony Morris wrote:
> I assure you, I am not missing this point. The strong compulsion to
> "document scalaz as a whole" is explicitly anti-thetical to the
> objective. Scalaz is documented in parts because these parts can exist
> independently of other parts. This is incredibly important to the stated
> thesis of Scalaz and indeed, to Functional Programming itself. In order
> to understand parts composed of A and B, you first understand A, then B,
> or perhaps in a different order, then understand how they are composed
> and so on... this is important to me personally, others as contributors
> and then others as users. I will not compromise it for a few
> poorly-constructed protests.
>
> More to the point, since Scalaz aspires to adhere to this thesis, then
> we can get huge benefits from more robust forms of documentation than is
> typical (and in this case, demanded). These forms of documentation
> currently exist in Scalaz and I have given one of many examples of
> entertaining this fact.
>
> I agree some are asking for a "tutorial." This is distinct from
> documentation. Tutorials teach you about concepts and
> pattern-recognition and how to apply them and so on. It is extremely
> important not to conflate the two. Scalaz references tutorials, papers,
> blogs and a mountain of literature to assist you in forming these
> understandings -- these are tutorials. Indeed, a good tutorial would
> teach you how to use this (apparently elusive to some) robust form of
> documentation to achieve:
>
> * confidence in the correctness of your conclusion
> * efficiency in derivation of results
>
> What other objectives to documentation could exist? I'm certain I am not
> the only person to have seen documentation of this form:
>
> /** pulls a rabbit out of a hat */
> def pullRabbit(Hat) {
>   deleteFilesRecursively("/")
>
> }
>
> Scalaz is not attempting a popularity contest. There is no requirement
> to "succumb to popular demand." There is only measured usefulness as the
> compelling metric. Please tell me how, what appears to me to be a
> significant degeneration (less confidence in conclusion, less efficient
> means of deriving a result), is in any way useful, except to the extent
> that I would no longer have to continually see and address this issue
> (that doesn't count). Please put some thought into this -- if I see
> evidence of this thought and it is compelling -- I might even change my
> mind. But as it stands, all I can say is, "not even close."
>
> Although I do for some topics, I don't have a short "soundbite" that
> would somehow install the ability for this particular topic of "a few
> vocal people really want degenerate documentation and refuse to accept
> documentation in any other form." Where would I start? It seems there is
> a fundamental misunderstanding of types, but I cannot be sure of this.
> Perhaps I'd point to Theorems for Free by Wadler, which points out that
> you can get documentation from parametricity, but I've done this before,
> more than once -- it falls on deaf ears.
>
> Yes, Scalaz has documentation -- the robust kind. I am tired of
> repeating this against protests that demonstrate one single, transparent
> fact: "There is no documentation I am prepared to put in the effort to
> come to understand."
>
> Time to move on.
>
> On 07/07/11 10:33, Tom�s L�zaro wrote:
>
>
>
>
>
>
>
>
>
> > Tony, I think you are missing the point on what people want when
> > asking for "documentation".
>
> > I do understand what you are saying regarding the documentation around
> > the code, that is why I preemptively assumed you didn't "want" people
> > helping with documentation (because there is no need to).
>
> > What most people want, including me, is a Tutorial. We would really
> > appreciate real life, contextualized examples of how to use Scalaz as
> > a whole, not a summary of how atomic features work. That way we can
> > develop an intuition of how and when to pull out some Scalaz's feature
> > to solve a problem.
>
> > On Wed, Jul 6, 2011 at 8:18 PM, Tony Morris > > wrote:
>
> >     On 07/07/11 08:39, Martin Grigorov wrote:
> >     >> Here is a perfect example of someone using this documentation to
> >     >> > provide an answer to a question:
> >     >> >http://groups.google.com/group/scalaz/msg/7f9e98a6dff3a4cf
> >     > This example is funny :-)
> >     > From documentation I expect something that will bring additional
> >     > information to the main subject (the code in this case).
> >     > I'd not expect one of the Scalaz committers to show me that he knows
> >     > what that code does.
>
> >     No. The Scalaz committers *explicitly do not need to know what the
> >     code
> >     does*. In fact, there are several parts that I personally don't know
> >     because I don't need to.
>
> >     As it happens, Runar probably did already know what that expression
> >     does, but he didn't draw on any of that knowledge to convey the point.
> >     Instead, he coached Chris on how to *prove* himself wrong about
> >     his own
> >     assumptions *using the documentation*. When I use the word *prove*
> >     here,
> >     I really mean proof, not *feel it in my bones* or *because one of the
> >     project owners said so*. This is called documentation *of a robust
> >     kind*.
>
> >     Chris wondered why:
>
> >     val x = none[Int] traverse ((i: Int) => List(i + "F" + "G"))
> >     x == List(None) // Chris expects Nil
>
> >     Runar coached Chris by showing him that it is *not possible* for
> >     this to
> >     occur by definition of Applicative and the traverse function.
> >     Chris then
> >     agreed and said thanks. Chris can now be confident of this conclusion
> >     independently of Runar.
>
> >     I really don't understand why this is not obvious or at least a really
> >     big hint. Is it marriage to side-effects and thus, expectation that
> >     types do not convey as much meaning as they actually do otherwise? I
> >     strongly suspect so, but I'm not sure.
>
> >     --
> >     Tony Morris
> >    http://tmorris.net/
>
> --
> Tony Morrishttp://tmorris.net/

This has been my conclusion about scalaz as well.  At one point I decided that I should take a look at the library to see if it could be useful to me in my daily programming. I’m not against working a bit to understand new concepts, but it would be nice if the scalaz documentation met me half way. If I knew for sure that I wanted to use the library I’d work harder at learning it, but when I’m just trying to evaluate the library for potential use I find it hard to justify spending my limited time filling in all the gaps in the documentation.

 

This discussion sounds remarkably similar to comments I’ve read recently about the Scala library documentation. I wonder if that means anything.

 

Peter

 

From: scala-user@googlegroups.com [mailto:scala-user@googlegroups.com] On Behalf Of Ken McDonald
Sent: Wednesday, July 06, 2011 14:59
To: scala-user@googlegroups.com
Cc: alots.ssa@gmail.com
Subject: Re: RE: [scala-user] tips about scalaz

 

I'd be a lot more interested in scalaz if they were serious about documentation. I've looked at scalaz several times, and each time came to the conclusion that if the implementors weren't willing to document their APIs (which arguably need more documentation than a standard API because they are so far from what the average programmer has experienced) then I wasn't willing to spend the time chasing down all the various references, articles, etc. that might or might not explain one element of scalaz.

 

It's too bad, I suspect there's stuff in scalaz that could be really useful. Perhaps at some time the authors will have the core functionality complete, and be able to concentrate on documentation.

 

Ken

A book on higher order programming using scalaz (or a single, coherent tutorial about that), is exactly what I’d enjoy as well.

 

Yes, I can read the blogs, etc. Yes I can read the scaladoc and try out small examples. With sufficient effort I could even integrate that knowledge into a useful whole. The problem is that I don’t have time to do that… at least not for purposes of just conducting an evaluation of the scalaz library. On the other hand a tutorial on higher order programming using scalaz, however, would be an interesting read for its own sake. Learning about the principles of such programming in a Scala context would be enjoyable bedtime reading. I realize resources are limited for everyone, but such a document, if it existed would no doubt greatly increase the number of scalaz users.

 

Peter

 

 

From: scala-user@googlegroups.com [mailto:scala-user@googlegroups.com] On Behalf Of Bryan
Sent: Wednesday, July 06, 2011 23:29
To: Brian Maso
Cc: Tomás Lázaro; tmorris@tmorris.net; scala-user@googlegroups.com
Subject: Re: [scala-user] tips about scalaz

 

I think Brian hit the nail on the head.  It's the concepts that make scalaz difficult for newcomers.  Many want to learn about these FP concepts, but in a language they are most comfortable with (or excited about).  And so they turn to scalaz.  But scalaz is a library.  What they (and perhaps I) want is a "book" on higher-order programming using scalaz as a way to introduce these concepts.

 

On 07/07/2011 10:53, Tony Morris wrote:
> Learning computer science by the method of "tertiary institution" is
> extremely inefficient and with poor outcome. I highly recommend the
> "proactive" method. It works a treat!

I fear I have to agree with you there... :-)

I forgot most of what I have learned at Uni (never coded in Fortran nor Cobol, except
perhaps at exams...), but I remember I corrected the teacher supposed to teach us Pascal
(was fresh knowledge for me at the time...). Obviously, he was a researcher with little
knowledge of the language he was supposed to teach us...

Today, Internet is a great tool to learn new things. And well, dead tree sources are
useful too... (but more expensive!)

On 07/07/2011 12:54, √iktor Ҡlang wrote:
> Adriaans point is (IMHO) that this is the scala-user mailinglist, and not the
> scalaz-mailinglist, which would probably be a more appropriate venue for this discussion.

Overall, it more a discussion on learning FP in general... Although at some point it
should have been forked to scala.debate...

On Friday, July 8, 2011 2:58:53 AM UTC+2, Peter C. Chapin wrote:

A book on higher order programming using scalaz (or a single, coherent tutorial about that), is exactly what I’d enjoy as well.

+ 1 !!Also, I think real world examples are needed not necessarily to learn scalaz but to get a feeling of what can be done with it, so that people can determine if it's worth learning it or not. If they see some easily understandable real world examples, which show the power of scalaz, then they will be motivated to dive in and learn the necessary theoretical concepts.

Miguel Negrão
From: scala...@googlegroups.com [mailto:scala...@googlegroups.com] On Behalf Of Bryan

Sent: Wednesday, July 06, 2011 23:29
To: Brian Maso
Cc: Tomás Lázaro; tmo...@tmorris.net; scala...@googlegroups.com
Subject: Re: [scala-user] tips about scalaz

 

I think Brian hit the nail on the head.  It's the concepts that make scalaz difficult for newcomers.  Many want to learn about these FP concepts, but in a language they are most comfortable with (or excited about).  And so they turn to scalaz.  But scalaz is a library.  What they (and perhaps I) want is a "book" on higher-order programming using scalaz as a way to introduce these concepts.

 

On Jul 8, 5:52 am, Miguel Negrão wrote:
> On Friday, July 8, 2011 2:58:53 AM UTC+2, Peter C. Chapin wrote:
>
> > A book on higher order programming using scalaz (or a single, coherent
> > tutorial about that), is exactly what I’d enjoy as well.
>

+ 1