The Ease of Scalaz (follow up)

Sorry, I found both the video and the Q&A's pretty much inscrutable,
which is rather ironic given the subject line :-(

So do a lot of people at first. What are you going to do about it?

On 09/09/2011 7:33 PM, "Alan Burlison" <alan.burlison@gmail.com> wrote:
> Sorry, I found both the video and the Q&A's pretty much inscrutable,
> which is rather ironic given the subject line :-(
>
> --
> Alan Burlison
> --

On 09/09/11 11:35, Tony Morris wrote:

> So do a lot of people at first. What are you going to do about it?

I found the last paragraph of your previous email rather condescending
and your reply above rather confrontational, so I guess what I'm going
to do it to stop reading any more of your emails.

You seem to want to evangelise the benefits of scalaz - that's a worthy
goal but I think you need to work on your style.

My previous conclusion has become even stronger:
Scalaz should NOT be used in real projects with a team of developers with different programming skills.

-
Andrey

On 09/09/11 12:24, Andrey Somov wrote:

> My previous conclusion has become even stronger:
> Scalaz should NOT be used in real projects with a team of developers with
> different programming skills.

I wouldn't go quite that far. For example if understanding all of the
297 page Java Generics FAQ was necessary in order to use them then
clearly they would be totally useless. However that's not the case, the
majority of the time you just have to know how to use generic classes,
not how to write them.

If I was to make a general comment it would be that the balance of
effort needs to be on explaining how to *use* features rather than they
are implemented. I've seen several blog posts and Stack Overflow items
where there's a whole series of anguished comments of the form "Yes, but
please tell me what use it is!" Monads seem to be the definitive
example of this ;-)

Plus the documentation is really Scala's worst enemy at times - as a
random example,
http://www.scala-lang.org/api/current/index.html#scala.util.control.Exception$
- what on earth does 'independently composable' mean and why do I care?
What do 'opt' and 'either' do? yes I can guess, but to be sure I need
to go off on a recursive document search, and that's irksome.

I know the documentation is being worked on and in general I'd say that
one of the things that's most attractive to me as a Scala newcomer is
the fact that these issues *are* recognised and *are* being addressed.
It's that kind of pragmatic response that I believe will be one of the
major contributors to Scala's success. Telling people they are clearly
dumb if they can't understand what you are telling them is barely OK in
academia, it's incredibly destructive in the commercial space.

[1] http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.pdf

Hi Andrey & Alan!
Scalaz is a tool to assist the programmer with functional programming
in scala. Functional programming is
a tool which is build upon referential transparency. This leads to a
certain ’style’ of programming because you have to be
explicit about side effects. But also you as the developer gain compos
ability and this is a very nice property. Because you
can compose function to more complex abstractions. Some people claim
the essence of programming is abstraction. So functional
programming can help a single programmer or a team to solve their
problems.
Statements like ‘developers with different programming skills. ‘ is
pretty bold IMHO. Because they will have ALWAYS
different programming skills, after all were are individuals, right?
To blame a programming library for lets call
it organisational or educational reasons just seems inappropriate to
me.
Just look at some examples of scalaz or video tutorials like this:
http://vimeo.com/10482466
If you don’t find any interesting fine if you find something that
interests you even better. You don’t have to
understand the whole library (that’s the point of heikos talk I
think). Just get started and look for opportunities to use it
in my experience in makes you more productive.

Regards Andreas

On 9 Sep., 13:24, Andrey Somov wrote:
> My previous conclusion has become even stronger:
> Scalaz should NOT be used in real projects with a team of developers with
> different programming skills.
>
> -
> Andrey

I think it is fair to compare this with what it also alleviates. You
aren't just getting a fancy way to collect validations on a range of
items. You are getting a fully tested way of doing this. That is, it
seems that by moving this into the type system, you can ease much of
the testing burden such that tests to make sure you handle when only
the 3rd or possibly the 1st and last argument are malformed or missing
are no longer explicitly necessary.

The same reason the === is nice. Moves what could have been caught by
a test into something that doesn't need to be tested because the type
system can do the job.

That is to say, you can't just compare this with the code it directly
replaced, but also the code that is no longer necessary because of it.
In my eye, it already looked nice on just the former. Adding in the
later is an additional benefit that seems huge to me.

Actually I was "evangelizing" learning. You have chosen the path of "whinging." Thanks for answering my rather mundane question.

On 09/09/2011 9:04 PM, "Alan Burlison" <alan.burlison@gmail.com> wrote:
> On 09/09/11 11:35, Tony Morris wrote:
>
>> So do a lot of people at first. What are you going to do about it?
>
> I found the last paragraph of your previous email rather condescending
> and your reply above rather confrontational, so I guess what I'm going
> to do it to stop reading any more of your emails.
>
> You seem to want to evangelise the benefits of scalaz - that's a worthy
> goal but I think you need to work on your style.
>
> --
> Alan Burlison
> --

On 09/09/11 21:43, Tony Morris wrote:

> Actually I was "evangelizing" learning. You have chosen the path of
> "whinging." Thanks for answering my rather mundane question.

As I said, I think your style needs a little work.

It doesn't really. I teach a lot. The whingy crap simply indicates a poor prognosis. Try to consider alternative responses than carrying on like a princess. They exist, promise.

On 10/09/2011 8:04 AM, "Alan Burlison" <alan.burlison@gmail.com> wrote:
> On 09/09/11 21:43, Tony Morris wrote:
>
>> Actually I was "evangelizing" learning. You have chosen the path of
>> "whinging." Thanks for answering my rather mundane question.
>
> As I said, I think your style needs a little work.
>
> --
> Alan Burlison
> --

Watching the video I had only one thought: Why would anyone bother?!
The speaker went to great length to turn a simple statement "args(index).toInt" into something monstrous and un-maintainable. All without providing a convincing argument as to why.
This is a VERY VERY hard sell. Maybe before doing all the Q and A on how to learn all this stuff it would be most productive to really, and mean REALLY convince the audience that there is a net benefit.
Here a quick pros and cons analysis. Pros: some vague promise of type and exception safety. However I am not landing a shuttle, do I really need that in my program? Cons: excessively verbose and complicated, 10 times more lines of code for such a simple example.
I am not convinced that the end result is worth all the effort. What are you gonna do about it?

On 10/09/11 11:21, Aleksey Nikiforov wrote:
> Watching the video I had only one thought: Why would anyone bother?!
>
> The speaker went to great length to turn a simple statement
> "args(index).toInt" into something monstrous and un-maintainable. All
> without providing a convincing argument as to why.
>
> This is a VERY VERY hard sell. Maybe before doing all the Q and A on how to
> learn all this stuff it would be most productive to really, and mean REALLY
> convince the audience that there is a net benefit.
>
> Here a quick pros and cons analysis. Pros: some vague promise of type and
> exception safety. However I am not landing a shuttle, do I really need that
> in my program? Cons: excessively verbose and complicated, 10 times more
> lines of code for such a simple example.
>
> I am not convinced that the end result is worth all the effort. What are you
> gonna do about it?
>
Give you the skills to make a more informed assessment. Are you ready?

Hi!
Are you sure you watched the video with full attention? You say he did
turn something "simple" into a monster. After that heiko gives a
example of his SBT plugin. So the POINT is if you have a single input
and you want to verify multiple properties on that. The main focus is
to do multiple validations and to collect the results of that
elegantly. If you have only a single check it barely makes sense. Does
this help?
Regards Andreas

On 10 Sep., 03:21, Aleksey Nikiforov wrote:
> Watching the video I had only one thought: Why would anyone bother?!
>
> The speaker went to great length to turn a simple statement
> "args(index).toInt" into something monstrous and un-maintainable. All
> without providing a convincing argument as to why.
>
> This is a VERY VERY hard sell. Maybe before doing all the Q and A on how to
> learn all this stuff it would be most productive to really, and mean REALLY
> convince the audience that there is a net benefit.
>
> Here a quick pros and cons analysis. Pros: some vague promise of type and
> exception safety. However I am not landing a shuttle, do I really need that
> in my program? Cons: excessively verbose and complicated, 10 times more
> lines of code for such a simple example.
>
> I am not convinced that the end result is worth all the effort. What are you
> gonna do about it?

On 09/10/11 00:48, Tony Morris wrote:

> It doesn't really. I teach a lot. The whingy crap simply indicates a poor
> prognosis. Try to consider alternative responses than carrying on like a
> princess. They exist, promise.

You really are very amusing :-)

Aleksey Nikiforov skrev 2011-09-10 03:21:
> Watching the video I had only one thought: Why would anyone bother?!

I personally discover the utility of Validation and applicative functors
when I wrote a stateless parser for data stored in JSON files. I wanted
to report all errors found in the parsing, not just the first, and still
possibly return all values successfully parsed. This is one case where
exceptions just doesn't work. Unfortunately I had to write it in C#
which is not powerful enough to make these concepts easy to use. Scala
does a much better job at it.

/Jesper Nordenberg

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

On 09/10/2011 09:10 PM, Jesper Nordenberg wrote:
> Aleksey Nikiforov skrev 2011-09-10 03:21:
>> Watching the video I had only one thought: Why would anyone bother?!
>
> I personally discover the utility of Validation and applicative functors
> when I wrote a stateless parser for data stored in JSON files. I wanted
> to report all errors found in the parsing, not just the first, and still
> possibly return all values successfully parsed. This is one case where
> exceptions just doesn't work. Unfortunately I had to write it in C#
> which is not powerful enough to make these concepts easy to use. Scala
> does a much better job at it.
>
> /Jesper Nordenberg
>

What's the problem?
http://paste.pocoo.org/show/473542/

I didn't say it's impossible to do in C#, after all I wrote the code,
but using it was awkward. The major problems I encountered was that C#'s
type inference isn't powerful enough and the crappy support for operator
overloading. Not having implicit parameters is another problem.

/Jesper Nordenberg

Tony Morris skrev 2011-09-10 13:14:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 09/10/2011 09:10 PM, Jesper Nordenberg wrote:
>> Aleksey Nikiforov skrev 2011-09-10 03:21:
>>> Watching the video I had only one thought: Why would anyone bother?!
>>
>> I personally discover the utility of Validation and applicative functors
>> when I wrote a stateless parser for data stored in JSON files. I wanted
>> to report all errors found in the parsing, not just the first, and still
>> possibly return all values successfully parsed. This is one case where
>> exceptions just doesn't work. Unfortunately I had to write it in C#
>> which is not powerful enough to make these concepts easy to use. Scala
>> does a much better job at it.
>>
>> /Jesper Nordenberg
>>
>
> What's the problem?
> http://paste.pocoo.org/show/473542/
>
>
> - --
> Tony Morris
> http://tmorris.net/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJOa0Z5AAoJEPxHMY3rBz0PxMAH/0jSY8fPQ1jjKt5j28eVVrxz
> cQWaQZyoMeIR5p2JSV2UYOh7e86Rr7h7qzF2XxcaKisTrqjhmmw/qUbpuCq3TTlX
> iaHlJIgtYUORuQa4fPovxOt5UE/tQTXSnDsoMYA2f7zF/lCWCGy/7d0W/7zQiQpV
> btUF75FvqbnXNSA49qRuwkuycMc7pdgsMbppjroTorFzJWyMzfXbdxj4nPXdi849
> sXYFpMiAPS2wnRivlYa6cdXBqw7qh9dNjpJ7LY7nXSsgz7uSipBCKDXo5DrfIqdy
> dYdP09XOY5VrEOqeJBVfZQCzRHIJPW4jZ+P4jlHZ9GTLntlvrte4iG5s3bftt5k=
> =I3Es
> -----END PGP SIGNATURE-----
>

Thanks for posting the video Tony.
While I'm still only learning Scala and my grasp of FP is pretty loose at this point the videodefinitely gave me a taste of the coolness possible with Scalaz.
In particular, the applicative functors stuff (Still need to grok that term in all it's meaning) usingValidation was immediately obviously useful to me.
I don't know how many times I've had to wrangle with the problem that section addressed so neatly but I do know I've done so in Java, PHP and Python many times and never been happy withthe usual approach (If-Else/Loop-Switch moshpit).

On 9 September 2011 02:12, Tony Morris <tonymorris@gmail.com> wrote:

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

Hello guys,
I just watched Heiko Seeberger's video of Scalaz at Scala Days 2011.
http://days2011.scala-lang.org/node/138/275

I think this is an excellent talk that introduces some of the benefits
of Scalaz library support without getting too "dirty". I'm glad we have
people like Heiko to present a different view on these topics to bring
diversity to modes of teaching and learning to benefit all.

I just thought I'd follow up on a couple of questions that were asked. I
have summarised the questions:

Q: Is the type-lambda necessary with regard to the NonEmptyList?
A: Actually, the use-case of "accumulating errors" using NonEmptyList is
common enough that Scalaz implements specialisations. We saw this with
method names such as "failNel." Therefore, the type constructor too gets
special treatment with a type alias.

type ValidationNEL[E, X] = Validation[NonEmptyList[E], X]

However, it is still not specific enough so as to avoid the type lambda
:( That is to say, since the "String" part is still left parameterised
[E], it requires "partial application" using a type lambda. If one were
to specialise it further, one could avoid the type lambda:

type ValidationNELStringErrors[X] = ValidationNEL[String, X]

Arguably, this is simply moving the type lambda to top-level (rather
than local when defined inline) and giving it a name. Specialisation at
this level is questionable in my opinion.

Here is how it looks without such a specialisation:

[({type A[B]=ValidationNEL[String, B]})#A]

Here is how it would look if we specialised even further to String:

[ValidationNELStringErrors]

Feel free to define such a type-alias in your application code, where
you may not even be using String. I do it myself where appropriate.

Q: Can I accumulate errors with a for-comprehension?
A: This is my favourite question :) I like questions that cannot
possibly be controversial (or can they?) :)

The answer is: definitively no. This is not a property of Scalaz, but a
fact in general. For-comprehensions denote monadic computation, while
applicative functors are more general. Let's be clear on that: The
applicative functor interface provides a strict subset of the derived
operations of the monad interface, however, the data types that are
applicative functors is a strict superset of those that are monads. It
is extremely important to keep contra/co variance in mind here when
evaluating this statement, because what I am about to tell you appears
to contradict it :) (but it doesn't).

The operation of "accumulating errors" with Validation can *only* be
written using an Applicative functor. It is just not possible to write
using a Monad interface (and therefore, for-comprehensions). I could
give you a proof of this, or I could show you a naive attempt at it then
hitting a wall, but that would be robbing you of a really fun and
helpful exercise. Try it!

The original paper (Applicative Programming With Effects) mentions the
use of a Monoid for accumulating errors. This is more specific than is
necessary, and as Heiko mentions, only Semigroup is necessary (all
Monoids are Semigroups).

By the way, I see this concept "accidentally invented" quite often.
Indeed, I accidentally invented it when writing web applications for
form field validation in 2008 before realising, "hey wait a minute, this
is precisely what was in that paper (modulo Monoid/Semigroup)!"

Q: How do I learn this stuff?
A: Well, this is a difficult question and one that I have spent much
time tackling.

First and foremost, focus on the *computational concept*. Try not to
spend much time worrying about specifics of syntax. If you have to read
it in Haskell because there is no other material, just learn the subset
of syntax that is required to internalise the concept -- it should only
take a few minutes and there are plenty of people to help understand
syntax. Surely you've witnessed the incredible enthusiasm of people who
have memorised various syntaxes to tell you all about it -- Haskell is
no different.

Fortunately, the same concept is already documented in Scala for you --
that's what Scalaz *is*! So if you prefer Scala syntax, go right ahead
and read it. As for the general interface, well unfortunately, this is
not possible to write in Java (type system) so I cannot present you the
Java syntax. We really are limited in the syntax that we can use for
teaching here. I've even used a pseudo-Java before where I modify the
type system on the spot. This usually has some success, but it is limited.

Importantly, I often encounter an enormous amount of attention devoted
to syntax *even when I present a syntax that is agreeable to by the
querying person*. I see this online and in real life often. This is when
I think "uh oh, this is a distraction that I was hoping to avoid -- can
I bring the discourse back on track?" In other words, try your very best
to focus on the computational concept. Focus on the problem it solves in
both a clinical sense (i.e. here is the problem expressed algebraically)
and an applied sense (i.e. how do I validate web form fields?). It is my
opinion that a good teacher will iterate between these two so as to
unify the idea in the student's mind. However, it is an obligation of
the student to trust the teacher, to not be distracted by tedious
details and to devote themselves to working with the teacher to the
common goal of gaining understanding. Sometimes a student will give up,
"I'm not getting anywhere with this", but that is because (my opinion)
there *must* be an initial penalty incurred, whereby the student simply
trusts the teacher despite apparent divergences from the goal -- the
teacher knows what they are doing -- let's hope. I do sympathise with
students who have been let down in the past of course, but what can I
do, but keep trying?

Hope that helps.


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

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

iQEcBAEBAgAGBQJOaVneAAoJEPxHMY3rBz0P98cIAMsqRVRcPTLvItbweDlgB508
FdYRE9hKGmkk1c2PCinMutthH+vsVfiDXh19+en3IRMbObpJRDB4pw65lzpMzuZ9
3VbVk4Jiai1PHFoFw3rDLdtSpGFMPIv56RrnKabRgpWdJ800kSPuVi2CencGiA8O
MMurpMs3yLtJlev5M7DZby31SORnGj3y9/3OaVC2QMWpNnjfNsW9fcbD/AnXdEkH
/9oMAmj80nd5S1Wyb9WODFnSFhrOVFwDhpQhSKmnAav5ZVzs6/FVa2/TRYKkDcct
bTIlKEkqvvCs3gNy4UPhkP6a72cL1lXF/dtkIAm2G7Nhale0k5vThPBA8UtDCyM=
=6N5V
-----END PGP SIGNATURE-----

On 09/12/2011 03:29 PM, Adam Jorgensen wrote:
> I do know I've done so in Java
Close your eyes.

Now open them.

http://functionaljava.googlecode.com/svn/artifacts/3.0/javadoc/fj/data/V...

Now close them again.

Now open them.

Hope that wasn't too traumatic :)

Argh! My eyes!
;-)

On 12 September 2011 07:39, Tony Morris <tonymorris@gmail.com> wrote:

On 09/12/2011 03:29 PM, Adam Jorgensen wrote:
> I do know I've done so in Java
Close your eyes.

Now open them.

http://functionaljava.googlecode.com/svn/artifacts/3.0/javadoc/fj/data/Validation.html#accumapply%28fj.Semigroup,%20fj.data.Validation%29

Now close them again.

Now open them.

Hope that wasn't too traumatic :)

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

On Wednesday I will be giving a talk called "Practical Scalaz" at Skillsmatter, London. I'll have a bit more time than the 25 minutes that Heiko had at scaladays, so hopefully I'll be able to expand on some of the ways I have actually benefited from scalaz.
On example: a month ago, there was some shenanigans in the currency markets and I had to work something out very quickly for my day job. Monoids came to the rescue and, in particular, one typeclass instance in scalaz. What would have been twenty lines of Java, probably 4 of scala became 3 c. h. a. r. a. c. t. e. r. s. thanks to scalaz (with no bugs).
http://skillsmatter.com/event/scala/scalaz
See you there.
Chris
Date: Fri, 9 Sep 2011 20:21:34 -0500
Subject: Re: [scala-user] The Ease of Scalaz (follow up)
From: lexn82@gmail.com
To: tmorris@tmorris.net
CC: alan.burlison@gmail.com; scala-user@googlegroups.com

Watching the video I had only one thought: Why would anyone bother?!
The speaker went to great length to turn a simple statement "args(index).toInt" into something monstrous and un-maintainable. All without providing a convincing argument as to why.
This is a VERY VERY hard sell. Maybe before doing all the Q and A on how to learn all this stuff it would be most productive to really, and mean REALLY convince the audience that there is a net benefit.
Here a quick pros and cons analysis. Pros: some vague promise of type and exception safety. However I am not landing a shuttle, do I really need that in my program? Cons: excessively verbose and complicated, 10 times more lines of code for such a simple example.
I am not convinced that the end result is worth all the effort. What are you gonna do about it?

On Mon, Sep 12, 2011 at 02:39, Tony Morris wrote:
> On 09/12/2011 03:29 PM, Adam Jorgensen wrote:
>> I do know I've done so in Java
> Close your eyes.
>
> Now open them.
>
> http://functionaljava.googlecode.com/svn/artifacts/3.0/javadoc/fj/data/V...
>
> Now close them again.
>
> Now open them.
>
> Hope that wasn't too traumatic :)

I was talking to someone from JPL/NASA who mentioned they tried
functional java, but that _was_ too traumatic. :-)

They are now considering Scala or Haskell for that project.

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

On 09/15/2011 08:03 AM, Daniel Sobral wrote:
> On Mon, Sep 12, 2011 at 02:39, Tony Morris wrote:
>> On 09/12/2011 03:29 PM, Adam Jorgensen wrote:
>>> I do know I've done so in Java
>> Close your eyes.
>>
>> Now open them.
>>
>> http://functionaljava.googlecode.com/svn/artifacts/3.0/javadoc/fj/data/V...
>>
>> Now close them again.
>>
>> Now open them.
>>
>> Hope that wasn't too traumatic :)
>
> I was talking to someone from JPL/NASA who mentioned they tried
> functional java, but that _was_ too traumatic. :-)
>
> They are now considering Scala or Haskell for that project.
>

That is the goal of Functional Java after all :)

If Functional Java is traumatic, wait until they try Java.

By the way, to anyone who liked this presentation, I strongly
recommend this one by Chris Marshall (oxbow_lakes on S.O.):

http://t.co/ni2hnW7W

It made clear to me some things that should have been obvious, but
which had escaped my notice so far.

On Thu, Sep 8, 2011 at 21:12, Tony Morris wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello guys,
> I just watched Heiko Seeberger's video of Scalaz at Scala Days 2011.
> http://days2011.scala-lang.org/node/138/275
>
> I think this is an excellent talk that introduces some of the benefits
> of Scalaz library support without getting too "dirty". I'm glad we have
> people like Heiko to present a different view on these topics to bring
> diversity to modes of teaching and learning to benefit all.
>
> I just thought I'd follow up on a couple of questions that were asked. I
> have summarised the questions:
>
> Q: Is the type-lambda necessary with regard to the NonEmptyList?
> A: Actually, the use-case of "accumulating errors" using NonEmptyList is
> common enough that Scalaz implements specialisations. We saw this with
> method names such as "failNel." Therefore, the type constructor too gets
> special treatment with a type alias.
>
> type ValidationNEL[E, X] = Validation[NonEmptyList[E], X]
>
> However, it is still not specific enough so as to avoid the type lambda
> :( That is to say, since the "String" part is still left parameterised
> [E], it requires "partial application" using a type lambda. If one were
> to specialise it further, one could avoid the type lambda:
>
> type ValidationNELStringErrors[X] = ValidationNEL[String, X]
>
> Arguably, this is simply moving the type lambda to top-level (rather
> than local when defined inline) and giving it a name. Specialisation at
> this level is questionable in my opinion.
>
> Here is how it looks without such a specialisation:
>
> [({type A[B]=ValidationNEL[String, B]})#A]
>
> Here is how it would look if we specialised even further to String:
>
> [ValidationNELStringErrors]
>
> Feel free to define such a type-alias in your application code, where
> you may not even be using String. I do it myself where appropriate.
>
> Q: Can I accumulate errors with a for-comprehension?
> A: This is my favourite question :) I like questions that cannot
> possibly be controversial (or can they?) :)
>
> The answer is: definitively no. This is not a property of Scalaz, but a
> fact in general. For-comprehensions denote monadic computation, while
> applicative functors are more general. Let's be clear on that: The
> applicative functor interface provides a strict subset of the derived
> operations of the monad interface, however, the data types that are
> applicative functors is a strict superset of those that are monads. It
> is extremely important to keep contra/co variance in mind here when
> evaluating this statement, because what I am about to tell you appears
> to contradict it :) (but it doesn't).
>
> The operation of "accumulating errors" with Validation can *only* be
> written using an Applicative functor. It is just not possible to write
> using a Monad interface (and therefore, for-comprehensions). I could
> give you a proof of this, or I could show you a naive attempt at it then
> hitting a wall, but that would be robbing you of a really fun and
> helpful exercise. Try it!
>
> The original paper (Applicative Programming With Effects) mentions the
> use of a Monoid for accumulating errors. This is more specific than is
> necessary, and as Heiko mentions, only Semigroup is necessary (all
> Monoids are Semigroups).
>
> By the way, I see this concept "accidentally invented" quite often.
> Indeed, I accidentally invented it when writing web applications for
> form field validation in 2008 before realising, "hey wait a minute, this
> is precisely what was in that paper (modulo Monoid/Semigroup)!"
>
> Q: How do I learn this stuff?
> A: Well, this is a difficult question and one that I have spent much
> time tackling.
>
> First and foremost, focus on the *computational concept*. Try not to
> spend much time worrying about specifics of syntax. If you have to read
> it in Haskell because there is no other material, just learn the subset
> of syntax that is required to internalise the concept -- it should only
> take a few minutes and there are plenty of people to help understand
> syntax. Surely you've witnessed the incredible enthusiasm of people who
> have memorised various syntaxes to tell you all about it -- Haskell is
> no different.
>
> Fortunately, the same concept is already documented in Scala for you --
> that's what Scalaz *is*! So if you prefer Scala syntax, go right ahead
> and read it. As for the general interface, well unfortunately, this is
> not possible to write in Java (type system) so I cannot present you the
> Java syntax. We really are limited in the syntax that we can use for
> teaching here. I've even used a pseudo-Java before where I modify the
> type system on the spot. This usually has some success, but it is limited.
>
> Importantly, I often encounter an enormous amount of attention devoted
> to syntax *even when I present a syntax that is agreeable to by the
> querying person*. I see this online and in real life often. This is when
> I think "uh oh, this is a distraction that I was hoping to avoid -- can
> I bring the discourse back on track?" In other words, try your very best
> to focus on the computational concept. Focus on the problem it solves in
> both a clinical sense (i.e. here is the problem expressed algebraically)
> and an applied sense (i.e. how do I validate web form fields?). It is my
> opinion that a good teacher will iterate between these two so as to
> unify the idea in the student's mind. However, it is an obligation of
> the student to trust the teacher, to not be distracted by tedious
> details and to devote themselves to working with the teacher to the
> common goal of gaining understanding. Sometimes a student will give up,
> "I'm not getting anywhere with this", but that is because (my opinion)
> there *must* be an initial penalty incurred, whereby the student simply
> trusts the teacher despite apparent divergences from the goal -- the
> teacher knows what they are doing -- let's hope. I do sympathise with
> students who have been let down in the past of course, but what can I
> do, but keep trying?
>
> Hope that helps.
>
>
> - --
> Tony Morris
> http://tmorris.net/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJOaVneAAoJEPxHMY3rBz0P98cIAMsqRVRcPTLvItbweDlgB508
> FdYRE9hKGmkk1c2PCinMutthH+vsVfiDXh19+en3IRMbObpJRDB4pw65lzpMzuZ9
> 3VbVk4Jiai1PHFoFw3rDLdtSpGFMPIv56RrnKabRgpWdJ800kSPuVi2CencGiA8O
> MMurpMs3yLtJlev5M7DZby31SORnGj3y9/3OaVC2QMWpNnjfNsW9fcbD/AnXdEkH
> /9oMAmj80nd5S1Wyb9WODFnSFhrOVFwDhpQhSKmnAav5ZVzs6/FVa2/TRYKkDcct
> bTIlKEkqvvCs3gNy4UPhkP6a72cL1lXF/dtkIAm2G7Nhale0k5vThPBA8UtDCyM=
> =6N5V
> -----END PGP SIGNATURE-----
>