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

201–210 of 251 posts

Re: OCaml Programming: Correct and Efficient and Beautiful

#201

Post by Akronymus »

muglug wrote: post #78
abathologist wrote: post #62

Earlier quoted context omitted.

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.

To me, the previously linked error message seems pretty clear.

Re: OCaml Programming: Correct and Efficient and Beautiful

#202

Post by Akronymus »

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

What about ocaml vs f#?

Re: OCaml Programming: Correct and Efficient and Beautiful

#203

Post by 0x69420 »

laylomo2 wrote: post #194
0x69420 wrote: post #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 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.

sure, but if it's the reader's first introduction to the language (which rwo is positioned as), the reader is in a uniquely bad position to discern justified best practices from arbitrary ones, and truths about the language from opinions about it

learning the language first, then someone's ideas about how it should be written (in this case, as encoded in a replacement standard library with a special module dedicated to making any call to the actual standard library throw a compile error), gives you the requisite context to understand the latter

Re: OCaml Programming: Correct and Efficient and Beautiful

#204

Post by muglug »

octachron wrote: post #164
ahmedalsudani wrote: post #152

Earlier quoted context omitted.

Rust is a different language with a different audience. If a functional language is presented today that does not automatically curry calls, I have no interest. Just because the tool does not work for you does not mean there's a defect in the design.

I think that it is better to not forget that expressiveness comes at the cost of a richer world of misbehaving code. If you are used to a world where functions have more than one argument and must be applied to exactly the right number of arguments and nearly never returns another function, starting a curried language suddenly throws you in a situation where many small mistakes like `plus 1` are not caught early anym…

Thanks for the work you’re doing — though it’s mostly too late for me, good to know that people are putting a lot of thought into these questions.

The sense I have got from my experience is that OCaml is a great language for people who are slightly less error-prone than I am.

My style of coding is to write a lot of slightly dodgy code in one breath, then use the typechecker to tell me all the things I got wrong. Even in a language I’m very familiar in there’s still a lot of trial and error.

OCaml currently seems great for people who are better at getting it mostly-right first time — I’ve seen a lot of OCaml code written by people with PhDs and backgrounds in type theory. Most other languages don’t have that sort of academic pedigree.

Re: OCaml Programming: Correct and Efficient and Beautiful

#205

Post by haskellandchill »

omginternets wrote: post #189

Forgive this tangential question, but does anyone know of a practically-oriented tutorial for implementing an ML-style language? Any format is fine, as are books.

There's "Modern Compiler Implementation in ML" which has a section on making the example language Tiger a pure functional language. I don't have "Compiling with Continuations" but that might be even more appropriate.

Re: OCaml Programming: Correct and Efficient and Beautiful

#206

Post by zem »

pjmlp wrote: post #105
lairv wrote: post #44

Earlier quoted context omitted.

Nope, I must say I have only used a small subset of languages from the FP-language-zoo, so my opinion on OCaml might be biased But as an example when writing Typescript, I feel so frustrated of not having a clean way of doing pattern-matching

You will have to wait for JavaScript to add it first. The whole point of Typescript and why it is so successful, is because they only add type system on top of JavaScript. Pattern matching would introduce new language constructs beyond what is required for defining types.

I think as long as they maintained it as a proper superset of javascript (i.e. all js code was valid ts code), adding a new language construct wouldn't hurt them much. see kotlin vs Java for a similar case

Re: OCaml Programming: Correct and Efficient and Beautiful

#207

Post by wiseowise »

acchow wrote: post #150
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.

Stockholm syndrome arrives quite quick in this case, as you become accustomed to this form as meaning "you're missing an arg" I agree the first 6 months of this is mind-numbingly frustrating.

What does Stockholm syndrome even have to do with this?

Re: OCaml Programming: Correct and Efficient and Beautiful

#208

Post by wiseowise »

shikoba wrote: post #169
c-cube wrote: post #148

Earlier quoted context omitted.

This is old advice :-). Use the LSP server and dune and the error displays instantly, no further setup required.

I don't get it. Is it sarcasm?

No. You don't need this anymore.

> You can use -annot or -bin-annot when compiling and the Tuareg function caml-types-show-type in Emacs will be your best friend.

Just open OCaml program in some editor with LSP(Vim, NeoVim, VS Code, Emacs) and it will instantly show you the error.

Re: OCaml Programming: Correct and Efficient and Beautiful

#209

Post by wiseowise »

water8 wrote: post #21
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:…

OCaml vs All: Good luck finding developers that will write quality code and not cost a fortune each.

> Good luck finding developers that will write quality code and not cost a fortune each.

You pick one regardless of language. Not sure what's your point here.

Post reply on HN