Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How side effects work in FP

chadnauseam.com

Post reply on HN
Print view View original

11–20 of 107 posts

Re: How side effects work in FP

#11

Post by kqr »

marcan_42 wrote: post #8

Well, that's the first time side effects in Haskell made sense to me. Well done. Not that I've ever seriously tried to learn Haskell, but in the past every time I've lazily come across an article about it it's always seemed like a bizarre confusing world, even though I know how functional programming (in the sense of purity) works. Now there's just one thing missing. We all know what this style of programming is. It'…

I think the problem is that people have learned the monad concept and then go overboard with it. Only monads are like async code with callbacks.

If people stuck to just explaining the IO monad specifically, which is a lot like async code with callbacks, then things would be better.

I wrote about this a few years ago: https://two-wrongs.com/the-what-are-monads-fallacy

Re: How side effects work in FP

#12

Post by hiptobecubic »

marcan_42 wrote: post #8

Well, that's the first time side effects in Haskell made sense to me. Well done. Not that I've ever seriously tried to learn Haskell, but in the past every time I've lazily come across an article about it it's always seemed like a bizarre confusing world, even though I know how functional programming (in the sense of purity) works. Now there's just one thing missing. We all know what this style of programming is. It'…

I disagree. I feel like this perspective makes sense to you because you feel more comfortable with js, not because monadic io is best explained in terms of callbacks.

Re: How side effects work in FP

#13

Post by frogulis »

marcan_42 wrote: post #8

Well, that's the first time side effects in Haskell made sense to me. Well done. Not that I've ever seriously tried to learn Haskell, but in the past every time I've lazily come across an article about it it's always seemed like a bizarre confusing world, even though I know how functional programming (in the sense of purity) works. Now there's just one thing missing. We all know what this style of programming is. It'…

While you may oversimplify a little, I think the core idea of your comment is pretty useful for learning. Unfortunately the first monads one encounters when learning Haskell are typically Maybe and IO. There are good practical reasons for this, but an early analogy to Async would probably make the idea a lot clearer.

Self-plug: I even wrote a short post about this quite recently, after making a similar comment on HN (https://frogulis.net/writing/async-monad)

Re: How side effects work in FP

#14

Post by kqr »

compressedgas wrote: post #7
arciini wrote: post #6

As someone who has never really understood monads (or tried that hard to) but who has done a good amount of Javascript programming, I really like the description of a monad as a series of nested data structures describing the next steps of a project. Ultimately, that's very similar to what old-school ways of declaring Promises do in Javascript. You're creating a data structure that you then attach a new function to e…

Not just similar. Promises are a monad. Though they don't strictly follow the monad laws as they are collapsing in JavaScript due to how Promise.resolve never allows a promise to resolve to a promise but only to the value of a promise.

I mean, as long as you have a flatMap/concatMap function JavaScript arrays are technically a monad too. But that is a practically meaningless thing to say.

What we talk about when we have about monads is the highly generic interface coupled with the highly generic combinators. This is not something shared by arrays and promises. In other words, none of them are monads in any practically meaningful sense.

Re: How side effects work in FP

#15

Post by dmitriid »

arciini wrote: post #6

As someone who has never really understood monads (or tried that hard to) but who has done a good amount of Javascript programming, I really like the description of a monad as a series of nested data structures describing the next steps of a project. Ultimately, that's very similar to what old-school ways of declaring Promises do in Javascript. You're creating a data structure that you then attach a new function to e…

There's "Functional Programming Jargon" which explains all these concepts in Javascript: https://github.com/hemanth/functional-programming-jargon

Re: How side effects work in FP

#16

Post by frogulis »

kqr wrote: post #11
marcan_42 wrote: post #8

Well, that's the first time side effects in Haskell made sense to me. Well done. Not that I've ever seriously tried to learn Haskell, but in the past every time I've lazily come across an article about it it's always seemed like a bizarre confusing world, even though I know how functional programming (in the sense of purity) works. Now there's just one thing missing. We all know what this style of programming is. It'…

I think the problem is that people have learned the monad concept and then go overboard with it. Only monads are like async code with callbacks. If people stuck to just explaining the IO monad specifically, which is a lot like async code with callbacks, then things would be better. I wrote about this a few years ago: https://two-wrongs.com/the-what-are-monads-fallacy

I like the analogy with musical instruments. Very practical.

I think you're right in saying that async is not representative of all monads, but it does help with questions that many beginners have, like "How do I get the value out of the maybe/IO/your-monad-here?"

Re: How side effects work in FP

#18

Post by pjmlp »

dmitriid wrote: post #17

"How to do side effects in s/FP/Haskell" Erlang is a functional programming language and doesn't need to jump through hoops to do side effects. So is OCaml. So is...

Somehow there is this school of thought that FP === Mirada/Haskell, go figure.

Re: How side effects work in FP

#19

Post by kqr »

frogulis wrote: post #16
kqr wrote: post #11

Earlier quoted context omitted.

I think the problem is that people have learned the monad concept and then go overboard with it. Only monads are like async code with callbacks. If people stuck to just explaining the IO monad specifically, which is a lot like async code with callbacks, then things would be better. I wrote about this a few years ago: https://two-wrongs.com/the-what-are-monads-fallacy

I like the analogy with musical instruments. Very practical. I think you're right in saying that async is not representative of all monads, but it does help with questions that many beginners have, like "How do I get the value out of the maybe/IO/your-monad-here?"

I don't think it generalises that well, unfortunately. How to get the value out of Maybe is "just pattern match it". There's nothing process-like about it at all -- it's just a plain container/wrapper.

The async analogy works for some monads like ST and IO and whathaveyou but it's not generally useful, due to the wide variety of types that are monads.

Re: How side effects work in FP

#20

Post by olliej »

Something that I always found funny is that main clearly has to take something as input (otherwise it would not be able to produce different output between runs). So in GHC the main method (main :: IO()) internally takes a value of type RealWorld (theRealWorld) and returns the new RealWorld produced by running the program. I imagine by the time it's lowered to actual assembly they've dropped that, but I've never dealt with ghc's machine codegen
Post reply on HN