4 ms·

A monad, as thought of in programming, is really something that requires higher kinded types. The reason they are hard to explain in a language without HKT is

A monad, as thought of in programming, is really something that requires higher kinded types. The reason they are hard to explain in a language without HKT is the same reason why List[T] would be hard to explain in a language without generics. edit: The article is impressive. It's just it feels like a different thing to me to than what monads are in haskell. I guess it would have to be.

elwell 5y ago
I love your podcast.
- adamgordonbell 5y ago
  Thanks!
AzzieElbab 5y ago
agreed but still impressed by authors effort
- tessierashpool 5y ago
  yep. as the OP said: There is a reason why most monad tutorials use Haskell: without syntactic support, monads are pretty clunky to use. (You could probaby go further and say "without semantic support.")
mping 5y ago
You can have monads in clojure (eg: http://funcool.github.io/cats/latest/#monad http://funcool.github.io/cats/latest/#monad) but the problem I see is that they are infectious and kinda force you to use them everywhere. In other languages, it's more palatable because the compiler checks for types, and normally there is some sugar to make it easier on the eyes. Besides, I think monads are a bit off the clojure way, even if they happen to exist somehow (eg promesa and manifold libraries).
- goostavos 5y ago
  And without the compiler checking the types, they're nightmarish to use. It falls to pure human sweat to track if a variable holds a `thing` or a `Monad Thing`. In my humble experience, it leads to lots of tedious banging around in the REPL to track down where you made a mistake. This is especially painful while refactoring. I've given up on the monads in dynamic languages outside of really strict confined situations (validation for instance). I think it's ultimately a bit silly to do something like `StateT` in Clojure rather than just using an `atom` or whatever. What you lose in referential transparency and purity, you more than make up for in sanity over the long haul. The scales would tip if Clojure had stronger typing options, but for now, using the idiomatic stuff is the way to go. Although, spec could probably be used in a pinch, but it's kind've hot garbage compared to compiler checked types (imho!).
deleted 5y ago
[deleted]
platz 5y ago
It's not that monads "require" higher kinded types, it's that , like an interface, monads only start really "buying" their "cost" when there are _many_ different things that can be monads. Then the common abstraction of the monad can be used to interact with these things that all share this common property, in a unified way. Finally, higher kinded types is what makes the idea of _many_ different things that can be monads manageable for the programmer, because if the underlying thing that the monad represents keeps changing into different forms, it's very easy to loose track of what structure or concept it currently represents without the types to keep track of that for you.
- adamgordonbell 5y ago
  yeah, that's better put. The usefulness of it, to me, is how the bind/flatmap can be generic over type constructors, but type constructors aren't a clojure concept. It's a static typing thing. To have an interface for monads, you need to have HKT don't you? To declare the type of bind? It could be useful otherwise. It would just seem like a slightly different thing.
  - jerf 5y ago
    You can also theoretically go the completely opposite direction and use dynamic typing. You have the usual tradeoffs related to that, plus maybe a couple new wrinkles, but it can work.
  - fiddlerwoaroof 5y ago
    Someone once told me “continuations are isomorphic to monads” and I eventually realized that the best way to do something monad-like in JS was to write functions that take a callback as their last argument and then higher order functions that manage threading the callbacks around, occasionally transforming it to slot in impure behaviors. I really disagree with the notion “HKT are necessary for monads”, though: they’re necessary to statically check that your monadic code is correct, but asside from things that rely on return-type inference, you can just implement those type-checks as runtime checks (or leave them out entirely): if the architecture of side-effects in your app is arranged around monadic principles, you can write all the same generic transformations (and, in fact, designing your dynamically typed code this way can get you a good fraction of the correctness benefits of static typechecking)

elwell 5y ago

I love your podcast.

adamgordonbell 5y ago
Thanks!

AzzieElbab 5y ago

agreed but still impressed by authors effort

tessierashpool 5y ago
yep. as the OP said: There is a reason why most monad tutorials use Haskell: without syntactic support, monads are pretty clunky to use. (You could probaby go further and say "without semantic support.")

mping 5y ago

You can have monads in clojure (eg: http://funcool.github.io/cats/latest/#monad http://funcool.github.io/cats/latest/#monad) but the problem I see is that they are infectious and kinda force you to use them everywhere. In other languages, it's more palatable because the compiler checks for types, and normally there is some sugar to make it easier on the eyes. Besides, I think monads are a bit off the clojure way, even if they happen to exist somehow (eg promesa and manifold libraries).

goostavos 5y ago
And without the compiler checking the types, they're nightmarish to use. It falls to pure human sweat to track if a variable holds a `thing` or a `Monad Thing`. In my humble experience, it leads to lots of tedious banging around in the REPL to track down where you made a mistake. This is especially painful while refactoring. I've given up on the monads in dynamic languages outside of really strict confined situations (validation for instance). I think it's ultimately a bit silly to do something like `StateT` in Clojure rather than just using an `atom` or whatever. What you lose in referential transparency and purity, you more than make up for in sanity over the long haul. The scales would tip if Clojure had stronger typing options, but for now, using the idiomatic stuff is the way to go. Although, spec could probably be used in a pinch, but it's kind've hot garbage compared to compiler checked types (imho!).

deleted 5y ago

[deleted]

platz 5y ago

It's not that monads "require" higher kinded types, it's that , like an interface, monads only start really "buying" their "cost" when there are _many_ different things that can be monads. Then the common abstraction of the monad can be used to interact with these things that all share this common property, in a unified way. Finally, higher kinded types is what makes the idea of _many_ different things that can be monads manageable for the programmer, because if the underlying thing that the monad represents keeps changing into different forms, it's very easy to loose track of what structure or concept it currently represents without the types to keep track of that for you.

adamgordonbell 5y ago
yeah, that's better put. The usefulness of it, to me, is how the bind/flatmap can be generic over type constructors, but type constructors aren't a clojure concept. It's a static typing thing. To have an interface for monads, you need to have HKT don't you? To declare the type of bind? It could be useful otherwise. It would just seem like a slightly different thing.
- jerf 5y ago
  You can also theoretically go the completely opposite direction and use dynamic typing. You have the usual tradeoffs related to that, plus maybe a couple new wrinkles, but it can work.
- fiddlerwoaroof 5y ago
  Someone once told me “continuations are isomorphic to monads” and I eventually realized that the best way to do something monad-like in JS was to write functions that take a callback as their last argument and then higher order functions that manage threading the callbacks around, occasionally transforming it to slot in impure behaviors. I really disagree with the notion “HKT are necessary for monads”, though: they’re necessary to statically check that your monadic code is correct, but asside from things that rely on return-type inference, you can just implement those type-checks as runtime checks (or leave them out entirely): if the architecture of side-effects in your app is arranged around monadic principles, you can write all the same generic transformations (and, in fact, designing your dynamically typed code this way can get you a good fraction of the correctness benefits of static typechecking)