Hacker News Reader

Comment by dleslie | Hacker News Reader

OCaml benefits from not looking like operator stew.

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!

I'd say OCaml wins in term of operators and maybe as a language until you start using monads. My entirely subjective feeling is that modern OCaml codebases use more and more monads, the language is becoming less elegant and tedious as a result.

The introduction of let+ and let* made using monads fairly elegant in my opinion but this is a recent addition so you might have never seen it used. Outside of concurrent code monads are not that common in my experience.

Module hell?

I'd even argue that OCaml has way less operator stew than Haskell if we include Haskell's strictness annotations, type class instance selectors, and the large number of operators they have in the standard library. By comparison OCaml has a very modest number of operators.

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.

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

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

> Why would one prefer to fully remove laziness?

Far from an Ocaml/Haskell expert, but is it that laziness makes resource use less predictable?

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

[2] https://markkarpov.com/tutorial/ghc-optimization-and-fusion....

Yes, but is incrementing a mutable variable properly constrained and typed?

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.

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

    f :: Int -> IO Int

    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.

One of the things that Haskell and monads bring to the table is typed side effects. Each action in a monadic computation has a type and cannot be freely mixed with other actions of different types. Of course, it's much easier and more convenient to go side-effecting willy nilly, as OCaml and imperative languages let you do, but that creates too many places for bugs to creep in and hide. Monadic programming gives you more control over what side effects are allowed when.

When I tried to dabble in OCaml, it definitely looked like operator stew to me, but I’m coming to it from the C, Python, JS, etc world so maybe Haskell is even worse in this regard?

You can try reason first, it's a frontend for OCaml with a C-like syntax

https://medium.com/@asankhaya/reason-with-ocaml-b75697a6c00b

Yeah, I played around with Reason but at the time the tooling kind of sucked and it only seemed to be used to generate JavaScript via BuckleScript. Not sure if things are better these days or not.

OCaml definitely has a lot of built-in operators, but Haskell makes it absurdly easy to define your own operators as well, with built-in syntax for using binary operators as prefix functions and vice-versa. I'm not sure there's a definitive answer, but that's probably in large part because the idea of "operator stew" is pretty subjective.

Ocaml makes it super easy to define your own operators as well. I was debugging a performance issue in an Ocaml codebase when I was very junior and new to the language, and proudly reported my finding that we shouldn't be using the (**) power operator in some algorithm but just multiplying and surely this was the cause of the problem. Turned out somebody had defined (**) as 64-bit multiply :)

That said I don't know Haskell to compare!

> Turned out somebody had defined (*) as 64-bit multiply :)

Well I don't think you should have been the one embarrassed in that scenario.

I don't remember exactly how it works in OCaml (it might be similar!) but in Haskell, I think functions beginning with certain characters are automatically operators, but you can use them prefix by wrapping them in parens, e.g. `2 + 2` is the same as `(+) 2 2`. Similarly, a two-parameter function can be used infix by wrapping in backticks. Off the top of my head, I think I remember getting warnings from the linter about saying something like "elem some_list some_elem" to check if an element existed in the list instead of the preferred "some_list `elem` some_elem". The idea that functions are operators are interchangeable and have first-class syntax for swapping between them is a lot of fun, but also one of those things where I feel like I'm kinda glad it's not mainstream due to the shenanigans that I might have to deal with in production code.

It’s been a while but it’s definitely similar in Ocaml, you define a function with a name that consists purely of the set of allowed symbols and it’s useable as an operator. The thing I found really fiddly/tricky is that the first character is used to define whether it’s prefix or infix, and its associativity. Which like you said, it’s very clever and concise and powerful, but can be a bit of a nightmare if you have these operators defined all over the place and have to piece together how they interact.

I don’t think Ocaml had that backtick infix syntax for non-symbol function names though!

I'd say that the learning curve in Haskell is much steeper.

Reply on news.ycombinator.com