Rewrite Applicative Functor definition

[sjsyrek]

This could, perhaps, use some work, but it’s a difficult concept, and I wanted to take a crack at something more comprehensive and a little more specific than “an object with an ‘ap’ method” just because that doesn’t help people understand the relationship of this structure to other FP structures (and also implies that functions in our world are just another kind of OOP-style method omg).

[sjsyrek]

I'm iffy about mentioning the laws, at least without further elucidation. Fine line between comprehensiveness and succinctness (or killing it and overkill)

[sjsyrek]

It is definitely too long. Any specific suggestions for cutting it down? The thing is, you can't understand Applicative easily without first understanding monoid and functor. Can I assume that at the outset? Because then I could delete that material. I suppose this is one reason not to alphabetize things, though we might consider grouping. Or maybe just cross-linking and explaining "you should read monoid, etc." first. I could also delete the laws applicatives must follow.

[jethrolarson]

Is it really necessary to explain monoid here? What is really needed to teach the basic usage of the interface?

[jethrolarson]

When I'm working on this document I keep asking myself what can be cut, if simpler words will work, and if an example can take the place of some hard to describe concept

[sjsyrek]

Teaching how to use is different from teaching to understand. You can say that applicatives apply functions within a context to values within a context, or something like that, or what we have now: an object with an 'ap' function, but that won't help anyone understand the principles it's based on, why it exists, how it's useful. So what I'm saying is not to explain monoid here but to state that an understanding of monoid and functor are necessary before moving on to applicative

[sjsyrek]

That makes sense. Me too. Hence the editorial bull session we have going here :-)

[jethrolarson]

A laudable goal, but I think it's one that's best served by an external resource. We could stand this up as a wiki page or blog article or whatever and link to it

On Thu, Aug 4, 2016, 9:57 AM Steven Syrek notifications@github.com wrote:

Teaching how to use is different from teaching to understand. You can say that applicatives apply functions within a context to values within a context, or something like that, or what we have now: an object with an 'ap' function, but that won't help anyone understand the principles it's based on, why it exists, how it's useful. So what I'm saying is not to explain monoid here but to state that an understanding of monoid and functor are necessary before moving on to applicative

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/hemanth/functional-programming-jargon/pull/97#issuecomment-237615262, or mute the thread https://github.com/notifications/unsubscribe-auth/AAB-4PTLcHvheyAVnHMv-R3O5P28nWFlks5qchn4gaJpZM4Jahds .

[jethrolarson]

Same goes for monad. If we're to try defining that so that users would get a deep understanding it'd be too overwhelming for newcomers to understand at all

On Thu, Aug 4, 2016, 10:01 AM Jethro Larson jethrolarson@gmail.com wrote:

A laudable goal, but I think it's one that's best served by an external resource. We could stand this up as a wiki page or blog article or whatever and link to it

On Thu, Aug 4, 2016, 9:57 AM Steven Syrek notifications@github.com wrote:

Teaching how to use is different from teaching to understand. You can say that applicatives apply functions within a context to values within a context, or something like that, or what we have now: an object with an 'ap' function, but that won't help anyone understand the principles it's based on, why it exists, how it's useful. So what I'm saying is not to explain monoid here but to state that an understanding of monoid and functor are necessary before moving on to applicative

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/hemanth/functional-programming-jargon/pull/97#issuecomment-237615262, or mute the thread https://github.com/notifications/unsubscribe-auth/AAB-4PTLcHvheyAVnHMv-R3O5P28nWFlks5qchn4gaJpZM4Jahds .

[sjsyrek]

I'll take a crack at something more succinct, but I do think something ought to be said about what these things actually are. Otherwise, why would anyone want to use them? We aren't likely anyone's first or last port of call for these definitions. That said I like the wiki idea too

[jethrolarson]

I just want this to be like a taste of these concepts with some examples. People should be left wanting more.

On Thu, Aug 4, 2016, 10:29 AM Steven Syrek notifications@github.com wrote:

I'll take a crack at something more succinct, but I do think something ought to be said about what these things actually are. Otherwise, why would anyone want to use them? We aren't likely anyone's first or last port of call for these definitions. That said I like the wiki idea too

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/hemanth/functional-programming-jargon/pull/97#issuecomment-237624174, or mute the thread https://github.com/notifications/unsubscribe-auth/AAB-4F7lOFKp8iZgXuv9E4z42D7nVrhKks5qciF0gaJpZM4Jahds .

[sjsyrek]

So it's like going out on a first date with a monad?

[jethrolarson]

Coffee date

On Thu, Aug 4, 2016, 11:13 AM Steven Syrek notifications@github.com wrote:

So it's like going out on a first date with a monad?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/hemanth/functional-programming-jargon/pull/97#issuecomment-237636741, or mute the thread https://github.com/notifications/unsubscribe-auth/AAB-4DnKaXwn8ib1QiBLs9J9sOYWih5Zks5qciu6gaJpZM4Jahds .

[sjsyrek]

I believe I made it more concise without sacrificing too much of the explanation.

[hemanth]

And...?

[sjsyrek]

Is this comment directed at me? I updated my pull request almost a week ago..?

[sjsyrek]

I think the "giant wall of text" issue could be resolved with a strategic newline. Also, if you think it's confusing, can you at least clarify what exactly is confusing? Writing concise definitions for these things is not easy, and I'm sure there are things that are going to be confusing, but specifics would help with shaping the language.

As far as the monoid thing is concerned, what's illuminating for newcomers certainly has a subjective element to it. I think that any newcomer to FP is going to have to understand basics first. You wouldn't go straight to monad, for example. Likewise, you should know functor before applicative and knowing both functor and monoid does help in understanding applicative. Otherwise, your definition is either going to be too technical (in its terseness) or misleading, like the current definition. I think it pays to be honest about these concepts and tell people "you need to understand x before you will understand y". That's how I learned them, myself, to the extent that I have learned them. Also, I doubt we're going to be anyone's first port of call for this information. So I agree about brevity, but I don't agree that we should treat these concepts in isolation from one another, because they aren't actually isolated and it's just going to be worse for any beginner down the line to think that they are.

Your remark about monoids in the category of endofunctors implies that my definition is equally abstruse and abstract. Do you really think so? Or are you just being sarcastic?

[hemanth]

Finally?

[hemanth]

What was the final decision on this?