How do I know that some code is beautiful? And how will one know that it will always stay beautiful? Correct and efficient is one thing. Beautiful? This is off topic but topics like this grinds my gears as it’s purely subjective.
OCaml Programming: Correct and Efficient and Beautiful
191–200 of 251 posts
Re: OCaml Programming: Correct and Efficient and Beautiful
#192Earlier quoted context omitted.
yes, that would be a straightforward error message! But I got the error message Error: This expression has type ((locl_ty * Tast.pos * ('ex, 'fb, 'en) Aast.expr_) list -> Result_set.t) list but an expression was expected of type Result_set.t list Type (locl_ty * Tast.pos * ('ex, 'fb, 'en) Aast.expr_) list -> Result_set.t is not compatible with type Result_set.t Which is not half as readable.
With OCaml type system permanently burned in my mind, I parse that error message as "there is an ` _ -> Result_set.t ` arrow type which is not compatible with type `Result_set.t`". Do you think that the issue is that the arrow `->` is too hard to spot?
It might help to make the difference more obvious by also showing the parts which unify properly, or introduce alias variables
for complex type expressions (for instance "(int * float array) list as 'a") to move away some of the noise in the error.
Re: OCaml Programming: Correct and Efficient and Beautiful
#193Earlier quoted context omitted.
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 doma…
Compile times and architecture astronomy are obvious counterarguments to the 'Haskell is always superior' delusion ;-)
Re: OCaml Programming: Correct and Efficient and Beautiful
#194very grateful that this course is free for all, and the youtube lectures are neat too real world ocaml 2e is nice, but like a lot of oreilly books about $LANGUAGE lately it's a lot of thinly-veiled $COMPANY opinions on $LANGUAGE best practices, where $COMPANY is, in this case, jane street. this is great if your motivation for learning ocaml is applying for a job at jane street if you think ocaml seems cool because wo…
I actually find these thinly veiled company best practices fascinating.
I find I can learn a lot of life lessons by reading a condensed account of a person’s entire life in their (auto)biography.
For the same reason, I would hope to learn a lot of great real life patterns from a book called Real World OCaml… a kind of condensed (auto)biography of an institution’s experience with a technology.
Re: OCaml Programming: Correct and Efficient and Beautiful
#195Earlier quoted context omitted.
Ok, you are using "parametric polymorphism" to mean bounded polymorphism. This explain my confusion! Indeed, I can understand your point of view then: bounded polymorphism is indeed better done with functors in OCaml. And since functor are syntactically heavy in OCaml there are not used everywhere and only when they are useful. Which doesn't mean that they are not used at all, as the Mirage project can attest. Mirage…
I don't really consider those separate things. Bounded polymorphism is parametric polymorphism, plus a type subset relationship. A quick sanity check on wikipedia is consistent with this model. BP is PP plus what's required to make it more than a toy I remember one annoyance I had with ocaml was the effective inability to use point-free style. I can't remember what limitation was behind this; do you know off the top…
> BP is PP plus what's required to make it more than a toy
And in fact OCaml does have BP, as was explained earlier, just with a heavier syntax.
> effective inability to use point-free style
OK but point-free style is not an end in itself, it's just a means to an end (clean code), and there's certainly no universal agreement that it's the best means...explicit style is almost always easier to understand for a wide assortment of people and doesn't require mental backflips trying to figure out the weird heiroglyphics of '(.) (.) (.)' etc. etc.
> Huge limitation for polymorphic ocaml code.
Yeah I can see how writing e.g.
let f x = g [] x
let f = g []
Re: OCaml Programming: Correct and Efficient and Beautiful
#196Earlier quoted context omitted.
Or if, you know, they were hired to work on a project where they get paid a salary. That seems to incentivize most devs.
Not "a salary", but a Jane Street salary and resume cred. Otherwise you just won't find that many takers.
I can assure you I will and in fact have found plenty of takers for my job postings with a niche language. You just need to word the postings appropriately and be willing to teach people what they don't know.
Re: OCaml Programming: Correct and Efficient and Beautiful
#197Earlier quoted context omitted.
let's see: - OCaml vs Haskell: eager vs lazy (=> memory consumption is more predictable) - OCaml vs Rust: OCaml has a GC (=> comfort) OCaml has tco (could not resist this ;) ) - OCaml vs Clojure: vastly superior typing system. (=> less bugs) - OCaml vs Kotlin: no JVM needed. - OCaml vs C++: more safety. once it compiles it will not segv. - OCaml vs Go: vastly superior typing system. (=> less bugs) - OCaml vs Python:…
OCaml vs All: Good luck finding developers that will write quality code and not cost a fortune each.
Good luck finding high quality cheap developers in any language really. Very few good developers are language specific so unless your HM is an idiot and actively screens out candidates without 10 years of previous experience in the specific framework you're using it won't be a limitation. If you want quality developers you need to offer either 1) lots of money, 2) amazing benefits, 3) interesting problems to work on. For many, an interesting language can provide an edge. I chose my current company because I would be working on Scala here as opposed to Java with the other offers I had. The quality of life improvement of the Scala position was enough to take it over the prospect of writing AbstractFactoryBeanImpl for the next few years.
Re: OCaml Programming: Correct and Efficient and Beautiful
#198Earlier quoted context omitted.
> It has no performance or coding benefit for teams larger than a few. That must be why Jane Street uses it then.
And pretty much only them. Perhaps some day we'll learn how little the programming language matters for anything beyond coding.
Ever used AWS EC2? Docker Desktop? OCaml code is driving some of the lower-level performance-sensitive parts. That's a gajillion instances running globally.
Re: OCaml Programming: Correct and Efficient and Beautiful
#199Earlier quoted context omitted.
Tiny quibble that I wouldn’t normally post but I think illustrates the readability issues here: Should that be “Result set type was expected”, not “list”?
No, I think this: Result_set.t list means a list whose items are of type Result_set.t. Also I think the notation X.t is idiomatic for a type defined by module X.
Regardless the function does not return a list.
Re: OCaml Programming: Correct and Efficient and Beautiful
#200Earlier quoted context omitted.
Which university? Does the course have a public webpage?
Cambridge does this (or did when I was there); https://www.cl.cam.ac.uk/~lp15/MLbook/ is the book for the course (available online).
It still does according to the undergraduate program page https://www.undergraduate.study.cam.ac.uk/courses/computer-s...