4 ms·

> A purely functional approach ala Haskell is not the only way. that wasn't the OP's argument though, the argument was that OCaml is somehow generally better f

> A purely functional approach ala Haskell is not the only way. that wasn't the OP's argument though, the argument was that OCaml is somehow generally better for engineers. > OCaml offers a pragmatic functional approach to programming. an evaluation of something as pragmatic depends purely on what one whishes to practice. There's no universally objective notion of pragmatism. > And now you are going to be able to have your OCaml code run in a truly parallel fashion on your multicore CPU. no, it won't be able to do that automatically. Your code will have to respect certain invariants to function properly, and you as a developer will have to enforce these invariants with the available tooling at hand. Haskell has purity, guaranteed STM, and `par` labels for that. OCaml doesn't have those and the existing codebases will have to eliminate their thread-unsafe public interfaces first. > When that happens you can track changes to state how are you planning to track state changes without purity?

sidkshatriya 5y ago
> > And now you are going to be able to have your OCaml code run in a truly parallel fashion on your multicore CPU. > no, it won't be able to do that automatically. [...] I was comparing it to the old situation in OCaml is that it was impossible to have threads that were executing pure OCaml code and were _not_ IO bound to execute truly parallely. That limitation is removed. To me it is pretty obvious that you will need to use things like atomics, thread safe data-structures, mutexes etc. to ensure your code runs properly in multicore OCaml. It was implicit in my response. But I should have been more explicit. > that wasn't the OP's argument though, the argument was that the OCaml is somehow generally better for engineers. Engineers tend to be pragmatic. OCaml is pragmatic. So in quick short form, OCaml may be better to solve a certain kind of problem than something that is more pure and abstract like Haskell. It was intended as an informal argument and not an argument in a court of law :-).
- youerbt 5y ago
  > pure and abstract Like math? Engineers would rather not use math? > It was intended as an informal argument Maybe. But at this point it just looks like a mean dig at Haskell. A better word would be opinionated. Haskell is opinionated, and that is fine. The biggest bait in this thread is using the term "engineers". It should rather be: people trained in imperative programming in mainstream imperative languages. Then it makes sense.
  - mook 5y ago
    > Like math? Engineers would rather not use math? Gosh yes engineers would rather not use math. If there are approximations that work well enough (and when incorrect goes the way that leads to buildings not falling down) engineers definitely like to use less math. For one thing, less math means less room to make mistakes, and often ugly but works well is better than elegant with a higher chance of failing due to people screwing up.
    - youerbt 5y ago
      > If there are approximations And approximations are not math all of the sudden? > definitely like to use less math Is your point that they would rather work less than more? Easier than harder? Cus that is not very relevant and applies to every kind of work. Or less math and more something else that you hand wave so hard it is not clear what it might be?
      - mook 5y ago
        >> If there are approximations > And approximations are not math all of the sudden? The context was Haskell versus OCaml, so yeah — Haskell is the more academic, pure math. Ocaml (in this context) is the more approximate, but more practical option for larger projects. In practice people use things like C and Python because spherical cows are close enough.
        youerbt 5y ago
        Ok, you are another person in this chain who decided to just drop "more practical" and call it a day. Why bother. It is especially funny in the thread about OCaml getting soon (2022 maybe) multicore support. Something this less practical ivory tower Haskell had before it was even cool.
        ernst_klim 5y ago
        Python still has GIL and it's definitely more practical and widely adopted.

sidkshatriya 5y ago

> > And now you are going to be able to have your OCaml code run in a truly parallel fashion on your multicore CPU. > no, it won't be able to do that automatically. [...] I was comparing it to the old situation in OCaml is that it was impossible to have threads that were executing pure OCaml code and were _not_ IO bound to execute truly parallely. That limitation is removed. To me it is pretty obvious that you will need to use things like atomics, thread safe data-structures, mutexes etc. to ensure your code runs properly in multicore OCaml. It was implicit in my response. But I should have been more explicit. > that wasn't the OP's argument though, the argument was that the OCaml is somehow generally better for engineers. Engineers tend to be pragmatic. OCaml is pragmatic. So in quick short form, OCaml may be better to solve a certain kind of problem than something that is more pure and abstract like Haskell. It was intended as an informal argument and not an argument in a court of law :-).

youerbt 5y ago
> pure and abstract Like math? Engineers would rather not use math? > It was intended as an informal argument Maybe. But at this point it just looks like a mean dig at Haskell. A better word would be opinionated. Haskell is opinionated, and that is fine. The biggest bait in this thread is using the term "engineers". It should rather be: people trained in imperative programming in mainstream imperative languages. Then it makes sense.
- mook 5y ago
  > Like math? Engineers would rather not use math? Gosh yes engineers would rather not use math. If there are approximations that work well enough (and when incorrect goes the way that leads to buildings not falling down) engineers definitely like to use less math. For one thing, less math means less room to make mistakes, and often ugly but works well is better than elegant with a higher chance of failing due to people screwing up.
  - youerbt 5y ago
    > If there are approximations And approximations are not math all of the sudden? > definitely like to use less math Is your point that they would rather work less than more? Easier than harder? Cus that is not very relevant and applies to every kind of work. Or less math and more something else that you hand wave so hard it is not clear what it might be?
    - mook 5y ago
      >> If there are approximations > And approximations are not math all of the sudden? The context was Haskell versus OCaml, so yeah — Haskell is the more academic, pure math. Ocaml (in this context) is the more approximate, but more practical option for larger projects. In practice people use things like C and Python because spherical cows are close enough.
      - youerbt 5y ago
        Ok, you are another person in this chain who decided to just drop "more practical" and call it a day. Why bother. It is especially funny in the thread about OCaml getting soon (2022 maybe) multicore support. Something this less practical ivory tower Haskell had before it was even cool.
        ernst_klim 5y ago
        Python still has GIL and it's definitely more practical and widely adopted.