8 ms·

I'm excited. Haskell gets a lot of attention but I have the feeling that OCaml may be better for engineers.

by Kototama 5y ago

deleted 5y ago
[deleted]
ghostwriter 5y ago
How can parallel untracked mutations of untracked state be better for engineers?
- naasking 5y ago
  > How can parallel untracked mutations of untracked state be better for engineers? It basically requires eager evaluation which, believe it or not, is a huge ergonomic win for people wanting to work on practical problems. OCaml also preserves the concise syntax and great type inference you get in Haskell. All in all, a more pragmatic set of tradeoffs I'd say, although it certainly has its own problems.
- sidkshatriya 5y ago
  There are many paradigms in programming. Each have their strengths. A purely functional approach ala Haskell is not the only way. Based on your comment, it would seem no one should use C/C++. Yet many do. It depends on what you want to achieve, what is your abstraction budget, your performance requirement, legacy code... OCaml offers a pragmatic functional approach to programming. And now you are going to be able to have your OCaml code run in a truly parallel fashion on your multicore CPU. In the future there are plans to add typing to effects though. (There is support for effects currently but its untyped and experimental). When that happens you can track changes to state (which is a kind of "effect") if you want to...
  - ghostwriter 5y ago
    > 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?
  - ModernMech 5y ago
    > Based on your comment, it would seem no one should use C/C++ Maybe, there are better options out there these days for parallel and concurrent programs. Parallel programming in C and C++ is extremely fraught for the very reasons the parent brings up. There are so many footguns, starting from the fact that the favorite debugging method of C programmers, printf(), is not even thread safe. It’s so bad that Rust markets as a feature “fearless concurrency”, capitalizing on the recognition that the prevailing emotional state of a C or C++ dev writing concurrent or parallel programs is one of fear. And the very thing that makes Rust concurrency fearless over C and C++ is that borrowing and mutability are explicitly tracked. As we enter a world where over a dozen CPU cores are the norm, we are learning what works and what doesn’t in writing programs for these machines, and integrating those learnings into new languages.
    - nomel 5y ago
      > starting from the fact that the favorite debugging method of C programmers, printf() Most everyone I know uses a debugger. Maybe you're mostly exposed to beginner programmers?
      - pjmlp 5y ago
        There are couple of them that share this kind of opinions, https://lkml.org/lkml/2000/9/6/65 https://lkml.org/lkml/2000/9/6/65
        nomel 5y ago
        I sympathize with what he's saying, and I imagine he's correct, for his context, but some of us don't work on never-ending code and just want to write the best code we can, as quickly as possible, so we can move on to the next challenge. For those that are more pragmatic, and enjoy working on the hard problems the code is trying to solve rather than the hard problems of the code, using a debugger can be beneficial.
        pjmlp 5y ago
        There are tons of ways to use debuggers, even in places that might seem one needs to contend themselves with printf debugging, what many miss is learning what is actually available. So you end up with legions of Linus hatting on debuggers and proud themselves of never having to use one, some kind of macho thing I guess.
- hedora 5y ago
  I assume they were referring to the strong OCaml ecosystem (and collection of C/C++ bindings), not the relative merits of the threading systems.
  - wk_end 5y ago
    The OCaml ecosystem is not particularly strong compared to Haskell (or most other languages).
- grumpyprole 5y ago
  It may not remain untracked, hopefully types for algebraic effects will land in the future.
- ernst_klim 5y ago
  > How can parallel untracked mutations of untracked state be better for engineers? What is untracked? Is unsafePerformIO (printLn ...) tracked? What is tracked? Is foo :: IO () thread-safe? Maybe, maybe not. What meaningful information does this signature says to me? That it does some IO? That's an extremely useless information, especially if most of your code is IO something. What granularity does IO have? Does foo :: IO () throws any exceptions? Maybe, maybe not. The need for effect tracking for writing correct programs is way overstated by some Haskell programmers. It's usually much more prudent to write DSLs which hide effects like variable mutations and logging, than expose them. For example you can start your program with a pure correct-by-construction core DSL, and then add logging, mutable variables where needed underneath the DSL's terms without breaking the semantics of the DSL. With effect tracking you are doomed to either reinvent custom effects to be able to switch interpreters painlessly, or you'll need to break the DSL by the addition of effects. Neither is prudent in real world, neither gives more value than takes. What is really funny is that some Haskell programmed believe that logging should be tracked, but allocation apparently should not (yes, it's a side effect). Where in fact all the "effects" are need to be tracked only when they are meaningful, i.e. when they are part of our DSL's semantics, and not some hidden part of the interpreter I don't need to know about. Imagine a theorem prover function which creates a conjunction of two terms: val conj : term -> term -> term It doesn't matter if it allocates or logs, at the precision that is interesting to us, it's just a function creating a conjunction of two terms.
  - ghostwriter 5y ago
    > unsafePerformIO (printLn ...) This repetitive talking point is getting boring. Go figure whether it's tracked now: {-# LANGUAGE Safe #-} -distrust-all-packages > What meaningful information does this signature says to me? That it does some IO? That's an extremely useless information, especially if most of your code is IO something. That's an extremely narrow view which you wouldn't have if you ever tried to implement a safe sandboxed environment. > What granularity does IO have? Does [...] throws any exceptions? Maybe, maybe not. what does it have to do with tracked parallel mutations? > Neither is prudent in real world, neither gives more value than takes define prudent and define real-world. > It doesn't matter if it allocates or logs have you heard about referential transparency? It's the thing your "theorem prover" example does not have.
dleslie 5y ago
OCaml benefits from not looking like operator stew.
- sidkshatriya 5y ago
  Actually OCaml has more operator stew than Haskell. Haskell's use of typeclasses/HKT avoids a lot of operator/function-name noise in the code. Where OCaml wins is that it does not hate mutation. This makes the code more impure but simpler. Sometimes just incrementing a mutable variable makes more sense than introducing a state monad!
  - bitwize 5y ago
    Yes, but is incrementing a mutable variable properly constrained and typed?
    - deleted 5y ago
      [deleted]
    - DonaldPShimoda 5y ago
      What does this even mean? OCaml's variables are immutable. To use mutation, you have to do so explicitly with the `ref` type, e.g.: let box = ref 0 in print_endline ("box value: " ++ int_of_string !box); box := !box + 1; print_endline ("box value: " ++ int_of_string !box) will print first `0` and then `1`. You cannot put a non-integer into the box because the box has type `int ref`, meaning only values of type `int` can be put into it with the `:=` operator.
      - kccqzy 5y ago
        GP is (rhetorically, I assume) asking about whether or not the action of incrementing the mutable variable is typed, not that the variable itself is typed. For example in normal Haskell the code that uses mutation and code that does not use mutation have different types. A function may have the type f :: Int -> Int but with mutation it can become f :: Int -> ST s Int or f :: Int -> IO Int or f :: Int -> STM Int depending on the circumstances. That's not the case in OCaml. The kind of mutation in OCaml references is the most similar to Haskell's ST monad (not to be confused with State or StateT), but in Haskell the type tells us a mutation is happening inside the function call.
DonaldPShimoda 5y ago
Totally agree. OCaml is, in general, a better choice for engineering and real-world application. I think Haskell gets a lot of attention because it's interesting (for lack of a better word). I don't mean "OCaml is a boring language", but rather "Haskell was specifically designed as a playground for advanced ideas in type theory, so lots of weird things happen in that ecosystem." For doing personal projects for fun, I'd rather work with Haskell, but for getting things done probably not.
gmfawcett 5y ago
Please let's just all be friends. :) It's fair game to discuss and differentiate the two languages on features, but "better for engineers" is going to take us right into the valley of flame-wars, by way of No-True-Scotsman town. :) Haskell and OCaml are both brilliant languages, with excellent feature sets and amazing dev teams... and lots of "engineers" who like them.
- yawaramin 5y ago
  Note the difference: Kototama: ...I have the feeling that OCaml may be better for engineers. You: let's not say that OCaml is better for engineers. People are allowed to feel things. But I'll give you a concrete reason why OCaml actually can be better for engineers: named and optional arguments. This single feature does wonders for code readability and maintainability. Actually I'll throw in a bonus reason: no laziness by default i.e. small and simple, predictable runtime that behaves almost exactly like a C executable.
  - light_hue_1 5y ago
    Named arguments exist, https://hackage.haskell.org/package/named-0.3.0.1/docs/Named.html https://hackage.haskell.org/package/named-0.3.0.1/docs/Named... That's just one example. But yes. Optional arguments are a big problem at scale. And laziness is the worst antifeature I could imagine. But. You can disable laziness and get great performance. You just need to be careful when using libraries and pick ones that have the right strictness. A strict Haskell would be a killer language.
    - pharmakom 5y ago
      > You just need to be careful when using libraries and pick ones that have the right strictness. Honestly a deal breaker > A strict Haskell would be a killer language. PureScript may be this language!
    - deleted 5y ago
      [deleted]
  - 5y ago
jamespwilliams 5y ago
Agreed. Being able to drop seamlessly into an imperative style is very useful. I’m someone who isn’t an experienced functional programmer, or that deeply knowledgeable about type systems and category theory etc, but OCaml is still approachable to me, I feel I can get stuff done in it. I didn’t feel that way with Haskell - I tried, but found the number of ways to do things overwhelming, and a lot of it felt very theoretical. Of course, Haskell’s pureness is an impressive and interesting feature; but it isn’t for me. OCaml also has much better systems programming abilities compared with Haskell, IMO. It feels like OCaml is the Rust of the functional programming world (and this is no accident, the Rust compiler was first implemented in OCaml in fact). This is all completely subjective of course.
baby 5y ago
I see Rust as an imperative language with functional support, and OCaml as a functional language with imperative support

I'm excited. Haskell gets a lot of attention but I have the feeling that OCaml may be better for engineers.

deleted 5y ago

[deleted]

ghostwriter 5y ago

How can parallel untracked mutations of untracked state be better for engineers?

naasking 5y ago
> How can parallel untracked mutations of untracked state be better for engineers? It basically requires eager evaluation which, believe it or not, is a huge ergonomic win for people wanting to work on practical problems. OCaml also preserves the concise syntax and great type inference you get in Haskell. All in all, a more pragmatic set of tradeoffs I'd say, although it certainly has its own problems.
sidkshatriya 5y ago
There are many paradigms in programming. Each have their strengths. A purely functional approach ala Haskell is not the only way. Based on your comment, it would seem no one should use C/C++. Yet many do. It depends on what you want to achieve, what is your abstraction budget, your performance requirement, legacy code... OCaml offers a pragmatic functional approach to programming. And now you are going to be able to have your OCaml code run in a truly parallel fashion on your multicore CPU. In the future there are plans to add typing to effects though. (There is support for effects currently but its untyped and experimental). When that happens you can track changes to state (which is a kind of "effect") if you want to...
- ghostwriter 5y ago
  > 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?
- ModernMech 5y ago
  > Based on your comment, it would seem no one should use C/C++ Maybe, there are better options out there these days for parallel and concurrent programs. Parallel programming in C and C++ is extremely fraught for the very reasons the parent brings up. There are so many footguns, starting from the fact that the favorite debugging method of C programmers, printf(), is not even thread safe. It’s so bad that Rust markets as a feature “fearless concurrency”, capitalizing on the recognition that the prevailing emotional state of a C or C++ dev writing concurrent or parallel programs is one of fear. And the very thing that makes Rust concurrency fearless over C and C++ is that borrowing and mutability are explicitly tracked. As we enter a world where over a dozen CPU cores are the norm, we are learning what works and what doesn’t in writing programs for these machines, and integrating those learnings into new languages.
  - nomel 5y ago
    > starting from the fact that the favorite debugging method of C programmers, printf() Most everyone I know uses a debugger. Maybe you're mostly exposed to beginner programmers?
    - pjmlp 5y ago
      There are couple of them that share this kind of opinions, https://lkml.org/lkml/2000/9/6/65 https://lkml.org/lkml/2000/9/6/65
      - nomel 5y ago
        I sympathize with what he's saying, and I imagine he's correct, for his context, but some of us don't work on never-ending code and just want to write the best code we can, as quickly as possible, so we can move on to the next challenge. For those that are more pragmatic, and enjoy working on the hard problems the code is trying to solve rather than the hard problems of the code, using a debugger can be beneficial.
        pjmlp 5y ago
        There are tons of ways to use debuggers, even in places that might seem one needs to contend themselves with printf debugging, what many miss is learning what is actually available. So you end up with legions of Linus hatting on debuggers and proud themselves of never having to use one, some kind of macho thing I guess.
hedora 5y ago
I assume they were referring to the strong OCaml ecosystem (and collection of C/C++ bindings), not the relative merits of the threading systems.
- wk_end 5y ago
  The OCaml ecosystem is not particularly strong compared to Haskell (or most other languages).
grumpyprole 5y ago
It may not remain untracked, hopefully types for algebraic effects will land in the future.
ernst_klim 5y ago
> How can parallel untracked mutations of untracked state be better for engineers? What is untracked? Is unsafePerformIO (printLn ...) tracked? What is tracked? Is foo :: IO () thread-safe? Maybe, maybe not. What meaningful information does this signature says to me? That it does some IO? That's an extremely useless information, especially if most of your code is IO something. What granularity does IO have? Does foo :: IO () throws any exceptions? Maybe, maybe not. The need for effect tracking for writing correct programs is way overstated by some Haskell programmers. It's usually much more prudent to write DSLs which hide effects like variable mutations and logging, than expose them. For example you can start your program with a pure correct-by-construction core DSL, and then add logging, mutable variables where needed underneath the DSL's terms without breaking the semantics of the DSL. With effect tracking you are doomed to either reinvent custom effects to be able to switch interpreters painlessly, or you'll need to break the DSL by the addition of effects. Neither is prudent in real world, neither gives more value than takes. What is really funny is that some Haskell programmed believe that logging should be tracked, but allocation apparently should not (yes, it's a side effect). Where in fact all the "effects" are need to be tracked only when they are meaningful, i.e. when they are part of our DSL's semantics, and not some hidden part of the interpreter I don't need to know about. Imagine a theorem prover function which creates a conjunction of two terms: val conj : term -> term -> term It doesn't matter if it allocates or logs, at the precision that is interesting to us, it's just a function creating a conjunction of two terms.
- ghostwriter 5y ago
  > unsafePerformIO (printLn ...) This repetitive talking point is getting boring. Go figure whether it's tracked now: {-# LANGUAGE Safe #-} -distrust-all-packages > What meaningful information does this signature says to me? That it does some IO? That's an extremely useless information, especially if most of your code is IO something. That's an extremely narrow view which you wouldn't have if you ever tried to implement a safe sandboxed environment. > What granularity does IO have? Does [...] throws any exceptions? Maybe, maybe not. what does it have to do with tracked parallel mutations? > Neither is prudent in real world, neither gives more value than takes define prudent and define real-world. > It doesn't matter if it allocates or logs have you heard about referential transparency? It's the thing your "theorem prover" example does not have.

dleslie 5y ago

OCaml benefits from not looking like operator stew.

sidkshatriya 5y ago
Actually OCaml has more operator stew than Haskell. Haskell's use of typeclasses/HKT avoids a lot of operator/function-name noise in the code. Where OCaml wins is that it does not hate mutation. This makes the code more impure but simpler. Sometimes just incrementing a mutable variable makes more sense than introducing a state monad!
- bitwize 5y ago
  Yes, but is incrementing a mutable variable properly constrained and typed?
  - deleted 5y ago
    [deleted]
  - DonaldPShimoda 5y ago
    What does this even mean? OCaml's variables are immutable. To use mutation, you have to do so explicitly with the `ref` type, e.g.: let box = ref 0 in print_endline ("box value: " ++ int_of_string !box); box := !box + 1; print_endline ("box value: " ++ int_of_string !box) will print first `0` and then `1`. You cannot put a non-integer into the box because the box has type `int ref`, meaning only values of type `int` can be put into it with the `:=` operator.
    - kccqzy 5y ago
      GP is (rhetorically, I assume) asking about whether or not the action of incrementing the mutable variable is typed, not that the variable itself is typed. For example in normal Haskell the code that uses mutation and code that does not use mutation have different types. A function may have the type f :: Int -> Int but with mutation it can become f :: Int -> ST s Int or f :: Int -> IO Int or f :: Int -> STM Int depending on the circumstances. That's not the case in OCaml. The kind of mutation in OCaml references is the most similar to Haskell's ST monad (not to be confused with State or StateT), but in Haskell the type tells us a mutation is happening inside the function call.

DonaldPShimoda 5y ago

Totally agree. OCaml is, in general, a better choice for engineering and real-world application. I think Haskell gets a lot of attention because it's interesting (for lack of a better word). I don't mean "OCaml is a boring language", but rather "Haskell was specifically designed as a playground for advanced ideas in type theory, so lots of weird things happen in that ecosystem." For doing personal projects for fun, I'd rather work with Haskell, but for getting things done probably not.

gmfawcett 5y ago

Please let's just all be friends. :) It's fair game to discuss and differentiate the two languages on features, but "better for engineers" is going to take us right into the valley of flame-wars, by way of No-True-Scotsman town. :) Haskell and OCaml are both brilliant languages, with excellent feature sets and amazing dev teams... and lots of "engineers" who like them.

yawaramin 5y ago
Note the difference: Kototama: ...I have the feeling that OCaml may be better for engineers. You: let's not say that OCaml is better for engineers. People are allowed to feel things. But I'll give you a concrete reason why OCaml actually can be better for engineers: named and optional arguments. This single feature does wonders for code readability and maintainability. Actually I'll throw in a bonus reason: no laziness by default i.e. small and simple, predictable runtime that behaves almost exactly like a C executable.
- light_hue_1 5y ago
  Named arguments exist, https://hackage.haskell.org/package/named-0.3.0.1/docs/Named.html https://hackage.haskell.org/package/named-0.3.0.1/docs/Named... That's just one example. But yes. Optional arguments are a big problem at scale. And laziness is the worst antifeature I could imagine. But. You can disable laziness and get great performance. You just need to be careful when using libraries and pick ones that have the right strictness. A strict Haskell would be a killer language.
  - pharmakom 5y ago
    > You just need to be careful when using libraries and pick ones that have the right strictness. Honestly a deal breaker > A strict Haskell would be a killer language. PureScript may be this language!
  - deleted 5y ago
    [deleted]
- 5y ago

jamespwilliams 5y ago

Agreed. Being able to drop seamlessly into an imperative style is very useful. I’m someone who isn’t an experienced functional programmer, or that deeply knowledgeable about type systems and category theory etc, but OCaml is still approachable to me, I feel I can get stuff done in it. I didn’t feel that way with Haskell - I tried, but found the number of ways to do things overwhelming, and a lot of it felt very theoretical. Of course, Haskell’s pureness is an impressive and interesting feature; but it isn’t for me. OCaml also has much better systems programming abilities compared with Haskell, IMO. It feels like OCaml is the Rust of the functional programming world (and this is no accident, the Rust compiler was first implemented in OCaml in fact). This is all completely subjective of course.

baby 5y ago

I see Rust as an imperative language with functional support, and OCaml as a functional language with imperative support