3 ms·

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

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.

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.