4 ms·

You don't have to introduce a state monad to increment a mutable variable in Haskell, you can do that with IORefs pretty much the same way you do it in OCaml. B

You don't have to introduce a state monad to increment a mutable variable in Haskell, you can do that with IORefs pretty much the same way you do it in OCaml. But in a multi-core environment you will eventually want a guaranteed STM.

sidkshatriya 5y ago
You are correct. However, IORefs are not idiomatic in "normal" Haskell. However, mutable variables are very much accepted in OCaml. Adding mutability to the mix via IORefs + Haskell's laziness by default means you don't _really_ know when a particular IORef mutation may really be executed. In OCaml, evaluation is eager and you know when it will happen. Even when you introduce bangs and special Haskell language extensions, fully removing laziness from your code in Haskell is difficult. TL;DR: Because of Haskell's laziness you are in some ways forced to be purely functional. OCaml allows you to embrace mutation in ways Haskell does not, in my view. > But in a multi-core environment you will eventually want a guaranteed STM. You actually may not always always want STMs. STMs are awesome but something more basic like locks may do the job. It can be more performant to use, say, a mutex. If STMs were superior on every parameter they would have taken over the world. They have not -- they are good in some scenarios and not so good in others...
- ghostwriter 5y ago
  > Even when you introduce bangs and special Haskell language extensions, fully removing laziness from your code in Haskell is difficult. Why would one prefer to fully remove laziness? > TL;DR: Because of Haskell's laziness you are in some ways forced to be purely functional. OCaml allows you to embrace mutation in ways Haskell does not, in my view. unless there's a strive to be more on the side of the Safe[1] language subset, Haskell can be told to embrace the same mutation property with a combination of `unsafePerformIO` and `seq`. People tend to avoid it because the language offers a tooling to achieve better mutation properties. Overall, my argument here is that OCaml's idiomatic approach to permissible mutations doesn't seem to be a competitive advantage when it comes to software development in general, but rather a flavour that imperative programmers prefer due to their familiarity with the concept. > You actually may not always always want STMs. Whenever there's a non-trivial retry policy, one should prefer to choose STM + queues over debugging adventures with Locks and Mutexes. Almost all of multithreaded software I can immediately think of have non-trivial retrying logic. [1] https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/safe_haskell.html https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/safe...
  - emmelaich 5y ago
    > Why would one prefer to fully remove laziness? Far from an Ocaml/Haskell expert, but is it that laziness makes resource use less predictable?
    - ghostwriter 5y ago
      Laziness on itself does not prevent one from properly evaluating resource utilisation. In fact, laziness helps in resource preservation. But what makes it less predictable is various optimisation techniques that come to aid the lazy environment: strictness analysis, rewrite rules, and stream fusion[1][2]. They may change significantly between compiler releases and affect the previously optimised codebase. [1] https://wiki.haskell.org/GHC_optimisations https://wiki.haskell.org/GHC_optimisations [2] https://markkarpov.com/tutorial/ghc-optimization-and-fusion.html https://markkarpov.com/tutorial/ghc-optimization-and-fusion....

sidkshatriya 5y ago

You are correct. However, IORefs are not idiomatic in "normal" Haskell. However, mutable variables are very much accepted in OCaml. Adding mutability to the mix via IORefs + Haskell's laziness by default means you don't _really_ know when a particular IORef mutation may really be executed. In OCaml, evaluation is eager and you know when it will happen. Even when you introduce bangs and special Haskell language extensions, fully removing laziness from your code in Haskell is difficult. TL;DR: Because of Haskell's laziness you are in some ways forced to be purely functional. OCaml allows you to embrace mutation in ways Haskell does not, in my view. > But in a multi-core environment you will eventually want a guaranteed STM. You actually may not always always want STMs. STMs are awesome but something more basic like locks may do the job. It can be more performant to use, say, a mutex. If STMs were superior on every parameter they would have taken over the world. They have not -- they are good in some scenarios and not so good in others...

ghostwriter 5y ago
> Even when you introduce bangs and special Haskell language extensions, fully removing laziness from your code in Haskell is difficult. Why would one prefer to fully remove laziness? > TL;DR: Because of Haskell's laziness you are in some ways forced to be purely functional. OCaml allows you to embrace mutation in ways Haskell does not, in my view. unless there's a strive to be more on the side of the Safe[1] language subset, Haskell can be told to embrace the same mutation property with a combination of `unsafePerformIO` and `seq`. People tend to avoid it because the language offers a tooling to achieve better mutation properties. Overall, my argument here is that OCaml's idiomatic approach to permissible mutations doesn't seem to be a competitive advantage when it comes to software development in general, but rather a flavour that imperative programmers prefer due to their familiarity with the concept. > You actually may not always always want STMs. Whenever there's a non-trivial retry policy, one should prefer to choose STM + queues over debugging adventures with Locks and Mutexes. Almost all of multithreaded software I can immediately think of have non-trivial retrying logic. [1] https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/safe_haskell.html https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/safe...
- emmelaich 5y ago
  > Why would one prefer to fully remove laziness? Far from an Ocaml/Haskell expert, but is it that laziness makes resource use less predictable?
  - ghostwriter 5y ago
    Laziness on itself does not prevent one from properly evaluating resource utilisation. In fact, laziness helps in resource preservation. But what makes it less predictable is various optimisation techniques that come to aid the lazy environment: strictness analysis, rewrite rules, and stream fusion[1][2]. They may change significantly between compiler releases and affect the previously optimised codebase. [1] https://wiki.haskell.org/GHC_optimisations https://wiki.haskell.org/GHC_optimisations [2] https://markkarpov.com/tutorial/ghc-optimization-and-fusion.html https://markkarpov.com/tutorial/ghc-optimization-and-fusion....