Earlier quoted context omitted.
They're barely used in industry.
But look at their influence: TypeScript and Rust, not to mention Elm, PureScript and other less mainstream languages
What I wish I knew when learning OCaml (2018)
21–30 of 88 posts
Re: What I wish I knew when learning OCaml (2018)
#22Re: What I wish I knew when learning OCaml (2018)
#23I 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)
#24Earlier quoted context omitted.
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 Pytho…
The syntax is not great, the standard library is very sparse, and the error messages from the compiler and interpreter are terrible (and used to be worse). The OCaml team used to treat the native code compiler (ocamlopt) as a second-class citizen, but it's the implementation that matters for performance. Since the end of Dennard scaling about 15 years ago, OCaml's lack of multithreading has also been a pain point, on…
Re: What I wish I knew when learning OCaml (2018)
#25Earlier 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…
That particular error message has been gone from OCaml for years now.
Re: What I wish I knew when learning OCaml (2018)
#26Earlier quoted context omitted.
> 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 ty…
> 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. That's reasonable if the error message were "This expression is of type X but an expression was expected of type Y ". But the worst error message in the OCaml interactive toplevel is when they're the same. This happened when you defined a new type named X (which, incidentally, must be lo…
Re: What I wish I knew when learning OCaml (2018)
#27The article says "::" is a Data Constructor. I can make sense of type 'a = Left of 'a | Right of 'a where Right and Left are the Data constructors but I don't see the link with the part I don't understand.
Re: What I wish I knew when learning OCaml (2018)
#28Earlier quoted context omitted.
> 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. That's reasonable if the error message were "This expression is of type X but an expression was expected of type Y ". But the worst error message in the OCaml interactive toplevel is when they're the same. This happened when you defined a new type named X (which, incidentally, must be lo…
Yeah if you did this now you’d get something like “this expression is of type t/1 but an expression of type t/2” to disambiguate.
Re: What I wish I knew when learning OCaml (2018)
#29Could someone please explain ? : type 'a list = 'a :: 'a list | [] The article says "::" is a Data Constructor. I can make sense of type 'a = Left of 'a | Right of 'a where Right and Left are the Data constructors but I don't see the link with the part I don't understand.
type 'a list = Cons of 'a * 'a list | Tail
...but with a fancy syntax for Cons and Tail.Re: What I wish I knew when learning OCaml (2018)
#30Could someone please explain ? : type 'a list = 'a :: 'a list | [] The article says "::" is a Data Constructor. I can make sense of type 'a = Left of 'a | Right of 'a where Right and Left are the Data constructors but I don't see the link with the part I don't understand.
Two pieces of data (with the constructor ::) with 1 being the head of the list (type 'a) and one being the tail of the list (type 'a list, a recursive definition).
:: is an allowed identifier in oCaml. If that is not allowed, the typical names are Cons for :: and Nil for []