3 ms·

I'd like to argue from a Haskell backend perspective that monad transformers deserve exactly the complexity they expose. They give you a handle to factor side e

by tel 12y ago

I'd like to argue from a Haskell backend perspective that monad transformers deserve exactly the complexity they expose. They give you a handle to factor side effects in sensible ways and to express that code requires exactly some set of effects and no others. It is not always clear how to factor code which does not have this rigor into effect-typed form. It can be extraordinarily difficult to recognize what effects are being carried out in which parts of code at first—especially if you haven't been forced into the discipline early. Thus, I find it unsurprising that you feel the translation effort is challenging. But, coming from the other angle—building things with well-defined effect typing from day zero and composing pieces atop one another to reach your final complexity goal—works exceedingly well. Better, it forms a design which can be translated to untyped settings and retain its nice composition properties. Which is to say not much more than: there is some logic to all that madness and once you're on the "other side" it's hard to judge these "incredibly complex type idioms" as anything other than useful and nearly necessary for sane code reasoning. I miss transformer stacks a lot when using other languages.

slashnull 12y ago
... said the monk, sitting cross-legged with an air of zen inner peace ; ) I think it all boils down to considerations of idealism vs. realism, in the end, and yes, I have to admit, I managed to get a sort of big picture understanding of Yesod and its ORM, and it's definitely a cool design. Can't say I know as much about Happstack, but the hello worlds were smaller. And the authors didn't have to invent two dependency management tools to get it to compile... /off-topic I actually used something akin to monads to write a quick and dirty parser combinator library... In PHP! It was really fun, but I have to admit that it got really hard to keep track of what was function, what was return, what was supposed to be passed along to the next function and so on without any real typing. For the first time I... I wanted monads. But still, I have 99 problems and I'd say 97 of them are undefined, nulls, erroneous typecasts, unexpected layers of wrapping, and so on. I wrote bad code, my teammates did, and here we are. I want to get rid of those so that I can, at last, have real problems. Then I'll port my REST server in Haskell ; )
- tel 12y ago
  I'm not a big user of Yesod, so I can't speak too much to that, though it is notoriously difficult to get Yesod to compile unless you use Stackage. I would say that types are really difficult to do in your head. It's tedious and error-prone. That said, the advantages are high so it's valuable, e.g. your parser combinators in PHP. Parser combinators are actually a great example of where monad transformers shine. You can see them as nothing more than a stack of `State` atop `Maybe` which dramatically simplifies the presentation and why they work. Better, you can rip out `Maybe` and replace it with `[]` to get non-deterministic parsers "for free"—all of the code remains the same. I actually happened to write up about this recently: https://gist.github.com/tel/df3fa3df530f593646a0 But yeah, gradual typing is seductive for existing codebases. You can just make the jump and beat them with hammers of frustration until the compiler gives you a thumbs up---but it's nobody's cup of tea. If you want discipline, you are far better off setting the rules from t=0 and going from there. Let me know when you start porting to Haskell. That'll be an exciting time.

by tel 12y ago

slashnull 12y ago

... said the monk, sitting cross-legged with an air of zen inner peace ; ) I think it all boils down to considerations of idealism vs. realism, in the end, and yes, I have to admit, I managed to get a sort of big picture understanding of Yesod and its ORM, and it's definitely a cool design. Can't say I know as much about Happstack, but the hello worlds were smaller. And the authors didn't have to invent two dependency management tools to get it to compile... /off-topic I actually used something akin to monads to write a quick and dirty parser combinator library... In PHP! It was really fun, but I have to admit that it got really hard to keep track of what was function, what was return, what was supposed to be passed along to the next function and so on without any real typing. For the first time I... I wanted monads. But still, I have 99 problems and I'd say 97 of them are undefined, nulls, erroneous typecasts, unexpected layers of wrapping, and so on. I wrote bad code, my teammates did, and here we are. I want to get rid of those so that I can, at last, have real problems. Then I'll port my REST server in Haskell ; )

tel 12y ago
I'm not a big user of Yesod, so I can't speak too much to that, though it is notoriously difficult to get Yesod to compile unless you use Stackage. I would say that types are really difficult to do in your head. It's tedious and error-prone. That said, the advantages are high so it's valuable, e.g. your parser combinators in PHP. Parser combinators are actually a great example of where monad transformers shine. You can see them as nothing more than a stack of `State` atop `Maybe` which dramatically simplifies the presentation and why they work. Better, you can rip out `Maybe` and replace it with `[]` to get non-deterministic parsers "for free"—all of the code remains the same. I actually happened to write up about this recently: https://gist.github.com/tel/df3fa3df530f593646a0 But yeah, gradual typing is seductive for existing codebases. You can just make the jump and beat them with hammers of frustration until the compiler gives you a thumbs up---but it's nobody's cup of tea. If you want discipline, you are far better off setting the rules from t=0 and going from there. Let me know when you start porting to Haskell. That'll be an exciting time.