4 ms·

"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. S

"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...

pjmlp 5y ago
Somehow there is this school of thought that FP === Mirada/Haskell, go figure.
- chii 5y ago
  I guess they should describe FP as 'referentially transparent' or not. Haskell is referentially transparent, but you can't say the same for many other FP languages like erlang, or ocaml.
  - adrian_b 5y ago
    All the FP languages include a subset that is referentially transparent. I do not consider the attempts of making the entire language referentially transparent and the exclusive use of lazy evaluation, like in Haskell, as being useful. Obviously there are people who like these features and who use Haskell, but in any case whenever FP languages are mentioned they should not be reduced to those that have made the controversial Haskell choices.
    - chii 5y ago
      I do believe that monads are what made it possible to be referentially transparent not for just a subset, but the entire language. It's a good choice - it enforces equational reasoning, even for things like IO and "side effects". It is harder to write code like this, if you're not used to it, but i imagine that if you can, the code would be of higher quality.
- edgyquant 5y ago
  As someone who is just getting into FP I’d say Haskell was the most famous language I knew of before a month ago. Lisp might count but it isn’t widely known to be a functional language most people just think it’s a weird language.
  - pjmlp 5y ago
    Since you are only getting into FP, here is a list of languages that aren't FP when Haskell and Miranda are considered the only game in town. Lisp, Scheme, Common Lisp, Clojure, Raket, Caml Light, OCaml, Standard ML, F#, Scala, MLton, Concurrent ML among other lesser known ones.
kryptiskt 5y ago
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 expression that only side effects and doesn't return a value is never needed. You could finagle your way around that, but the result would be something like unsafePerformIO in current Haskell, where it's hard work to ensure that it's used correctly.
- XorNot 5y ago
  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 in their favor) - the number of arguments about the sheer amount of things which can and definitely would go bad across hundreds of servers when you tried to do things - versus their desire to ignore these problems as infrequent so they wouldn't have to try and code the handling in a functional way (FP is terrible at logging, so even getting that done adequately was an argument). Basically the paradigm does tend towards collapsing once the problem grows too complicated for someone to keep in their head because it actively fights the sort of procedural reasoning humans do pretty much natively in favor of dealing with abstract math which very few people are any good at.
  - travv0 5y ago
    > 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.
    - dmitriid 5y ago
      They probably mean Haskell. Note: I don't know Haskell, so below is speculation. To log you need IO. To get IO you need to provide it to the function that will do logging. And now your function has to be marked as doing IO. So now you need to thread all that IO through all your functions, and "turn you code into monadic code" (I think that's the term). Other languages (like Erlang) don't care, and you can log whenever you want. --- Flamewar off-topic: it looks like hardly anyone is doing any useful logging in Haskell, because if you search for "logging in Haskell" you end up in: - highly academic discussions on "logging actions" vs "logging of computations" - extremely convoluted solutions that turn even the simplest examples into a mess - a couple of libraries whose entire documentation is usually "believe me we're the shit", and if they do have examples, they are an impenetrable mess of custom types and ascii art For every other language it literally is `logger.info(something)`
lmm 5y ago
Even in OCaml, if your program depends on the sequencing of effects then representing this explicitly is valuable.
anchpop 5y ago
I'm a professional OCaml developer, so I definitely know and agree with you :p I still think Haskell is "more FP" than OCaml because it allows equational reasoning in more cases. I don't think it's a problem to describe the platonic ideal of functional programming, since even in OCaml the pattern I mentioned is useful (for example a very common OCaml pattern is using the let-monadic syntax to simulate do-notation when using LWT)

"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...

pjmlp 5y ago

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

chii 5y ago
I guess they should describe FP as 'referentially transparent' or not. Haskell is referentially transparent, but you can't say the same for many other FP languages like erlang, or ocaml.
- adrian_b 5y ago
  All the FP languages include a subset that is referentially transparent. I do not consider the attempts of making the entire language referentially transparent and the exclusive use of lazy evaluation, like in Haskell, as being useful. Obviously there are people who like these features and who use Haskell, but in any case whenever FP languages are mentioned they should not be reduced to those that have made the controversial Haskell choices.
  - chii 5y ago
    I do believe that monads are what made it possible to be referentially transparent not for just a subset, but the entire language. It's a good choice - it enforces equational reasoning, even for things like IO and "side effects". It is harder to write code like this, if you're not used to it, but i imagine that if you can, the code would be of higher quality.
edgyquant 5y ago
As someone who is just getting into FP I’d say Haskell was the most famous language I knew of before a month ago. Lisp might count but it isn’t widely known to be a functional language most people just think it’s a weird language.
- pjmlp 5y ago
  Since you are only getting into FP, here is a list of languages that aren't FP when Haskell and Miranda are considered the only game in town. Lisp, Scheme, Common Lisp, Clojure, Raket, Caml Light, OCaml, Standard ML, F#, Scala, MLton, Concurrent ML among other lesser known ones.

kryptiskt 5y ago

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 expression that only side effects and doesn't return a value is never needed. You could finagle your way around that, but the result would be something like unsafePerformIO in current Haskell, where it's hard work to ensure that it's used correctly.

XorNot 5y ago
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 in their favor) - the number of arguments about the sheer amount of things which can and definitely would go bad across hundreds of servers when you tried to do things - versus their desire to ignore these problems as infrequent so they wouldn't have to try and code the handling in a functional way (FP is terrible at logging, so even getting that done adequately was an argument). Basically the paradigm does tend towards collapsing once the problem grows too complicated for someone to keep in their head because it actively fights the sort of procedural reasoning humans do pretty much natively in favor of dealing with abstract math which very few people are any good at.
- travv0 5y ago
  > 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.
  - dmitriid 5y ago
    They probably mean Haskell. Note: I don't know Haskell, so below is speculation. To log you need IO. To get IO you need to provide it to the function that will do logging. And now your function has to be marked as doing IO. So now you need to thread all that IO through all your functions, and "turn you code into monadic code" (I think that's the term). Other languages (like Erlang) don't care, and you can log whenever you want. --- Flamewar off-topic: it looks like hardly anyone is doing any useful logging in Haskell, because if you search for "logging in Haskell" you end up in: - highly academic discussions on "logging actions" vs "logging of computations" - extremely convoluted solutions that turn even the simplest examples into a mess - a couple of libraries whose entire documentation is usually "believe me we're the shit", and if they do have examples, they are an impenetrable mess of custom types and ascii art For every other language it literally is `logger.info(something)`

lmm 5y ago

Even in OCaml, if your program depends on the sequencing of effects then representing this explicitly is valuable.

anchpop 5y ago

I'm a professional OCaml developer, so I definitely know and agree with you :p I still think Haskell is "more FP" than OCaml because it allows equational reasoning in more cases. I don't think it's a problem to describe the platonic ideal of functional programming, since even in OCaml the pattern I mentioned is useful (for example a very common OCaml pattern is using the let-monadic syntax to simulate do-notation when using LWT)