What I wish I knew when learning OCaml (2018)
1–10 of 88 posts
Re: What I wish I knew when learning OCaml (2018)
#2A good list. ML languages push you (kicking and screaming) into the pit of success.
Re: What I wish I knew when learning OCaml (2018)
#3I tried OCaml a long time ago, and one of the things that really turned me off of it was all the inscrutable error messages. I went to #ocaml on Freenode for help, and when I had the error messages explained to me I asked how the person who explained them knew what they meant. He told me that the reason he knew was because he took a couple of semesters of type theory courses at his university. I didn't want to have to take a couple of semesters of type theory courses in order to be able to program effectively in this language. I hope the situation has improved since then.
The other thing I didn't like (which was something shared with other statically-typed languages) was feeling like I had to wrestle forever with the compiler to get my program to run. It just always felt so much easier to write programs in dynamically typed languages. Sure, my programs might have bugs in them, but I could iron them out over time, and my programs change so much anyway that pieces of buggy-but-working code in those dynamically typed languages might be replaced wholesale anyway before I even ran in to the bugs.. so the pace of prototyping in dynamically typed languages is much faster, in my experience.
Re: What I wish I knew when learning OCaml (2018)
#4A good list. ML languages push you (kicking and screaming) into the pit of success.
They're barely used in industry.
Re: What I wish I knew when learning OCaml (2018)
#5TIL that Ocaml/SML are compiled into lambda expressions... I literally thought lambda calculus is only used in CS classes.
OCaml's syntax is pretty annoying but type inference is actually amazing.. I changed my mind over it, as previously I thought explicit type annotations are simpler. Turns out, it would be humanly impossible to explicitly annotate every piece of OCaml, just let the compiler do it for you
Re: What I wish I knew when learning OCaml (2018)
#6I tried OCaml a long time ago, and one of the things that really turned me off of it was all the inscrutable error messages. I went to #ocaml on Freenode for help, and when I had the error messages explained to me I asked how the person who explained them knew what they meant. He told me that the reason he knew was because he took a couple of semesters of type theory courses at his university. I didn't want to have t…
I think both of these points can be alleviated with certain coding habits that come with practice. For instance, adding type annotations in some places will help with error messages. And using "assert false" (which has type 'a) will let you run an incomplete/broken program.
As for the error messages requiring expertise in type theory, it sounds as an exaggeration, esp. when not using advanced features.
Re: What I wish I knew when learning OCaml (2018)
#7I tried OCaml a long time ago, and one of the things that really turned me off of it was all the inscrutable error messages. I went to #ocaml on Freenode for help, and when I had the error messages explained to me I asked how the person who explained them knew what they meant. He told me that the reason he knew was because he took a couple of semesters of type theory courses at his university. I didn't want to have t…
I think both of these points can be alleviated with certain coding habits that come with practice. For instance, adding type annotations in some places will help with error messages. And using "assert false" (which has type 'a) will let you run an incomplete/broken program. As for the error messages requiring expertise in type theory, it sounds as an exaggeration, esp. when not using advanced features.
"adding type annotations in some places will help with error messages."
I annotated the hell out of my programs, and completely avoided OCaml's type inference as much as I could because I saw that it could not guess what I meant. I still had tons of problems understanding the error messages.
Error messages like "This expression is of type X but an expression was expected of type X" were not uncommon, and super frustrating.
Re: What I wish I knew when learning OCaml (2018)
#8I tried OCaml a long time ago, and one of the things that really turned me off of it was all the inscrutable error messages. I went to #ocaml on Freenode for help, and when I had the error messages explained to me I asked how the person who explained them knew what they meant. He told me that the reason he knew was because he took a couple of semesters of type theory courses at his university. I didn't want to have t…
I guess inscrutable error messages are a "feature" of ML-like languages. I have not used OCaml yet, but the first few years with Haskell probably have been just as rough in terms of parsing type errors.
Haskell has a few niceties when trying to debug type errors nowadays. For example typed holes that allows one to spice in `_` within code and the compiler will tell you what type it expects you to replace that hole with, alleviating many issues I had previously. But in the same sense I'm in agreement with you, and I've been more productive when writing Guile/Chicken Scheme code for small tools.
Interestingly I've binged on OCaml videos recently, because I would find it interesting to work with it some day. From a distance what I like about it (aside from the functional language goodness) is that it supports objects, has row polymorphism, optional arguments, and imperative constructs (I sure like my mutation heavy for/while loops when prototyping code).
Re: What I wish I knew when learning OCaml (2018)
#9Earlier quoted context omitted.
I think both of these points can be alleviated with certain coding habits that come with practice. For instance, adding type annotations in some places will help with error messages. And using "assert false" (which has type 'a) will let you run an incomplete/broken program. As for the error messages requiring expertise in type theory, it sounds as an exaggeration, esp. when not using advanced features.
"adding type annotations in some places will help with error messages." I annotated the hell out of my programs, and completely avoided OCaml's type inference as much as I could because I saw that it could not guess what I meant. I still had tons of problems understanding the error messages. Error messages like "This expression is of type X but an expression was expected of type X" were not uncommon, and super frustr…
> I annotated the hell out of my programs, and completely avoided OCaml's type inference as much as I could because I saw that it could not guess what I meant.
The type checker and the type inference parts of the compiler are one and the same. If the type checker can’t infer what you mean you are most likely writing invalid code.
> Error messages like "This expression is of type X but an expression was expected of type X" were not uncommon, and super frustrating.
Ocaml is a strongly typed static language. As such your code has to respect type constraints. It’s very much a feature not a bug.
Still to be less defensive I too sometimes wish the error messages were more clear in highlighting why a certain type was expected but at least Ocaml provides tooling to live check the inferred type of any sub-expression while you edit your code.
Re: What I wish I knew when learning OCaml (2018)
#10A good list. ML languages push you (kicking and screaming) into the pit of success.
They're barely used in industry.
I wonder why this is the case. Ocaml syntax doesn't seem very arcane, it is not hell-bent on functional purism and pragmatically allows for imperative code. Performance seems quite reasonable.
What does it lack that prevented it from gaining wider acceptance? Surely buy-in from a large company was an issue, but even F# hasn't seen any significant uptake. Is it really the lack of curly brackets? That didn't stop Python...
Is it just that being labelled 'functional' was a huge stigma for a very long time?