Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OCaml Programming: Correct and Efficient and Beautiful

cs3110.github.io

Post reply on HN
Print view View original

51–60 of 251 posts

Re: OCaml Programming: Correct and Efficient and Beautiful

#51

Post by tgflynn »

muglug wrote: post #45
munchler wrote: post #34

Earlier quoted context omitted.

FWIW, F# is very similar to OCaml, but its error message in this case is usually quite clear. E.g. This expression was expected to have type 'int' but here has type 'string -> int'

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.

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.

Re: OCaml Programming: Correct and Efficient and Beautiful

#52

Post by tgflynn »

muglug wrote: 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…

From what I've seen of Rust though it adds its own brand of complexity due to its basic requirement for maximal efficiency which precludes having a garbage collector.

I don't think I would want to use Rust unless I really needed a language with near optimal performance. OCaml on the other hand seems suitable for programs where correctness is important but performance isn't the driving concern. At least I'm considering using it for that type of application, though I'm not yet a serious OCaml programmer (still working my way through this course actually).

Re: OCaml Programming: Correct and Efficient and Beautiful

#53

Post by toastal »

zaptrem wrote: post #50

I took this class last semester. Michael Clarkson is an awesome professor. After learning OCaml I want pattern matching in JavaScript! Beyond the language itself, it absolutely made me a better programmer.

Pattern matching without ADTs though loses a lot of the power. The fact that you'd still have to handle null/undefined cases means it's still annoying to use and hardly exhaustive.

Re: OCaml Programming: Correct and Efficient and Beautiful

#54

Post by octachron »

muglug wrote: post #45
munchler wrote: post #34

Earlier quoted context omitted.

FWIW, F# is very similar to OCaml, but its error message in this case is usually quite clear. E.g. This expression was expected to have type 'int' but here has type 'string -> int'

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?

Re: OCaml Programming: Correct and Efficient and Beautiful

#55

Post by imajoredinecon »

tgflynn wrote: post #51
muglug wrote: 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.

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

Re: OCaml Programming: Correct and Efficient and Beautiful

#56

Post by tgflynn »

throwamon wrote: post #29
toolslive wrote: post #16

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

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

Re: OCaml Programming: Correct and Efficient and Beautiful

#57

Post by eckza »

shadowgovt wrote: post #36
muglug wrote: 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…

This mirrors my experience in SML/NJ, where for the longest time the most common error message the compiler would spit out was 'tycon mismatch' and a Google search would not tell you what a tycon was (it's a type constructor). I think, unfortunately, I've observed a pattern in much functional programming (F# being a blessed exception) that relatively excellent computer language designers suffer from the utter ineptit…

If you ever do any frontend work, you should give Elm a try. The tooling is lightweight but effective; and the compiler error messages are best-in-class.

Re: OCaml Programming: Correct and Efficient and Beautiful

#58

Post by wyager »

muglug wrote: 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.

Re: OCaml Programming: Correct and Efficient and Beautiful

#59

Post by tgflynn »

This is a very specific question but I thought I'd ask it here on the chance someone might have a good answer.

I've been slowly working my way through this course and I ran into an issue recently when I upgraded my OCaml installation to the latest version (4.13.1). With this version I find that the simple instructions for building an executable with dune (especially one that uses OUnit) given here https://cs3110.github.io/textbook/chapters/data/ounit.html no longer work.

It seems dune now requires you to initialize a project. Does anyone know how to translate the instructions in the course to the current version of dune ?

I realize I could install an opam switch for the previous version but I'd rather be working with the latest one.

Just hoping someone might be able to save me an hour or so figuring this out on my own.

Re: OCaml Programming: Correct and Efficient and Beautiful

#60

Post by twh270 »

toolslive wrote: post #16
xyproto wrote: post #14

Earlier quoted context omitted.

I also find it hard to spot why OCaml is the natural "step up" for creating real world applications instead of Haskell, Rust, Clojure or even Kotlin, C++, Python and Go.

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.
Post reply on HN