JavaScript Promises Discussion: Make Them Monadic? (2013)

That's fair, but these terms are leaking out to business analysts, project managers, product managers, and customers. They have no idea what we're talking about. My weak attempts at synonyms might be attackable, buy we're coming across as elite bullshitters. I'd love something that was more consumable for the common person.

> Basically, I want to stop alienating project managers, product managers, and customers with weird jargon.

The things you might need jargon for are things that they shouldn't have to concern themselves with. If you use more familiar words but arrange them in unfamiliar ways, you'll cause the same confusion as by using jargon, except someone might believe they understood when they really didn't.

If you feel like you need to refer to programming concepts when talking to non-technical people, you're doing it wrong. Instead of talking about "immutable"/"constant"/"fixed", say that you made changes to prevent data from being altered accidentally. That's something they care about, not how exactly you did it.

First, going straight to "How do I understand Monads?" is not a good idea. I remeber when this article showed up on the web, and I remember wishing it had been written before I started learning Haskell:

https://byorgey.wordpress.com/2009/01/12/abstraction-intuiti...

If you want to understand monads, start hacking and watch for patterns.

> But, just to be super honest -- and possibly completely wrong -- the terminology is really off-putting. At a glance it just feels super complex, academic and completely divorced from practical coding. I get vibes of enterprise java class hierarchies looking at this stuff.

Yeah, and here's my take on why it looks like that:

First, the terminology is all borrowed from mathematics, hence the academic tone. People can debate on the merits of this; I think it makes more sense when you're making tools for folks who are already familiar with the usual notation, but e.g. if you're not dealing with people who are already accustomed to the way physisicts talk about things, "p" is probably not the best variable name for momentum, traditional as it may be.

The authors of that document seem to have gone even farther in that direction than the Haskell folks -- Setoid? really? It's just fing equals! even Haskell calls it Eq. At least they kept Ord.

Also, the design looks to be basically transliterated from Haskell. There's been no attempt to adapt it to either javascript's strengths or its weaknesses. For example: Conceptually a monoid is a special case of a category, but it's fiddly to abstract out the commonalities in Haskell because of the way the type system works. In javascript you could basically collapse the two, with id == empty and concat == compose. You might still want a blurb in there somewhere about the differences; not every category is a valid monoid, but there's no reason to have a whole separate hierarchy with different method names. * The whole TypeRep thing they talk about is a complication that is unnecessary in Haskell; having methods that aren't attached to an extant value is just a non-issue, because the compiler can figure out which one you mean based on the types.

The libraries were designed around Haskell, and they lose something in translation. One of the things that kept in that thread was why not build some experience using these patterns before writing a spec? I tend to agree.

The other thing is that it is a big pile of abstractions. Even when working in Haskell, though I am more or less familiar with all of the type classes on that chart, I've only really had call to use 9 of them. Including Eq(Setoid) and Ord. The abstractions can definitely get to be a bit much.

There is some real use for this stuff; here's one I find kindof shiny:

https://apfelmus.nfshost.com/articles/monoid-fingertree.html

...but I would say these abstractions are as applicable to day to day programming as the rest of computer science -- no more and no less.

I'm with you on the complexity allergy thing. Lately I've been doing some stuff in elm[1], and the simplicity has been a wonderful breath of fresh air coming from Haskell. I might recommend it if you're curious about functional programming. Some of the same ideas are sprinkled throughout the libraries; every time you see a function called "andThen," there's a monad lurking there, but because elm doesn't have type classes, you won't find anything called Monad. The flip side is you end up writing more boilerplate than you would in a language that can abstract these things away.

[1]: http://elm-lang.org/

> But until it affects day to day dev work, there's a whole set of people that aren't going to give the slightest fuck.

That's a seriously toxic attitude to have.

People are using monads and other FP concepts daily to simplify "day to day dev work" (here's an example [0].) The fact that it's more or less mainstream to write off a concept because it sounds "academic" is worryingly anti-intellectual in a profession that is allegedly based in analytical thinking.

> Can anyone here give a concrete example of a real world problem that is more cleanly solved with these changes to the Promise spec?

There are some in the linked github thread (which had to be reposted repeatedly until people actually stopped and read them, btw.) It's about being able to write DRY code that abstracts over not only promises, but anything else that forms a monad, like arrays, optional values, and so on.

[0] https://github.com/facebook/Haxl

A promise can only be activated once. You still have to use callbacks for buttons and other things that can be activated more than once.