Live data from Hacker News

OCaml Programming: Correct and Efficient and Beautiful

cs3110.github.io

21–30 of 60 posts

Re: OCaml Programming: Correct and Efficient and Beautiful

#21
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?

Pros and cons as usual. I worked with both languages professionally but I personally find OCaml more practical, better at programming in the large and easier to write maintainable code. It's a simpler language overall (side effects, strict evaluation). I find the language finds sweet spot between these attributes whereas Haskell is more abstract.

That being said, Haskell is pretty nice as well but I'd pick OCaml for real world stuff.

One thing that bothered me with both these languages is that people not fluent with FP could write code that isn't idiomatic at all. It's probably a bit harder to do in Haskell.

Re: OCaml Programming: Correct and Efficient and Beautiful

#22
post #13
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.

*. sends its regards

:)

Re: OCaml Programming: Correct and Efficient and Beautiful

#23
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 functions but once in awhile you want to just build a vector from a for loop. OCaml let's you do it without it being a whole intervention.

Re: OCaml Programming: Correct and Efficient and Beautiful

#24
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…

What about Haskell STM versus OCaml Multicore Eio?

Re: OCaml Programming: Correct and Efficient and Beautiful

#25
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?

My take is that OCaml lets you sneak a little mutation in, with a little effort, which can make a huge difference in the performance of some algorithms.

Re: OCaml Programming: Correct and Efficient and Beautiful

#26
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…

Have you looked at Idris 2?

I'm 53, impressed that you're still going at it at 69!

Re: OCaml Programming: Correct and Efficient and Beautiful

#27
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…

Also, a major differentiator is that Haskell deals with effects primarily by using monads, whereas many modern functional languages (e.g. Koka or Flix) are being designed from the ground up to use algebraic effects instead. OCaml is also embracing effects. Haskell has some effect libraries as well, but monadic code is everywhere. IMHO, as someone who loves Haskell, algebraic effects will make FP much more approachable.

Re: OCaml Programming: Correct and Efficient and Beautiful

#28

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…

What about Haskell STM versus OCaml Multicore Eio?

Kcas is the Haskell STM analogue in OCaml https://github.com/ocaml-multicore/kcas/

Re: OCaml Programming: Correct and Efficient and Beautiful

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

Post reply on HN