4 ms·
> having to use monads or effects for io Speaking as a Haskell programmer, this is not a problem. You put “IO” in the function signature and “do” in the body,
by klodolph 3y ago
> having to use monads or effects for io
Speaking as a Haskell programmer, this is not a problem. You put “IO” in the function signature and “do” in the body, and that’s workable. Or some other Monad. You get so many choices, which is its own problem, but “having to use monads” is not a problem in practice.
There are other problems that make Haskell hard to work with. This just happens to not be it.
- staunton 3y ago> There are other problems that make Haskell hard to work with. What are the biggest or most important ones in your opinion?
- DonaldPShimoda 3y agoI'm not who you asked but I think the clearest example is lazy evaluation. Anecdotally speaking as someone who's helped teach a few classes in Haskell, students often have problems with laziness until they really adapt to the functional paradigm, and even then continue to have some problems. The other common problem I see is not actually a Haskell problem but merely a problem Haskell exacerbates: many students fail to think through their types prior to starting an implementation. I frequently had students in office hours trying to force their way through a problem and when questioned about the types were unable to reason at the type level intuitively. I suspect this reflects larger problems in my university's undergraduate program, but I figured I'd comment on it anyway.
- tome 3y agoI can testify, to my embarrassment, to the same experience.
- voidhorse 3y agoSure, it was just an off the cuff example. And while I agree that monads are not horrible by any means I think you are oversimplifying a bit. Monad transformers, the mtl library, ect. all exist after all... Even if using monads is relatively painless I wouldn't say that it's easier than using a language that allows you to freely execute side effects wherever for programs that are highly interactive.
- xedrac 3y agoHaskell does let you freely execute side effects. It just asks you to label any function that does so. People get tripped up by it because it's different, but in practice, it's absolutely trivial.
- consilient 3y ago`IO` is all you need if you want to freely execute side effects wherever. `mtl` and friends are for when you want to restrict which effects are available where.
- c_crank 3y agoWould there be so many ineffective tutorials and bad analogies if having to use monads really wasn't a problem?
- ParetoOptimal 3y agoSurely people never overcomplicate simple things, right? :)
- empath75 3y agoWeirdly once i stopped trying to understand what a monad was, i had no problem using them.
- chongli 3y agoThe problem with monads is that they’re a term from abstract algebra. Haskell’s documentation talks about them from that perspective (including monad laws), which makes them quite natural for anyone who’s studied some abstract algebra in university. Unfortunately, most programmers trying to learn Haskell have not taken any abstract algebra courses, so these definitions and laws are deemed insufficient. Regular people want to know the exact nature of a thing — not just a list of mathematical properties that hold — and so they insist that there must be something more. But there’s nothing there!
- grumpyprole 3y agoThis is FUD. You don't need to have studied abstract algebra to understand the monad laws. Basic high school maths is more then sufficient. EDIT: Apologies, I missed the subtle point this post was making!
- tome 3y ago> This is FUD I think chongli is actually in agreement with you
- klodolph 3y agoThe reason that there are so many tutorials and analogies is because monads are relatively easy to understand, but unfamiliar, and they allow you to do a bunch of math (which you don’t have to do). Not hard enough to cause Haskell programmers any problems.