Live data from Hacker News

OCaml Programming: Correct and Efficient and Beautiful

cs3110.github.io

61–70 of 251 posts

Re: OCaml Programming: Correct and Efficient and Beautiful

#61
post #51

Earlier quoted context omitted.

It doesn't look so bad to me. It's telling you that a list type was expected but you passed it a function that returns a list instead. You're right though that OCaml isn't the kind of language you can pick up in an afternoon.

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.

Re: OCaml Programming: Correct and Efficient and Beautiful

#62
post #46

Earlier quoted context omitted.

Do you have a more precise example in mind? The example that you are describing should emit an error message of the form This expression has type type_of_arg_3 -> return_type but an expression of type return_type was expected which seem alright to me. (But I cannot not be called an OCaml aficionado). The type error might be delayed in sufficiently polymorphism context but that is a more infrequent occurrence (outside…

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 read them however.

Re: OCaml Programming: Correct and Efficient and Beautiful

#63
post #46

Earlier quoted context omitted.

Do you have a more precise example in mind? The example that you are describing should emit an error message of the form This expression has type type_of_arg_3 -> return_type but an expression of type return_type was expected which seem alright to me. (But I cannot not be called an OCaml aficionado). The type error might be delayed in sufficiently polymorphism context but that is a more infrequent occurrence (outside…

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

Looks similar to what TypeScript will offer you.

Re: OCaml Programming: Correct and Efficient and Beautiful

#64
post #58
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…

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?

Re: OCaml Programming: Correct and Efficient and Beautiful

#65
post #2

I learned some Haskell years ago but it didn't stick with me. Lately, I want to get back into functional programming to see whether I'm missing out on something. This book looks nice, and so does OCaml. Any suggestions on books, courses, or resources on this subject? Also, just to get proper motivation, why should I learn functional programming as a capable Software Engineer?

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.

Re: OCaml Programming: Correct and Efficient and Beautiful

#66
post #58
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…

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.

Re: OCaml Programming: Correct and Efficient and Beautiful

#67
post #45

Earlier 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?

Yes, I think that's the issue.

I built a reasonably popular typechecker for PHP, so I have some experience with the DX for these sorts of programs. I don't think it's good for a couple of ASCII characters and line breaks to be the difference between an acceptable and an unacceptable type annotation. It requires, as you say, for the OCaml type system to be burned into people's minds for them to immediately spot the issue.

In a similar context Rust will just say "function expected 5 arguments, you gave it 4" which has a very obvious remediation.

Re: OCaml Programming: Correct and Efficient and Beautiful

#69
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 value by default doesn't scale well to large, complex application. Just the paradigm is no longer tenable and you need to switch at least partially to imperative programming with mutable variable. For example this is what it does the implementation of the OCaml itself.

To develop further the point about "what doesn't scale" there is also the function with unnamed arguments and currying. While extremely elegant for simple programs it gets confusing for real-world applications when function needs quite a lot of arguments and there is no longer any obvious order to give them. If you stick with that and you choose an order it becomes arbitrary, difficult to remember and currying no longer makes a lot of sense.

Functional programming with immutable values is a wrong pattern for programming languages. Many algorithms, almost all actually, are naturally expressed in imperative style with mutable arrays or variables.

What is needed is to bridge the good things from OCaml, the type system, the pattern matching with tagged types into a modern, imperative programming languages.

Rust is a sort of answer but they got it wrong because it is too low level about managing the memory, the ownership pardon, and everything else so programmers cannot just express the algorithm or the logic they want to implement but they have to spend a lot of mental energy thinking about ownership issues and unneeded accidental complexity like lifetime annotations.

Post reply on HN