Live data from Hacker News

OCaml Programming: Correct and Efficient and Beautiful

cs3110.github.io

91–100 of 251 posts

Re: OCaml Programming: Correct and Efficient and Beautiful

#91

"beautiful" But then it has quirks like using ;; to end statements (EDIT: only in the REPL). And comments with that weird syntax But worse of all are the optional parenthesis in function calls. Yes, I know Ruby has it. But it feel super weird and a needless flexibility (that causes more confusion than it solves). I can't get over this stuff, sorry.

I have to interject here for the sake of those unfamiliar with OCaml and who may take the parent comment at face value.

Saying "it has quirks like using ;; to end statements" is misleading to the point of just being bogus. The double semi-colon is only ever used in the REPL. In fact, I've been programming OCaml for fun and professionally for over 15 years, and I've never used a double semi-colon in my code, nor have I ever encountered one in the "wild".

Re: OCaml Programming: Correct and Efficient and Beautiful

#92
post #5

I spent a lot of time on Standard ML in university. OCaml was always portrayed as the engineer's alternative for real applications. I spent some time brushing up on OCaml a few years ago using Exercism.io. While OCaml is a personal "top tier" language, I'd always prefer Haskell, Rust or Scala. Type classes / traits just seem to beat a higher-order module system for me.

I learned SML/NJ and OCaml around the same time and for some reason I found SML more pleasant. I particularly liked the SML "Basis" library, it felt really well designed to me. Still, I'd pick either over Scala. Superior compilation times, cleaner syntax, less complex. Haskell also just feels excessively clever. I had hoped Rust would be "OCaml but for systems programming" and it sort of is, -- but the borrow checker…

SML definitely has a more tastefully designed syntax also, and not only because it's a smaller grammar. OCaml syntax is the "scuffed" version of SML syntax, as the kids say!

Unfortunately to be a real-world SML user these days is a very isolating proposition, because although there are some really nice implementations (MLton, PolyML), to a first approximation there are zero libraries.

Re: OCaml Programming: Correct and Efficient and Beautiful

#93
post #56

Earlier quoted context omitted.

> vastly superior typing system. (=> less bugs) I have no horse in this race, but claiming it to be "vastly superior" and implying "less bugs" makes it sound like this is a logical consequence, when you're actually staying on one side of an endless debate that to me doesn't have clear winners. For instance, from the little I've learned about Clojure, they claim the lack of a "vastly superior type system" is a feature…

I don't think I've ever seen anyone seriously argue against the claim that strong typing systems at least prevent many types of bugs. Now people may think that they are more productive in a language with weak types but that's a different consideration.

This was on HN the other day: https://github.com/hwayne/awesome-cold-showers#static-vs-dyn.... I would probably add a caveat to the listed caveats that testing might not be considered? Like if every dynamically typed code base implements an ad-hoc typechecker with a testing framework, it's a distinction without a difference.

Re: OCaml Programming: Correct and Efficient and Beautiful

#94

"beautiful" But then it has quirks like using ;; to end statements (EDIT: only in the REPL). And comments with that weird syntax But worse of all are the optional parenthesis in function calls. Yes, I know Ruby has it. But it feel super weird and a needless flexibility (that causes more confusion than it solves). I can't get over this stuff, sorry.

I have to interject here for the sake of those unfamiliar with OCaml and who may take the parent comment at face value. Saying "it has quirks like using ;; to end statements" is misleading to the point of just being bogus. The double semi-colon is only ever used in the REPL. In fact, I've been programming OCaml for fun and professionally for over 15 years, and I've never used a double semi-colon in my code, nor have…

Thanks for clarifying

Re: OCaml Programming: Correct and Efficient and Beautiful

#95
post #58

Earlier quoted context omitted.

There are many similar warts in the ocaml type system. Parametric polymorphism in ocaml sucks as well. If you haven't tried haskell, you probably should. Its type system is much cleaner (and more powerful, if you want) than ocaml's, and many details of Rust are derived from Haskell.

Parametric polymorphic is the same in OCaml and Haskell. Did you meant to say that the value restriction does not play nicely with point-free programming?

That's one aspect of it. The ergonomics are dogshit. I remember having to use explicit quantification all the time when writing polymorphic library code. Also, without typeclasses, polymorphism is super inconvenient, to the point where it's almost exclusively used in the most critical data structures like sets and maps. It's not "the same as in haskell" except maybe in the very vague sense that they have similar underlying type theories (although ocaml's is much weaker - e.g. I remember needing to use some hacks to approximate HKTs, while haskell handles them easily).

Re: OCaml Programming: Correct and Efficient and Beautiful

#96
post #58

Earlier quoted context omitted.

There are many similar warts in the ocaml type system. Parametric polymorphism in ocaml sucks as well. If you haven't tried haskell, you probably should. Its type system is much cleaner (and more powerful, if you want) than ocaml's, and many details of Rust are derived from Haskell.

Haskell is a great language but has plenty of its own warts. The value prop and trade offs between OCaml and Haskell really makes it hard to use one as a drop in for the other imo.

Strong disagree; I have thousands of hours with both and I would essentially never recommend ocaml over haskell unless your company already has an ocaml codebase/ocaml expert employees.

I'm very conscious of the existence of pareto tradeoffs; I am asserting that, in this case, there is essentially no tradeoff to be made. Haskell is equal or better (sometimes significantly so) in almost every relevant domain. For domains in which ocaml is a better choice, it is not the globally best choice (i.e. both ocaml and haskell are bad in those domains).

Re: OCaml Programming: Correct and Efficient and Beautiful

#97
post #95

Earlier quoted context omitted.

Parametric polymorphic is the same in OCaml and Haskell. Did you meant to say that the value restriction does not play nicely with point-free programming?

That's one aspect of it. The ergonomics are dogshit. I remember having to use explicit quantification all the time when writing polymorphic library code. Also, without typeclasses, polymorphism is super inconvenient, to the point where it's almost exclusively used in the most critical data structures like sets and maps. It's not "the same as in haskell" except maybe in the very vague sense that they have similar unde…

OCaml does not require more annotations than Haskell for polymorphic functions? Both language only require annotations in the case where inference would be undecidable (polymorphic recursions, higher-rank polymorphism, and GADTs).

I know few cases where OCaml require less annotations than Haskell, I would expect the reverse to be true.

And maps and sets are not the main use case for polymorphism in OCaml. Even taking in account that it sounds like you are talking about functors, maps and sets are still not the only instance of functors in OCaml.

Re: OCaml Programming: Correct and Efficient and Beautiful

#98
post #95

Earlier quoted context omitted.

That's one aspect of it. The ergonomics are dogshit. I remember having to use explicit quantification all the time when writing polymorphic library code. Also, without typeclasses, polymorphism is super inconvenient, to the point where it's almost exclusively used in the most critical data structures like sets and maps. It's not "the same as in haskell" except maybe in the very vague sense that they have similar unde…

OCaml does not require more annotations than Haskell for polymorphic functions? Both language only require annotations in the case where inference would be undecidable (polymorphic recursions, higher-rank polymorphism, and GADTs). I know few cases where OCaml require less annotations than Haskell, I would expect the reverse to be true. And maps and sets are not the main use case for polymorphism in OCaml. Even taking…

> OCaml does not require more annotations than Haskell for polymorphic functions?

A) I am fairly confident this is not actually true in a technical sense, although it's been several years since I've thought about it

B) In any case, in the (many) instances where you (by rule or convention) need to put a type signature on your function (e.g. because it's a top-level function, one that you export, etc.), it is a pain in the ass to make it polymorphic in ocaml compared to in haskell.

> Even taking in account that it sounds like you are talking about functors

No, I'm not, although ocaml people tend to think exclusively in "functors" (badly named, in my opinion - conflicts with the more common category-theoretic definition) because the experience of using actually parametric functions is so bad that they almost never do it.

Re: OCaml Programming: Correct and Efficient and Beautiful

#99
post #3

My introduction to programming course in my university was in OCaml. It was all downhill from there when it comes to the programming languages I had to use.

Seems its better to start with javascript so you can have the reverse experience.

Then I would probably be writing HN posts claiming that languages with advanced type systems and functional programming are too hard and impractical, and that they are trying to be clever and cool for no reason.

But, partly thanks to that course, I'm able to pick up any paradigm, and my opinion on what's better is informed by knowledge of both things. I'm also able to structure imperative code better than my "imperative only" colleagues.

Re: OCaml Programming: Correct and Efficient and Beautiful

#100
post #41

Earlier quoted context omitted.

It's not getting things done that matters. It's feeling superior to others that matters.

Hey, it's not a feeling. It's a fact.

It is certainly a fact, that you feel superior.

I would like to confirm that fact, by comparing productive output..

Post reply on HN