3 ms·

The problem with making effects explicit is that effects pollute: a callee doing IO means that all is callers also acquire the IO effect. Which is as it should

The problem with making effects explicit is that effects pollute: a callee doing IO means that all is callers also acquire the IO effect. Which is as it should be, except that this makes code modifications tedious if effects have to be explicitly mentioned. Haskell makes it harder still by using completely different syntax for monadic and pure code which means that introducing an effect in a callee requires rewriting the caller.

catnaroek 10y ago
Local effects are possible, e.g., algebraic effects (until a handler is reached) and local imperative state (ST). Your second complaint is valid, of course.
ubernostrum 10y ago
Haskell : side effects :: Java : exceptions
klodolph 10y ago
This is not a problem in practice, having worked on decent size (10s of kloc, so not huge) Haskell projects. It just doesn't really come up. You end up with the outer bits of your program written in some monad, and then smaller, self-contained modules will be pure. So if you need to rewrite some pure code and have it use IO, it's usually called from a place that already uses IO to begin with. You might compare it to checked exceptions in Java, which are actually a total pain in the butt in practice. Even if you did need to "rewrite" the caller—which is rare, as I mentioned—the change is usually pretty trivial. You might change the type and stick an fmap, <$> <*>, liftM2 or whatever in the caller, but it won't be a big deal.
- continuational 10y ago
  I've run into the problem when writing an interpreter. If you're not already using a monad, you basically need to change every line of code in the program. Trivial perhaps, but quite tedious. That said, you learn to predict where monads will be needed over time, and it's absolutely worth it to be able to use the type system to reason about side effects.
- deleted 10y ago
  [deleted]
- preordained 10y ago
  Agreed. That's not where I felt pain...it's swerving in and out of pure/impure/different monads code when I really just want to speak my logic outright, without threading it through the type system with a pipe cleaner. I always loved pure Haskell code like I'd use if I was solving project Euler problems or other toy logic things...but when I had to go into a monad with the lifts and *M methods and do notation...felt like tramping around in a suit of armor. Not to mention hideous type signatures a mile long, that you sweep under the rug with type synonyms. I grinned and bore it for a while in the name of "purity", but it sucked. I guess my point is just to add some counterweight to this myth that once you grok pure FP you never come back to the "dirty" old world...and also to give some color to the particular pain points that arose. Haskell, I think exposes both a lot of the potential in pure FP, and several pitfalls.
  - klodolph 10y ago
    The "suit of armor" may be an apt metaphor, clumsy but safe. I personally haven't had problems with long type signatures in my code. Typically, they'll disappear when you define the right monad for your application. But I don't have much experience solving "toy" problems in Haskell, I've leaned more towards production code, so my experiences are different. That's one of the main problems with Haskell—so many people learn it to get better at programming rather than to use it in earnest, write blog posts about monads, and solve toy problems like Project Euler. Like other languages, it takes a different form when you're managing larger projects. Just my 2¢.
  - marcosdumay 10y ago
    Haskell does force an organization into your code¹. If you try to write it in a way that the language does not "like", you will suffer. The logic you want to speak is probably not suitable for expression in Haskell, but there is very probably an equivalent logic that is suitable. Haskell forces you into specializing your code into pure and impure parts. You can go deep on any of those, and use one to interpret the other, but mixing them is bad. 1 - One of the many, many features that I do consider misfeatures on other languages, but in Haskell it interacts well with the rest of the language and becomes empowering.

catnaroek 10y ago

Local effects are possible, e.g., algebraic effects (until a handler is reached) and local imperative state (ST). Your second complaint is valid, of course.

ubernostrum 10y ago

Haskell : side effects :: Java : exceptions

klodolph 10y ago

This is not a problem in practice, having worked on decent size (10s of kloc, so not huge) Haskell projects. It just doesn't really come up. You end up with the outer bits of your program written in some monad, and then smaller, self-contained modules will be pure. So if you need to rewrite some pure code and have it use IO, it's usually called from a place that already uses IO to begin with. You might compare it to checked exceptions in Java, which are actually a total pain in the butt in practice. Even if you did need to "rewrite" the caller—which is rare, as I mentioned—the change is usually pretty trivial. You might change the type and stick an fmap, <$> <*>, liftM2 or whatever in the caller, but it won't be a big deal.

continuational 10y ago
I've run into the problem when writing an interpreter. If you're not already using a monad, you basically need to change every line of code in the program. Trivial perhaps, but quite tedious. That said, you learn to predict where monads will be needed over time, and it's absolutely worth it to be able to use the type system to reason about side effects.
deleted 10y ago
[deleted]
preordained 10y ago
Agreed. That's not where I felt pain...it's swerving in and out of pure/impure/different monads code when I really just want to speak my logic outright, without threading it through the type system with a pipe cleaner. I always loved pure Haskell code like I'd use if I was solving project Euler problems or other toy logic things...but when I had to go into a monad with the lifts and *M methods and do notation...felt like tramping around in a suit of armor. Not to mention hideous type signatures a mile long, that you sweep under the rug with type synonyms. I grinned and bore it for a while in the name of "purity", but it sucked. I guess my point is just to add some counterweight to this myth that once you grok pure FP you never come back to the "dirty" old world...and also to give some color to the particular pain points that arose. Haskell, I think exposes both a lot of the potential in pure FP, and several pitfalls.
- klodolph 10y ago
  The "suit of armor" may be an apt metaphor, clumsy but safe. I personally haven't had problems with long type signatures in my code. Typically, they'll disappear when you define the right monad for your application. But I don't have much experience solving "toy" problems in Haskell, I've leaned more towards production code, so my experiences are different. That's one of the main problems with Haskell—so many people learn it to get better at programming rather than to use it in earnest, write blog posts about monads, and solve toy problems like Project Euler. Like other languages, it takes a different form when you're managing larger projects. Just my 2¢.
- marcosdumay 10y ago
  Haskell does force an organization into your code¹. If you try to write it in a way that the language does not "like", you will suffer. The logic you want to speak is probably not suitable for expression in Haskell, but there is very probably an equivalent logic that is suitable. Haskell forces you into specializing your code into pure and impure parts. You can go deep on any of those, and use one to interpret the other, but mixing them is bad. 1 - One of the many, many features that I do consider misfeatures on other languages, but in Haskell it interacts well with the rest of the language and becomes empowering.