Hacker News Reader

Comment by tathougies | Hacker News Reader

Hmm... Javascript pervasively uses monads, in the form of promises and the await/async keywords, but it is a strict language.

View on HN

If we wanted to be picky, promises technically aren't monads because .then() does too much with auto unwrapping nested promises.

https://stackoverflow.com/a/50173415 has some good examples.

It's close, though. Really close. And don't get me wrong - I still love promises and async / await. They're much better than what we had before.

That post is misguided for so many reasons. In order to say something 'forms a monad', you need to define over what operations. That poster assumes Promise forms a monad using regular javascript function composition as the function composition operator. This is stated without justification, and there are other notions of javascript function composition which would preserve the functor composition law.

More clearly, Promise indeed forms a functor, if the domain is the set of Javascript functions which do not return 'Promise<X>'.

That means they do meaningless unnecessary wrapping too. It is even more ridiculous for a weak-typed language.

The only point of a Monad is that in a lazy language it desugars into an implicit nested functions, which guarantees the order of evaluation.

The monadic code, then, could be generalized over >>=, >> and return, and given that, specialized instances of a Monad class could be made, like Maybe, ST and what not.

The only meaning in performing these steps is to establish a guaranteed order of evaluation (via implicit nesting of functions) for serialized abstractions.

But that is ok, most of Javascript coders never studied CS fundamentals or comparative PL.

So you think there's a construct that allows you to do what Promises do that are simpler and do not form a monad?

Please, do tell.

> But that is ok, most of Javascript coders never studied CS fundamentals or comparative PL.

Can you explain what you mean by this? You seem to be under the impression that javascript the language did something extra to make Promises form a monad when in reality, the very idea of a Promise forms a monad to begin with, independent of any particular implementation in javascript.

> The only point of a Monad is that in a lazy language it desugars into an implicit nested functions, which guarantees the order of evaluation.

That is not true at all. You seem to confuse side-effect-free with lazy and the state monad with any monad. Monad instances like options or either data types allow for the simple composition of functions that yield them. In any language. Promises form a useful monad because there is no other way to talk about values that have not been evaluated yet.

> there is no other way to talk about values that have not been evaluated yet.

There is a way, and it is known since at least R5RS.

https://www.gnu.org/software/mit-scheme/documentation/mit-sc...

It's really funny to see someone complaining about the lack of CS fundamentals in other people but does not know the difference between a weakly typed language and a dynamic one. :-D

To recapitulate some basics: JS is a strongly typed dynamic language.

> JS is a strongly typed

Strongly typed implies no implicit coersions at runtime. Python is strongly typed. JS or PHP are weakly typed.

That's wrong.

What's about this Python code:

  1.0 + 1

Or this Scala Code:

  "1".toFloat + "1".toInt

In both cases that's clearly implicit type coercion at runtime.

So according to the above constraint there would hardly be any strongly typed languages… (But quite the opposite is true in fact).

Weakly typed means you can hose the type-system somehow and then perform some "illegal" or completely nonsensical operation. For example that's easy in C, but not possible in JS. In a strongly typed language any value has some precise type at any time. This is true for JS so it's strongly typed.

Reply on news.ycombinator.com