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

11–20 of 60 posts

Re: OCaml Programming: Correct and Efficient and Beautiful

#11

Post by derriz »

skybrian wrote: post #8
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?

I'm not an OCaml or Haskell expert, but I expect that laziness makes performance harder to reason about? Edit: but in this case, apparently the book was written for a course at Cornell where they teach both functional and imperative programming using the same language.

In my experience, reasoning about (or maybe being able to manage) memory consumption is more of an issue for fully lazy languages.

Having worked on a code-base written in a lazy (Haskel-like) FPL where the architecture relied heavily on laziness, the least pleasant issue to deal with was sudden and obscure explosions in memory consumption.

Which would of course have a big impact on performance so maybe this was your point also.

Re: OCaml Programming: Correct and Efficient and Beautiful

#12

Post by hermanhermitage »

skybrian wrote: post #8
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?

I'm not an OCaml or Haskell expert, but I expect that laziness makes performance harder to reason about? Edit: but in this case, apparently the book was written for a course at Cornell where they teach both functional and imperative programming using the same language.

That’s been my experience. Across the spectrum of languages I’ve found certain features such as dynamic memory, managed memory, memory safety, evaluation model, etc all have an impact on the transparency of understanding time and space characteristics. I spend most of my time in assembly and C, but love the sheer ranges of language options we have today. I put Haskell in the “Miranda” branch of languages which I love for tackling some problems but day to day but I’ve never got a handle on how that translates into predictable characteristics of the generated code.

Re: OCaml Programming: Correct and Efficient and Beautiful

#13

Post by shawn_w »

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?

Personally, I don't like how Haskell considers things like I/O as side effects that have be wrapped in monads. Ocaml feels much more practical.

Plus, though both languages allow defining new infix operators, ocaml coders are much more restrained about it than haskellers, and I hate having to figure out what >>>>$=<<< does when it shows up in code.

Re: OCaml Programming: Correct and Efficient and Beautiful

#14

Post by faldor20 »

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?

As someone who has lightly used Haskell and quite heavily used ocaml:

- Pragmatism: The ocaml community has a stronger focus on practical real projects. This is shown by the kind of packages available on the ecosystem and the way those packages are presented. (A number of Haskell packages I've tried to use often seen to be primarily intellectual pursuit with little documentation on actually using them).

- Simplicity: Haskell does have some amazing features, but it has so many different ways to do things, so many compiler flags, code can look vastly different from one codebase to another. It's kind of the c++ of FP. Ocaml is definitely more cohesive in its approach.

Tooling: last I used Haskell the whole ecosystem was pretty rough, with two package managers and a lot of complexity in just setting up a project. Ocaml is not at the level of rust or other modern languages, but is definitely a stop above I'd say.

Re: OCaml Programming: Correct and Efficient and Beautiful

#15

Post by [deleted] »

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?

[deleted]

Re: OCaml Programming: Correct and Efficient and Beautiful

#16

Post by AnimalMuppet »

OneDeuxTriSeiGo wrote: post #10
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?

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.

Re: OCaml Programming: Correct and Efficient and Beautiful

#17

Post by sestep »

AnimalMuppet wrote: post #16
OneDeuxTriSeiGo wrote: post #10

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.

No, OCaml is not lazy.

Re: OCaml Programming: Correct and Efficient and Beautiful

#18

Post by KiranRao0 »

AnimalMuppet wrote: post #16
OneDeuxTriSeiGo wrote: post #10

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.

OCaml is not lazy.

src: https://signalsandthreads.com/future-of-programming/

Re: OCaml Programming: Correct and Efficient and Beautiful

#19

Post by Syzygies »

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?

I started with SML in the 1980's, implementing a core math algorithm (Grobner bases) used in my K&R C computer algebra system Macaulay. Then I got this idea there should be a related algorithm in a different problem domain (Hilbert bases) and I managed to convert my code in twenty minutes. It ran. This completely blew my mind, on par with switching from punched card Fortran to an APL terminal in the 1970's.

Everyone talks a good line about more powerful, expressive programming languages till they need to put in the work. Ten years effort to program like ten people the rest of your life? I'm 69 now, I can see how such an investment pays off.

I moved to OCaml. Studying their library source code is the best intro ever to functional programming, but I felt your "all the way" pull and switched to Haskell. (Monads make explicit what a C program is doing anyway. Explicit means the compiler can better help. What it comes down to is making programming feel like thinking about algebra. This is only an advantage if one is receptive to the experience.)

I'm about to commit to Lean 4 as "going all the way". Early in AI pair programming, I tested a dozen languages including these with a challenging parallel test project, and concluded that AI couldn't handle Lean 4. It keeps trying to write proofs, despite Lean's excellence as a general purpose programming language, better than Haskell. That would be like asking for help with Ruby, and AI assuming you want to write a web server.

I now pay $200 a month for Anthropic Max access to Claude Code Opus 4 (regularly hitting limits) having committed to Swift (C meets Ruby, again not just for macOS apps, same category error) so I could have first class access to macOS graphics for my 3-manifold topology research. Alas, you can only build so high a building with stone, I need the abstraction leverage of best-in-category functional languages.

It turns out that Opus 4 can program in Lean 4, which I find more beautiful than any of the dozens of languages I've tried over a lifetime. Even Scheme with parentheses removal done right, and with far more powerful abstractions.

Post reply on HN