Stop saying "the ___ monad"

2,280 views
Skip to first unread message

Evan Czaplicki

unread,
May 2, 2014, 4:35:51 PM5/2/14
to elm-d...@googlegroups.com
I really don't want to call things the ___ monad! (e.g. the IO monad, the state monad, etc.)

Haskell people (including me) always say things like, "To print things out you need to use the IO monad." This is like saying, "To add numbers you need to use the Addition Group."

It's just really weird to describe the algebraic properties of the thing in it's name. It also focuses on characteristics you don't need to fully appreciate to be able to use and understand the particular instance. You don't need to understand group theory or field theory to do addition and multiplication, and this is a good thing! Group theory deepens that understanding, but it is non-essential to being able to do basic math.

In both these cases, we made something simple sound magical and complex. I want Elm people to say "To print things out, use the IO library" and to make it parallel "To add numbers, use addition."

Evan Czaplicki

unread,
May 2, 2014, 4:42:02 PM5/2/14
to elm-d...@googlegroups.com
Also, we talked about a new API for the HTTP library a while ago. If someone asks, "what is this Http a thing?" the answer is not "a Monad"! This is like answering "what is this Maybe thing?" with "a Monad"!

Both are data structures and I think we, as a community, should be very clear about that. An (Http a) value is data structure representing an effect we'd like to perform at some point. I think the easiest name is an Explicit Effects, so please try to use terms like this!

If people are into learning about the algebraic properties of particular data structures, or common usage patterns of certain data structures, that's great. But I don't want to be forcing this on people if they just want to get something done (like add two numbers).

John Mayer

unread,
May 2, 2014, 4:59:46 PM5/2/14
to elm-d...@googlegroups.com

Fair enough. It's important to have some solidarity in terminology, because as first adopters and early language writers, we have an amplified influence over the future of idiomatic Elm.

But sometimes I might want to be able to say that something "is monadic", if I felt that it's a major feature or focus of the library. My state library, for example, really isn't interesting except for the fact that it implements the Monad pattern. This particular library is actually quite clumsy to use if you don't use desugared-do-block style.

--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

John Nilsson

unread,
May 2, 2014, 5:05:23 PM5/2/14
to elm-d...@googlegroups.com
I've been thinking that this is an instance of a more general problem om conflating types and modules. F.ex. in OOP where inheritance usually implies subtyping you also get odd Is-A relationships that you might rather remain an implementation detail.

So maybe one approach to this problem is for a language to be very picky about how it expresses known properties about a module.

I find algebraic properties like monad or monoid particularily interesting because they are properties of the relationship between things not of the things as such or their types. 

Take fold, if you were to implement it such that you'd like to enforce a monoid relationship between the base case and the combining function. In Scala and Haskell you could say given an instance m: Monoid[T] fold = something m.zero ... m.append
But that's not very interesting, the real relationship should rather be expressed
fold zero append = something zero append where Monoid(zero,append)
That is the type Monoid is about the relationship between the zero and append values, not their type.

BR,
John


John Mayer

unread,
May 2, 2014, 5:13:03 PM5/2/14
to elm-d...@googlegroups.com

But the HTTP proposal is monadic. When we're talking about API design, I don't want to censor myself from mentioning "hey look, that type is monadic" just because some people are unfamiliar with why that might be evidence of good design.

And sometimes monads have nothing to do with effects. But they share a common, incredibly useful pattern of control flow. We can keep it out of the standard libs, but I very much doubt that we can purge monads from the public user libraries or the realm of lost discussion. And I don't think we should.

Raoul Duke

unread,
May 2, 2014, 5:16:47 PM5/2/14
to elm-discuss
> just because some people are unfamiliar with why that might be evidence of
> good design.

glad you said "might" :-)

Alexander Noriega

unread,
May 2, 2014, 5:18:09 PM5/2/14
to elm-d...@googlegroups.com
I strongly disagree!

I think the question is "what are you going to call SomeAbstraction?" is, and I think the answer is not one universally appropriate answer. That is, the answer is neither 1) "Don't call X a monad!" nor 2) "Call X a monad!".

Those two answers are blind guidelines/recommendations/rules. They are missing context, and time. 

The following is the situation I think you're referring to: Say Alice doesn't know about monads, and she comes and asks me "What is this SomeAbstraction thing?, I want to use it!", then if I answer "It's a Monad", my answer will be quite unhelpful, even if I then explain what monads are! Why? Because it is one instance of something general which Alice just found out about. 

In that situation, you are right.

But now consider this situation: Bob wrote a bunch of code years ago, and now I have to look at it and maintain it. I've no idea what any of it does. But the phrase "X and Y, and Z, are monads" (and the types, of course!) gives me so much information that I can make sense of a great deal of the codebase.

I've been in this last situation several times.

"X is a {insert kind of functor, i.e. applicative, monad, etc}" can be extremely useful and information-rich. It literally tells you, in a word, about a whole "interface" and capabilities something has (and doesn't).

Let's not set a universal rule against a word just because it can be used unwisely.

Conrad Parker

unread,
May 2, 2014, 5:57:43 PM5/2/14
to elm-d...@googlegroups.com
On 3 May 2014 07:18, Alexander Noriega <lambd...@gmail.com> wrote:
I strongly disagree!

I think the question is "what are you going to call SomeAbstraction?" is, and I think the answer is not one universally appropriate answer. That is, the answer is neither 1) "Don't call X a monad!" nor 2) "Call X a monad!".

Those two answers are blind guidelines/recommendations/rules. They are missing context, and time. 

The following is the situation I think you're referring to: Say Alice doesn't know about monads, and she comes and asks me "What is this SomeAbstraction thing?, I want to use it!", then if I answer "It's a Monad", my answer will be quite unhelpful, even if I then explain what monads are! Why? Because it is one instance of something general which Alice just found out about. 

In that situation, you are right.

But now consider this situation: Bob wrote a bunch of code years ago, and now I have to look at it and maintain it. I've no idea what any of it does. But the phrase "X and Y, and Z, are monads" (and the types, of course!) gives me so much information that I can make sense of a great deal of the codebase.

I've been in this last situation several times.

"X is a {insert kind of functor, i.e. applicative, monad, etc}" can be extremely useful and information-rich. It literally tells you, in a word, about a whole "interface" and capabilities something has (and doesn't).

Let's not set a universal rule against a word just because it can be used unwisely.


Yes, and I think Evan was mostly referring to the first case: ie. in any docs that would be read by new Elm users with no functional programming experience, and when talking to them, it's confusing to mention abstract relations on types.

I agree that it's useful to mention these in the docs, so maybe we could have a standard section that explains what each type implements. It can be lower down in the docs for a module, and it should be possible to write working code without reading it.

That section would be somewhere that the people who like these abstractions could dump their thoughts, and we could have a rule like "don't mention monads/monoids/functors etc" outside of this section.

It could include examples to justify its own existence, like "http implements monad, which allows you to write code like: ..."

Newbies could come back to this section twelve months later when they're working out how to simplify their code, and old hacks could skip the intro fluff and just read this section.

What would we call it: "Algebras on this type", "Implements", "Advanced use"?

Conrad.
 

On Friday, May 2, 2014 5:35:51 PM UTC-3, Evan wrote:
I really don't want to call things the ___ monad! (e.g. the IO monad, the state monad, etc.)

Haskell people (including me) always say things like, "To print things out you need to use the IO monad." This is like saying, "To add numbers you need to use the Addition Group."

It's just really weird to describe the algebraic properties of the thing in it's name. It also focuses on characteristics you don't need to fully appreciate to be able to use and understand the particular instance. You don't need to understand group theory or field theory to do addition and multiplication, and this is a good thing! Group theory deepens that understanding, but it is non-essential to being able to do basic math.

In both these cases, we made something simple sound magical and complex. I want Elm people to say "To print things out, use the IO library" and to make it parallel "To add numbers, use addition."

--

Max New

unread,
May 2, 2014, 6:38:08 PM5/2/14
to elm-d...@googlegroups.com
Sorry?

Max New

unread,
May 2, 2014, 6:38:53 PM5/2/14
to elm-d...@googlegroups.com
PRs welcome on the IO documentation.

John Mayer

unread,
May 2, 2014, 7:07:26 PM5/2/14
to elm-d...@googlegroups.com

Haha don't worry it was me too with my state monad package.

Evan, despite the position I took in my previous mails, I'm still giving serious consideration to what you're saying, and I do like your PR.

--

Evan Czaplicki

unread,
May 2, 2014, 8:03:40 PM5/2/14
to elm-d...@googlegroups.com
I think I wasn't so clear. I am going to try to clarify my position talking specifically about Group theory. I think people have built up tolerances and biases that are easier to see when you put things in another context.

Precise language: "___ is a group" vs. "the ___ group"

This is really about speaking precisely. To say "addition forms a group" is just a fact about addition. There are certain algebraic properties that are true about addition. This is cool if you'd like to parallelize something, so in the particular context of a general parallelization algorithm, it makes sense to bring up this algebraic property. You can write a better library if you account not just for addition, but for multiplication and whatever else. In that context, when we need a general solution, it is valuable to talk about the general algebraic property and its instances.

But to say "the addition group" is really really odd. It's implying there's an addition field? And an addition semi-group? People can usefully say the "additive group on integers" or the "multiplicative group on integers" but in those cases we are actually distinguishing between two specific groups that both apply to integers.

When to be general:

In the context of explaining addition, the fact that it is a group is not helpful. This only becomes interesting when we'd like to talk in a general way. Once you have 3-5 examples that you want to use interchangeably in a particular API, then it starts making sense to talk about things in a generic way. To understand a library for Result, State, IO, or Http, the shared patterns do not matter to a casual user. These are separate use cases. Put another way, to understand addition and multiplication, the shared patterns do not matter to the casual user.

So talking in a generic way is useful when you actually want to create something generic! A parallelization library for example.

I am going to make the claim that a monad is an algebraic pattern that is useful for reifying effects. That is, I want to say that it only makes sense to talk about monads if you are interested in talking about reified effects (i.e. explicit effects) in a general way. In my experience this applies only to do-notation, which Elm does not have.

I personally find that there is a very small amount of code that I write that really needs to be generic on effects in any other sense. Now that I think of it, I do get utility out of monad transformers, but I'd argue that that is a ridiculous name that we should avoid. Something like "Nested Effects" would be waaaay clearer. In that context, when we want to be general about which effects can be nested, it makes sense to talk about effects in a general way. Any effect can be nested inside this one, an effect has these algebraic properties, oh hey, State, IO, and Http can all be nested effects!

Summary:

Basically I am saying that we should be precise. If you have the urge to talk about monads, first ask yourself if this is a case in which being general is important. For any particular instance (addition, multiplication, state, io, http, etc.) I think being generic is adding unnecessary complexity and teaching in a bad way. But when it comes to a library for parallelization or nested effects, one must talk in a general way to create a good library.

Talking about algebra for library design:

I find that thinking about applicative vs monad is really helpful for a certain kind of library design. Specifically if you are designing ways to handle effects like FRP or pipes. In this context, it helps you get a nice API and carefully choose how much expressiveness you want. Library design is all about being meticulous about how to minimally express something and algebras are really helpful in this context, so that's fine. When you can't explain what you've done without the algebra you used to design it, then you have more work to do! The fact that something is a group does not mean you are a good teacher for just saying that and walking off.

OXO made it big in kitchenware because they thought hard about their design. They thought about ergonomics and usability. But if they said, you need to understand ergonomics to be able to use our kitchenware, they would fail. The genius of these products is that you don't have to know anything about ergonomics to know that this knife just feels really nice to use.

As a concrete example of library designers having a hard time because they did not know about monads, the clearest example is the Promises stuff that happened recently in JS. If you know about monads, designing that API is trivial. If not, you are reinventing a lot of stuff, probably in a messy way.

I think the big take away is, designing a library and presenting a library are very different things.

Alexander Noriega

unread,
May 2, 2014, 8:19:09 PM5/2/14
to elm-d...@googlegroups.com
Yes! This I entirely agree with. 

--Alexander

Eitan Chatav

unread,
May 2, 2014, 8:27:12 PM5/2/14
to elm-d...@googlegroups.com
Re: group theory. We do actually say things like "the dihedral group" or "the spin group". To say "addition group" is odd but only because addition of what? To say "the group of integers under addition" is not very odd at all. I'm not saying I disagree about whether or not something should be referred to as a monad. After all, why monad and not functor or type-constructor, or if it's a monad-plus, why not that? It's somewhat arbitrary and why concentrate on those particular operations and not others? At the same time I feel like there's a lot of talk about how scary it is to hear the word monad and that's why it shouldn't be used. Lots of words in programming are scary to me but I knew what a monad was before I started programming so that's not one of them :-)

Evan Czaplicki

unread,
May 2, 2014, 9:26:48 PM5/2/14
to elm-d...@googlegroups.com
Re: group theory. We do actually say things like "the dihedral group" or "the spin group".

I looked into both of these because I was not familiar. It appears that a Dihedral Group is a general designation, so reflecting a unit-square along the y-axis would form a Dihedral Group, as would rotation about the origin. Gotta say, I am a big fan of this group :P I don't really know what's up with the Spin Group, but if it is helping to be precise about exactly what you are talking about, it seems to still be in line with the argument made above. 
 
At the same time I feel like there's a lot of talk about how scary it is to hear the word monad and that's why it shouldn't be used. Lots of words in programming are scary to me but I knew what a monad was before I started programming so that's not one of them :-)

I'm not talking about scary vs. friendly. This is definitely motivated by the fact that many many people (including myself) struggle(d) to figure out what the hell was going on with monads, but the point is that even if we are going to say monad, we should do it in a way that is precise, meaningful, and helpful to the uninitiated. I don't want Elm to be a secret club in which the password is monad (no plebs allowed).

But I want to focus on a caricature of what you just expressed. "People have presented programming ideas in an inaccessible way before, so fuck it, we will too." I definitely don't mean to be critical of you or say that this is at all what you meant. I want to pick up on this because I think there is a certain sense of fatalism in Haskell. People just feel like "you're going to have a shitty time learning this, but hey, we all went through it and we like it now." It's hard, deal with it. I don't find that satisfying, and I don't want people to have that attitude in this community. So my goal in thinking about this is how to make it easy to learn and accessible. I really don't care what people call it as long as it's helping people understand what's going on.

I think the term is not used so precisely in the Haskell community because they pioneered what it was really useful for in programming. It's hard to get your terms precise when you are not sure yet. We have better info now and I think we can do better. It's also important to note that much of the charm of Haskell comes from the fact that it's got all sorts of crazy stuff in it that challenges you. Perhaps it could have been presented in a less mystical way, but then maybe some of the magic of Haskell would be gone and OCaml would have been a bigger deal.

Anyway, I hope this does not sound mean, I am totally reacting to cultural and marketing issues that have made things hard for Haskell's popularity and trying to make an argument about how we can present the same ideas in a way that invites people rather than alienates them.

Christopher Done

unread,
May 3, 2014, 5:38:49 AM5/3/14
to elm-d...@googlegroups.com
I like this! Very good insight. It's clear where our preoccupation with monads comes from. Many types we write specifically for the purpose of being a monad, we say "here's an Identity monad" or whatever. The fact that nobody says "the IO functor" or "the IO applicative"—it sounds strange—is enlightening. I'll adopt your proposal in my own expression. 

In fact, if someone had prominently pointed this out 15 years ago it might've saved developing this phraseology. Unfortunately it seems to have been spread, if anyone, by Wadler in his original Monads for functional programming paper: “This is called the identity monad: …” Back when that was all those types existed for.

John Nilsson

unread,
May 3, 2014, 7:49:20 AM5/3/14
to elm-d...@googlegroups.com
On Fri, May 2, 2014 at 10:42 PM, Evan Czaplicki <eva...@gmail.com> wrote:
algebraic properties of particular data structures

But this is precisely the problem, is it not? Data structures don't have algebraic properties, operations on those structures do. But people insist on describing the data structures as if they did.

It's a bit ironic that in category theory, where monads are borrowed from(?), one of the major features seems to be the focus on morphisms rather than objects.[1] Yet when expressed in programming languages the focus is shifted to the objects (types).


My (admittedly not expressed very clearly) point before was that a language, not only in the choice of wording in documentation, but in the choice of semantics and syntax, encourages a certain mindset. And the use of type classes in Haskell, and later in Scala to describe monads has encouraged the mindset that data structures such as List, or Http in this case, 'are' monads.

So Elm should maybe not adopt type classes as implemented in those languages if the aim is to discourage this mind set, and instead go for something which separate the property constraint (i.e. 'forms a monad') from the instance (i.e. the pair Http.onSuccess and the Http constructor) in a way that moves the focus from 'data structur is a' to the focus 'operations on datastructure forms a'.

BR,
John
 
 But languages like Haskell and Scala where it's possible to express such properties have syntax and semantics that makes it very easy to fall into the

John Nilsson

unread,
May 3, 2014, 7:51:04 AM5/3/14
to elm-d...@googlegroups.com
Ignore the last sentence, it was meant to be removed ;)

Christopher Done

unread,
May 3, 2014, 8:57:39 AM5/3/14
to elm-d...@googlegroups.com
On 3 May 2014 13:49, John Nilsson <jo...@milsson.nu> wrote:
> My (admittedly not expressed very clearly) point before was that a language,
> not only in the choice of wording in documentation, but in the choice of
> semantics and syntax, encourages a certain mindset. And the use of type
> classes in Haskell, and later in Scala to describe monads has encouraged the
> mindset that data structures such as List, or Http in this case, 'are'
> monads.

If there were true we'd see other instances of "the <type>
<property>". We don't. We don't even see "the IO functor" or "the Tree
comonad" or "the function arrow". We only see it, I believe, because a
good number of types have made for the sole purpose of exploiting
their monad properties, like Identity, State, Reader, ST, etc. which
was even the case in Wadler's paper. Monad is a special case.

John Nilsson

unread,
May 3, 2014, 10:45:11 AM5/3/14
to elm-d...@googlegroups.com
Well, I'm not saying it is wrong to talk about 'the' monad. It has be pointed out to me that there is only one way to define a monad involving the typical list data structure. In that case talking about 'the' list monad makes perfect sense.

What I'm saying is that this tends to encourage the thinking that the list data structure, or any module defining operation on it, 'is-a' monad.

That you can talk about 'the' monad though is, i guess, the background of why typeclasses are implemented as they are in that they are expected to be implicitly resolved, which is workable as long as there is only one possible instance, but starts to get hairy beyond that. The monoid example I had before is a good example, how, and why, do you implicitly resolve (0,+) over (1,*) as 'the' monoid instance in a context where you just want to make sure that what ever parameters forms a monoid? While you cold (in scala) just require def op[T](ts: Seq[T], arg:Monoid[T]) it feels kind of odd to package things in a datastructure (the monoid instance) just to prove their algebraic properties. So in practice APIs tend to either not enforce the property and just put it as documentation (def op[T](ts: Seq[T], zero: T, sum:(T,T)=>T)) or expect implicit resolution (def op[T:Monoid](ts:Seq[T])) while the latter style isn't very common for Monoids I think it's fairly common to see this mistake when it comes to Equality and Ordering

So my suggestion is to go with a hybrid (def op[T](ts: Seq[T], Monoid[T](zero, sum)) such that the semantics doesn't require the Monoid instance to be represented as an actual data structure, just as a type that spans the two arguments.

I guess scala would treat this as syntactic sugar for
def op[T,Z<:T,S<:(T,T)=>T](ts: Seq[T],  zero: Z, sum: S)(implicit ev: (Z,S) => Monoid[T,zero.type,sum.type)) or something such. Which in practice seems rather hard on both type inference and programmer. So not sure if it is feasible at all...

BR,
John


John Nilsson

unread,
May 3, 2014, 11:56:53 AM5/3/14
to elm-d...@googlegroups.com
Just realized that Scala syntax might be a bit opaque on an elm discussion list ;)

The last example represents the scala approach to this problem in which and implicit argument (resolved by the compiler) is supplied as evidence of the algebraic properties, but not necessarily used in the actual computation. Example: http://stackoverflow.com/questions/11450949/type-equality-in-scala

In this case (with the Monoid) such an evidence might take the form of an implication represented as a function from a narrow enough type to prove the assertion about the two arguments.

zero.type is Scala syntax for singleton types, types with exactly one value, so 0.type would be the type representing the value 0. Monoid(zero.type, sum.type) would be the type level assertion that the zero and sum indeed forms a monoid. So a (total) function returning that type would be proof that the arguments supplied to that functions proves that property.

BR,
John

Ben James

unread,
May 4, 2014, 5:20:42 AM5/4/14
to elm-d...@googlegroups.com
The point is not the reason why people use the terms like this; it's the effect it has on learners.

I'm not going to claim it definitely harms learning. But the phenomenon of learners cargo-culting "the <type> monad", in contexts where the monadic nature of <type> is irrelevant, is not hard to observe.

For example, here is a JavaScript library implementing a data structure called Maybe: https://github.com/chrissrogers/maybe

As far as I can see, the library does not implement anything resembling a monadic interface. There is no implementation of a bind operation. Yet, the README says, "This is the Maybe monad for JavaScript".

There will always be a tension between allowing some informal use of terminology when experienced users communicate with one another; and ensuring that the language seen by learners is helpful to them.

Sean Corfield

unread,
May 6, 2014, 7:32:22 PM5/6/14
to elm-d...@googlegroups.com
Coming late to this party: can I just say "hallelujah!"...?

Outside of the Haskell world, very few software engineers talk about "monads" at all. And I think this is part of why Haskell has never become as popular as it deserves to be: the terminology used in the Haskell community is (deliberately?) academic and - to the rest of the world - unnecessarily obtuse (or pedantic, depending on your point of view).

If you want Elm to be popular, you've got to stop using that sort of academic terminology, regardless of how "right" it may be. No one except Haskellers care in the least whether something is a monad or an applicative or any of those things. Except maybe the ScalaZ folks (who are basically Haskellers trying to turn Scala into a "mainstream" version of Haskell).

Sean
signature.asc

Sean Corfield

unread,
May 6, 2014, 8:49:02 PM5/6/14
to elm-d...@googlegroups.com
Calling my opinion out as "stupid shit" on Twitter is extremely unprofessional:


I have been very consistent in cautioning that if Elm wants to gain broad acceptance, it needs to present itself as less academic than Haskell - which is exactly what Evan was suggesting in this thread.

Sean
signature.asc

Quildreen Motta

unread,
May 6, 2014, 9:24:26 PM5/6/14
to elm-d...@googlegroups.com
You can replace Haskell with <programming language>, and "monads" with <interface that happens to be used in said programming language>, and you'll see why the conclusion don't follow from the premise. Terminology that happens to come from a field people are unfamiliar with tends to appear, well, "unfamiliar." But this doesn't mean that people should stop using this terminology, since they are meaningful inside of the contexts they are used.

For example, in the Java community, people use the word "Iterator" when they want to refer to the interface "Iterator," and its properties, and the word "List" (for example) when they want to refer to a data structure in particular (which happens to implement the previously mentioned interface). The same reasoning applies to the word "monad." There are cases where it's important to refer to the concept embodied by the interface, rather than a specific thing that happens to implement it, therefore a general "Stop saying the ___ monad" isn't actually helpful, as it's going from one blind usage of terminology from blindly avoiding the usage of said terminology altogether, even in the contexts where it is actually important to use them.

Evan Czaplicki

unread,
May 6, 2014, 10:49:20 PM5/6/14
to elm-d...@googlegroups.com
I don't exactly understand what's happening here. It appears that people are reacting to a misquote of the title of this thread? Even if you do the title right, the actual point I'm trying to make is not really clear until my third email. Just wanted to stress that because it does not seem that anyone in the recent emails disagrees substantially with the particular argument I made there.

In any case, I want this community to be a really friendly place where people of whatever level or background can share their ideas freely. I feel silly having to point this out, but I really respect Sean and think he's a great influence for this community. I think he's proved that many times on many different topics.

That does not even matter though. No matter who it is, we need to treat each other with respect, especially when we disagree. The fact that we have people with reasonably diverse backgrounds and opinions on this list is a huge boon to Elm.

I have more to say about tone and how to disagree with people in a constructive and fun way, but I've been crafting this email for too long! :P Just be nice! We've got bigger fish to fry than other FP people. 


Kim-Ee Yeoh

unread,
May 6, 2014, 11:15:25 PM5/6/14
to elm-d...@googlegroups.com

On Wed, May 7, 2014 at 9:49 AM, Evan Czaplicki <eva...@gmail.com> wrote:
That does not even matter though. No matter who it is, we need to treat each other with respect, especially when we disagree. The fact that we have people with reasonably diverse backgrounds and opinions on this list is a huge boon to Elm.

Leaving all this abstract math for a bit to borrow from high-energy physics, it seems like folks are doing intellectual scattering experiments in this forum:

"... an age-old technique of figuring out how stuff works: You poke it, throw stuff at it and smash it together. :D –  Lagerbaer Jan 27 '12 at 21:35"

But with so many brilliant particles -- I mean, ideas -- being launched at the same time, I can barely make sense of the discussion.

Anyway, back to your favorite programming on group and category theory ... ;)

-- Kim-Ee

Sean Corfield

unread,
May 6, 2014, 11:19:11 PM5/6/14
to elm-d...@googlegroups.com
On May 6, 2014, at 7:49 PM, Evan Czaplicki <eva...@gmail.com> wrote:
> Just be nice! We've got bigger fish to fry than other FP people.

Indeed. Apparently my teasing upset a couple of people here (and subsequently on Twitter for an hour or so!). m-sorry :)

I really had hoped that folks would realize that this was intended to be somewhat tongue in cheek:

"No one except Haskellers care in the least whether something is a monad or an applicative or any of those things. Except maybe the ScalaZ folks (who are basically Haskellers trying to turn Scala into a "mainstream" version of Haskell)."

Think of Bodil Stokke wandering around, clutching her rainbow My Little Pony, and wearing a T shirt that says:

"A MONAD IS JUST A MONOID IN THE CATEGORY OF ENDOFUNCTORS.
WHAT'S THE PROBLEM?"

I'm trying to find a link to that image of her from one of the conferences I was at, but all I found was this presentation...

http://slides.com/julientournay/a-monad-is-just-a-monoid-in-the-category-of-endofunctors-what-s-the-problem/

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)



signature.asc

Tomek Wiszniewski

unread,
Sep 8, 2015, 5:09:39 PM9/8/15
to Elm Discuss, se...@corfield.org
Hi folks,

as a JavaScript programmer without a degree in Computer Science I’m very glad this topic comes up! I’ve been “growing up” to Functional Programming, but I don’t have the theoretical background which many of you have up your sleeves. I’m really interested in what monads are, what problems they solve and how I can solve similar problems in a similar way – but I’m also a busy person who has no choice but care about getting things done in the first place.

Alright, enough babbling. As a newbie – from the “other side of the front” :) – I want to say three things:

1. Getting things done in Elm has been a great, painless pleasure for me! It seems like I’ve been using monads all along – but I haven’t needed that knowledge to get my things done so far.

2. To get a solid understanding of what I’m doing, I’m slowly learning Haskell in the meantime. Guess what – my favorite resource (learnyouahaskell.com) – manages to cover I/O in an understandable way before it gets into explaining monads. Like Evan said – throughout the course the author explains simple, specific applications (getting things done) before it goes on to explaining the general theory behind them. Bull’s eye, I’d say!

3. I’ve always learned through getting things done. That’s the fun way. That’s the way my baby son learns. Things we learn this way just naturally stay in our minds.

Evan, many thanks for bringing this up! Thumbs up, hallelujah and move on!
Reply all
Reply to author
Forward
This conversation is locked
You cannot reply and perform actions on locked conversations.
0 new messages