Live data from Hacker News

OCaml Programming: Correct and Efficient and Beautiful

cs3110.github.io

51–60 of 60 posts

Re: OCaml Programming: Correct and Efficient and Beautiful

#51

I would take the FP zealots more seriously if they stopped asserting that FP makes things more correct. Zero evidence that this is the case. I can tell you that debugging a compiler written in ML is a dumpster fire compared to debugging a compiler written in C++. If take C++ over any FP language for compilers any day of the week.

> I would take the FP zealots more seriously if they stopped asserting that FP makes things more correct. Depends on the correctness requirements in question. But overall you are 100% correct about this. FP, among other aspects, enables and promotes some ways of reasoning, for instance when mutation is avoided, that can be relatively easy to use to verify correctness of certain types of properties. For instance, indu…

I think it’s true that for a tiny compiler-like thing where you quickly need to roll an AST, FP languages have something to offer.

But larger compilers tend to converge to two architectural features due to the sense that us compiler folk have that it leads to better maintainability. I think there is weak empirical evidence to support these choices (weak because you can’t run a repeatable experiment to prove it; it’s just experience we have)

1. Drop the AST as soon as possible and convert to an IR like a CFG with SSA or something like that. This allows for easier transforms, easier pattern matching, and easier analysis. It’s easier to get the compiler right in CFG than AST and it takes less code to do it.

2. Mutation. Compilers mutate the IR in place. This makes it easier to decouple transforms from one another and encourages writing finer grained passes that just do one thing well.

So you end up with the heart of the compiler being a CFG+SSA IR that is mutable. FP doesn’t help you do that, but OOP does help a lot. And you need state/mutation, ie imperative programming.

Re: OCaml Programming: Correct and Efficient and Beautiful

#52
post #4

Could an OCaml expert give a quick take on the view that if FP, why not go all the way and do Haskell instead? I mean, if "correct, efficient, beautiful" are attributes of OCaml (and I know opinions differ, but let's assume for a moment..) then shouldn't they be attributes of Haskell too, maybe even more so in some ways?

The person to look to for explanations of why OCaml/SML and not Haskell is Bob Harper. For example, the module system vs ad hoc polymorphism: https://existentialtype.wordpress.com/2011/04/16/modules-mat... He also has in-depth critiques of laziness-by-default but the one link I found is a 404.

Re: OCaml Programming: Correct and Efficient and Beautiful

#53

Earlier quoted context omitted.

At least theoretically they could be however OCaml is in large part driven by Jane Street and has been for some time now and Jane Street's entire business model is built around optimizing for ultra high throughput, ultra low latency software where mistakes could cost on the order of hundreds of billions of dollars. So my guess would be less that Haskell is not these things (nor couldn't it be) but rather that OCaml h…

Is OCaml lazy? I'm not an expert, but if you want ultra high throughput, you might not want lazy. If I understand correctly, in Haskell some nonobvious things can slow you down because of the laziness.

How does laziness cause a slowdown? It merely reorders work done, it doesn't necessarily create more work.

Re: OCaml Programming: Correct and Efficient and Beautiful

#54

Earlier quoted context omitted.

You can use the ReasonML syntax with the standard OCaml toolchain, it's the same language with curly braces. (Not to be confused with ReScript which spun off of it, but is now a different language that only targets the JavaScript stack.) Do you simply dislike the OCaml syntax or is it some particular quirk? > the variable scope thing The what thing? Variables are just lexically scoped, are you referring to shadowing?

Convenience link here: https://reasonml.github.io/ (When you look at the blog, you'll see that the last blog update was in 2018, and you might conclude that the project is dead. But it's actually not -- their Github repo is still getting new commits!)

I believe the Reason syntax for OCaml is now maintained by the same people as Melange; which is the revived version of BuckleScript, the OCaml fork targeting JS, from which Reason and later ReScript spun off.

Re: OCaml Programming: Correct and Efficient and Beautiful

#55

Earlier quoted context omitted.

You can use the ReasonML syntax with the standard OCaml toolchain, it's the same language with curly braces. (Not to be confused with ReScript which spun off of it, but is now a different language that only targets the JavaScript stack.) Do you simply dislike the OCaml syntax or is it some particular quirk? > the variable scope thing The what thing? Variables are just lexically scoped, are you referring to shadowing?

IIRC every variable have an anonymous name based on their scope. So a = 10; { a = 20; } print(a) This would print 10. Something like that. I just remembered that the first time I encountered this, I thought "this is going to be one of those things where I will unnecessarily trip over" and closed the page.

You did mean shadowing then. But your example is deceptive, that C-like assignment syntax doesn't exist in Reason, much less in OCaml. The real Reason syntax makes the shadowing much clearer:

  let a = 10;
  {
    let a = 20;
  }
  print(a);
And even more clear in OCaml:

  let a = 10 in
  begin
    let a = 20 in
    ()
  end;
  print a
BTW you should also close the page on Rust then, which also has OCaml-like variable shadowing (and many other languages use very similar forms of shadowing, such as local variables shadowing object fields in Java/C#).

Re: OCaml Programming: Correct and Efficient and Beautiful

#56

Earlier quoted context omitted.

Convenience link here: https://reasonml.github.io/ (When you look at the blog, you'll see that the last blog update was in 2018, and you might conclude that the project is dead. But it's actually not -- their Github repo is still getting new commits!)

I believe the Reason syntax for OCaml is now maintained by the same people as Melange; which is the revived version of BuckleScript, the OCaml fork targeting JS, from which Reason and later ReScript spun off.

Heh, the family lineage here is very complicated!

Re: OCaml Programming: Correct and Efficient and Beautiful

#57
post #45

Earlier quoted context omitted.

FP is great but not necessarily at all costs. OCaml is immediate by default instead of lazy, and allows imperative code with side-effects. Both escape hatches from the pure FP world. So, performance is easier to reason about and you can interact with your side-effecty real world stuff without having to reorganize your whole program around the correct monad. Most of the time you want your loops to be higher order func…

I really like Ocaml, but the error handling is very bad, some libraries use Option/Result, some use exceptions, the inconsistency makes it a little hard to work with. I much prefer Rust in this regard.

doesn't the Rust ecosystem also inconsistently mix Option and Result?

anyway, it's a fairly trivial wrapper to handle the odd annoying thing that raises

Option.try_with (fun () -> thing_that_exns ())

Result.try_with (fun () -> thing_that_exns ())

(it would be nice if you could tell if something raises by the type signature somehow though)

Re: OCaml Programming: Correct and Efficient and Beautiful

#58

Earlier quoted context omitted.

There's plenty of evidence. Here's the OCaml compiler catching a redundant rule in the Unicode line-breaking algorithm: https://www.unicode.org/mail-arch/unicode-ml/y2020-m03/0000.... People who like rejecting this kind of stuff as 'feels' are ironically also being guided by their 'feels'.

One example of a compiler catching some issue isn't evidence. It's an anecdote. There's no scientific experiment you could run that proves, or disproves, that type systems lead to more correctness. It's a thing you cannot possibly know.

We already have scientific experiments that prove it. Here is a significant result: https://ieeexplore.ieee.org/document/7985711

This is why I say that people who keep denying this are vibing based on their feels. Instead of asking for the evidence they just keep saying there can't possibly be any evidence.

Re: OCaml Programming: Correct and Efficient and Beautiful

#59

Earlier quoted context omitted.

Is OCaml lazy? I'm not an expert, but if you want ultra high throughput, you might not want lazy. If I understand correctly, in Haskell some nonobvious things can slow you down because of the laziness.

How does laziness cause a slowdown? It merely reorders work done, it doesn't necessarily create more work.

To do lazyness, you need to accumulate "intermediate computation objects" called thunks. These take space and time to store.

See: https://wiki.haskell.org/index.php?title=Thunk https://wiki.haskell.org/index.php?title=Performance/Strictn...

Re: OCaml Programming: Correct and Efficient and Beautiful

#60
post #4

Could an OCaml expert give a quick take on the view that if FP, why not go all the way and do Haskell instead? I mean, if "correct, efficient, beautiful" are attributes of OCaml (and I know opinions differ, but let's assume for a moment..) then shouldn't they be attributes of Haskell too, maybe even more so in some ways?

The person to look to for explanations of why OCaml/SML and not Haskell is Bob Harper. For example, the module system vs ad hoc polymorphism: https://existentialtype.wordpress.com/2011/04/16/modules-mat... He also has in-depth critiques of laziness-by-default but the one link I found is a 404.

If you'd like to see Bob Harper's take on programming languages, have a look at the short video series Practical Foundations for Programming Languages

https://www.youtube.com/playlist?list=PL0DsGHMPLUWVy9PjI9jOS...

Post reply on HN