Live data from Hacker News

OCaml Programming: Correct and Efficient and Beautiful

cs3110.github.io

71–80 of 251 posts

Re: OCaml Programming: Correct and Efficient and Beautiful

#72
post #40
post #27

I found my experience trying to work with a large OCaml base a nightmare — when signatures changed in an unstable dependency (e.g. function argument removed and nested inside another), the errors spat out by the typechecker were utterly incomphrehensible. This was largely due to automatic currying in OCaml — if I have a function call "some_function arg1 arg2" and "some_function" adds a third argument, that call becom…

> when signatures changed in an unstable dependency The problem is not OCaml here.

Yes because we all work in perfect world under optimal conditions.

Re: OCaml Programming: Correct and Efficient and Beautiful

#73
post #27

I found my experience trying to work with a large OCaml base a nightmare — when signatures changed in an unstable dependency (e.g. function argument removed and nested inside another), the errors spat out by the typechecker were utterly incomphrehensible. This was largely due to automatic currying in OCaml — if I have a function call "some_function arg1 arg2" and "some_function" adds a third argument, that call becom…

We develop a large OCaml application and find the error messages are fine. Changing signatures is an advantage when refactoring because it identifies all the places you need to make changes.

In addition I greatly prefer having a garbage collector around.

Re: OCaml Programming: Correct and Efficient and Beautiful

#74
post #65

Earlier quoted context omitted.

Berkeley's Programming Languages and Compilers references this book and you get to apply OCaml to something non-trivial. https://inst.eecs.berkeley.edu/~cs164/fa21/

It doesn't appear from your link that the course materials are available online though.

On the schedule page, there are links to further material. I don't think you can do the drills or exams, but you _can_ do the homework if you have a github account.

Re: OCaml Programming: Correct and Efficient and Beautiful

#75
very 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 wow jane street does epic hft in ocaml, then read real world ocaml 2e

if you think ocaml seems cool because wow they wrote coq/fstar/the early rust compiler in ocaml, then read cs3110

Re: OCaml Programming: Correct and Efficient and Beautiful

#76
post #22
post #17

Earlier quoted context omitted.

Which university? Does the course have a public webpage?

Not the original commenter, but my first year course of Introduction of Programming 15 years age was also using OCaml. There were two groups of students, standard one was using Pascal, and the functional one using OCaml. I was studying on Warsaw University and the lecture notes are in Polish: https://mimuw.edu.pl/~kubica/wpf/wpf.pdf

That was exactly the course that I took at the WU :) Fond memories.

Re: OCaml Programming: Correct and Efficient and Beautiful

#77
post #27

I found my experience trying to work with a large OCaml base a nightmare — when signatures changed in an unstable dependency (e.g. function argument removed and nested inside another), the errors spat out by the typechecker were utterly incomphrehensible. This was largely due to automatic currying in OCaml — if I have a function call "some_function arg1 arg2" and "some_function" adds a third argument, that call becom…

I think the issue is the compiler error messages being poor. Automatic currying is wonderful for productivity (in my experience).

Elm is not really an alternative to OCaml (or Rust) but it shows how nice compiler error messages can be.

Re: OCaml Programming: Correct and Efficient and Beautiful

#78
post #46

Earlier quoted context omitted.

yup, specific error message is here: https://news.ycombinator.com/item?id=31861450

Looks like that is exactly the error message predicted. It’s expecting a list of result values, but is getting a list of functions from some stuff to that result. IME, it’s definitely true that OCaml doesn’t have the didactic error messages that many have come to like in Rust et al. They said, imo they generally give the information needed solve problems and I like their concision. It takes a bit of time to learn to…

> It takes a bit of time to learn to read [OCaml's error messages]

Yeah, and I think you could say the same of Rust when it comes to the borrow checker's messages.

But in Rust's case the problem it's trying to describe is itself pretty complex. The complexity of OCaml's error messages are really not justified by the problem they're warning you about, which is itself very straight-forward.

Re: OCaml Programming: Correct and Efficient and Beautiful

#79

As a former OCaml hobbyist programmer my take on these kind of books or articles is that, yes OCaml is extremely elegant and beautiful as a programming language and it shines for simple applications. Some parts of it are actually not so elegant, for example the object oriented aspect completely spoil the elegance of the core language. On the other side OCaml, as a pure functional programming language with immutable v…

Concerning the issue with function arguments, this is one of the reason why OCaml has labelled arguments. And for instance, Janestreet's idiom udes labelled arguments as often as possible.

Similarly, I am not sure what is the issue with using imperative OCaml for imperative algorithms when they are a better fit for the problem at hand?

Re: OCaml Programming: Correct and Efficient and Beautiful

#80
post #60

Earlier 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:…

Not sure what you mean by "- OCaml vs Kotlin: no JVM needed." as Kotlin has support for native and JavaScript compilation, and WASM via native.

Maybe it's changed in the year or so since I looked at kotlin, but my impression when I did look at it was support for anything other than the JVM was definitely second class
Post reply on HN