The author doesn't mention laziness, which is pretty huge. Laziness is half of immutable data structures!
I have a tidbit in the first paragraphs: http://blog.vmchale.com/article/effects
How side effects work in FP
41–50 of 107 posts
Re: How side effects work in FP
#42Oh, haven't seen a monad article in quite some time. > Monads really are just a convenient way to build up action values Except when they aren't, because lists/arrays (with map) and Maybe (with map) and .. are something totally different. And that's the problem with _all_ these monad tutorials/how-tos/...: the problem is, that monads (and functors) are not burritos or elephants but _both_. So they are hard to underst…
A bunch of those mentioned don't address laziness and how the IO monad deals with it: http://blog.vmchale.com/article/effects
Re: How side effects work in FP
#43"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...
There is a reason for this, and it's not that Haskell is jumping through hoops unnecessarily. All those languages are strictly evaluated, which means that side effects are clearly localized in time and space, we know when and where they happen if we run the program. Haskell is lazy, and laziness doesn't go well together with ad-hoc side effects. Haskell evaluates expressions when the result is needed, and an expressi…
> the result would be something like unsafePerformIO in current Haskell, where it's hard work to ensure that it's used correctly.
Not really, unsafePerformIO has its place - just its not in typical Haskell programs.
Re: How side effects work in FP
#44Oh, haven't seen a monad article in quite some time. > Monads really are just a convenient way to build up action values Except when they aren't, because lists/arrays (with map) and Maybe (with map) and .. are something totally different. And that's the problem with _all_ these monad tutorials/how-tos/...: the problem is, that monads (and functors) are not burritos or elephants but _both_. So they are hard to underst…
A bunch of those mentioned don't address laziness and how the IO monad deals with it: http://blog.vmchale.com/article/effects
Actually the most important part of monads in Haskell is the do-notation. Without that, monadic code would look like JS' callback hell (although composition of monads using monad transformers/monad stacks isn't much better).
Haskell without laziness is Purescript, btw.
Re: How side effects work in FP
#45As 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…
> Ultimately, that's very similar to what old-school ways of declaring Promises do in Javascript.
Yes, and monadic code suffers from the same problem, that's why Haskell has do-notation
do
b bind(fun1, (a) => bind(fun2, (b) => pure(b)))Re: How side effects work in FP
#46I don't speak Rust well, but I can share my perspective from Clojure, where I tend to think in data. A program is a sequence of immutable functions taking input from the world and reducing that to instructions to mutate the world (aka side effects). The world here can also be some place that stores state. Ideally mutation is the last step of the pipeline, which takes the instructions and produces the side effects. Or…
> immutable functions
That doesn't sound right.
Re: How side effects work in FP
#47I don't speak Rust well, but I can share my perspective from Clojure, where I tend to think in data. A program is a sequence of immutable functions taking input from the world and reducing that to instructions to mutate the world (aka side effects). The world here can also be some place that stores state. Ideally mutation is the last step of the pipeline, which takes the instructions and produces the side effects. Or…
That model fits functional reasoning. It doesn’t fit all programs, though, as it doesn’t allow the input to depend on the _execution_ of the mutation instructions. Example: input “I step forward”, output “monster appears”, next input “I try to shoot it”. That second input wouldn’t be there if the output weren’t executed.
You missed the point where a program can take inputs over time. In your example, the program takes “step forward” and goes through the flows, eventually mutating state at the end, including redrawing the screen or prompting the user for their next input. The next input is based on the current state of the machine, and there can be as many or few valid state transitions as you, the programmer, would like to manage.
Re: How side effects work in FP
#48FP explanations like this annoy me:
That is, this code:
x = foo()
y = bar(x)
z = bar(x)
Should mean the same thing as:
y = bar(foo())
z = bar(foo())
Because it's obvious to anyone that has written any sort of complex program that those are not the same thing. foo() can be an expensive operation like an HTTP call. Or it might depend on a database which can change state underneath it.
I assume FP has answers for these things but the tutorials never cover them. They all imagine a world without state or expensive operations to show how wonderful it is. And that's an easy world to program in.
Re: How side effects work in FP
#49FP explanations like this annoy me: That is, this code: x = foo() y = bar(x) z = bar(x) Should mean the same thing as: y = bar(foo()) z = bar(foo()) Because it's obvious to anyone that has written any sort of complex program that those are not the same thing. foo() can be an expensive operation like an HTTP call. Or it might depend on a database which can change state underneath it. I assume FP has answers for these…
No post body was provided.
Re: How side effects work in FP
#50Earlier quoted context omitted.
There is a reason for this, and it's not that Haskell is jumping through hoops unnecessarily. All those languages are strictly evaluated, which means that side effects are clearly localized in time and space, we know when and where they happen if we run the program. Haskell is lazy, and laziness doesn't go well together with ad-hoc side effects. Haskell evaluates expressions when the result is needed, and an expressi…
This sort of thing is where I detach from the idea that functional programming is the ultimate good as some advocates would push it: it's far too obvious that outside of narrow constraints, real hardware just isn't functional. No where was this more apparent in my career then when I was on a team of Scala-using FP programmers who were building part of a real hardware provisioning system (and the org structure tipped…
> FP is terrible at logging
Um, what? You can't just drop this without elaborating. I've never seen anybody have problems logging in a functional language.