Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OCaml Programming: Correct and Efficient and Beautiful

cs3110.github.io

Post reply on HN
Print view View original

41–50 of 60 posts

Re: OCaml Programming: Correct and Efficient and Beautiful

#41

Post by [deleted] »

differentmod wrote: post #40
pizlonator wrote: post #29

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…

[deleted]

Re: OCaml Programming: Correct and Efficient and Beautiful

#42

Post by differentmod »

yawaramin wrote: post #38
pizlonator wrote: post #36

Earlier quoted context omitted.

There is no evidence that any of those things lead to more correctness. It’s all feels

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

Do you have any thoughts on my other post in this comment section?

https://news.ycombinator.com/item?id=44699548

Re: OCaml Programming: Correct and Efficient and Beautiful

#43

Post by djtango »

mbac32768 wrote: post #23
teiferer wrote: 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?

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…

It's really worth noting that one of the biggest real world Haskell codebases in the world (ie Standard Chartered) wrote their own compiler to make Haskell evaluation strict and make it easier to do interop with C++

Laziness by default was definitely an opinionated design choice for a language when using it in production

Re: OCaml Programming: Correct and Efficient and Beautiful

#44

Post by tome »

djtango wrote: post #43
mbac32768 wrote: post #23

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…

It's really worth noting that one of the biggest real world Haskell codebases in the world (ie Standard Chartered) wrote their own compiler to make Haskell evaluation strict and make it easier to do interop with C++ Laziness by default was definitely an opinionated design choice for a language when using it in production

When I worked for Standard Chartered I was told that Mu, the compiler in question, was only strict because it was originally written to target an existing strict runtime (called Lambda, and Mu is the next letter in the Greek alphabet), not because they particularly wanted a strict language.

Re: OCaml Programming: Correct and Efficient and Beautiful

#45

Post by Mk2000 »

mbac32768 wrote: post #23
teiferer wrote: 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?

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.

Re: OCaml Programming: Correct and Efficient and Beautiful

#46

Post by johnisgood »

yawaramin wrote: post #34
pizlonator wrote: post #29

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.

OCaml is not just FP. It's FP + strong static typing + modular programming + exhaustive pattern matching + fast compiles + great set of built-in compiler lints (eg unused code warnings, mutation warnings). All of these things together help write very reliable code.

For those who do not know, OCaml is multi-paradigm. You can do OOP and imperative in OCaml as well, not just FP. In a typical codebase, you may find a combination of all styles.

Re: OCaml Programming: Correct and Efficient and Beautiful

#47

Post by Taikonerd »

debugnik wrote: post #31
anon-3988 wrote: post #30

I just want OCAML to have curly braces, please. And the variable scope thing in OCAML is extremely off putting.

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!)

Re: OCaml Programming: Correct and Efficient and Beautiful

#48

Post by anon-3988 »

debugnik wrote: post #31
anon-3988 wrote: post #30

I just want OCAML to have curly braces, please. And the variable scope thing in OCAML is extremely off putting.

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.

Re: OCaml Programming: Correct and Efficient and Beautiful

#49

Post by pizlonator »

yawaramin wrote: post #38
pizlonator wrote: post #36

Earlier quoted context omitted.

There is no evidence that any of those things lead to more correctness. It’s all feels

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.

Re: OCaml Programming: Correct and Efficient and Beautiful

#50

Post by [deleted] »

pjmlp wrote: post #37
pizlonator wrote: post #29

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.

Yet all mainstream languages, including C++, keep adding FP concepts. Better spend some time having fun with std::variant, visit, and ranges transformers.

[deleted]
Post reply on HN