4 ms·

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 hel

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.

pmoriarty 5y ago
"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.
- WastingMyTime89 5y ago
  > 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.
  - pmoriarty 5y ago
    "you are most likely writing invalid code" Of course I'm writing invalid code: that's why I'm getting error messages. The problem is that I'm having trouble understanding why it's invalid. Error messages are supposed to help me here, but quite often they didn't.. they just led to more confusion... especially in complex code, where I needed help and clarity most.
  - kragen 5y ago
    > 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 lowercase), but there were still references to things of the old type X. I think this has been fixed in recent versions of OCaml.
    - poorlydefined 5y ago
      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.
      - kragen 5y ago
        The fact that this problem took 25 years to fix is maybe the more damning thing. It wasn't a bug, exactly; it was a usability problem. Clearer demonstrations of development priorities could hardly be given.
        octachron 5y ago
        That was mostly a man-power issue. The good news is that nowadays such nonsensical error messages are near the top of my personal development priority for OCaml.
        kragen 5y ago
        During those 25 years OCaml gained native-code compilers for new architectures, labeled arguments, and polymorphic variants, among other things. How could it be mostly a manpower issue?
        octachron 5y ago
        Work and time contributed by open source collaborators on their free or academic time cannot be magically converted from one subsystem to another. It is honestly very easy to have progress on the aspects that spark interest while some subsystem are starved from attention when there are no full-time developers working on a project.
- gmfawcett 5y ago
  > Error messages like "This expression is of type X but an expression was expected of type X" were not uncommon, and super frustrating. That particular error message has been gone from OCaml for years now.
- kripke 5y ago
  There is a balance to find between not enough annotations and too much annotations that one has to find. My algorithm is to write few annotations by default, and my answer to error messages I do not understand is to add "obvious" annotations (e.g. type of arguments) to tell type inference what I expect. Rarely does that solve the underlying issue, but it often makes the error message much clearer. With experience, I am more or less able to preemptively add the annotations that will probably help (e.g. aiming avoid accidentally polymorphic functions, the return type of mutually recursive functions, etc.). I don't think I have ever gotten "This expression is of type X but an expression was expected of type X" outside of the toplevel with type re-definitions, and recent OCaml versions have a nice error message for this now: Error: This expression has type t/1 but an expression was expected of type t/2 Hint: The type t has been defined multiple times in this toplevel session. Some toplevel values still refer to old versions of this type. Did you try to redefine them? In general the error messages have been continuously improving in recent years.
kragen 5y ago
Hey, thanks for that "assert false" trick! I never knew that! I don't know much about type theory but I did eventually manage to learn to interpret OCaml's type errors well enough to get things to compile. It still feels like driving a car by scraping it along a highway guardrail but it's often better than testing. I have to write twice as much code as in Python, it takes me longer to get it to run, and I still can't call it from C or Lua, but it runs twenty times as fast as Python and the process of thinking through the types helps me a lot to write code that works. I keep hoping I'll internalize the type system enough that my programs run the first time they way they do in Python, but it hasn't happened yet. I still often write a prototype in Python, though.
- legobmw99 5y ago
  OCaml also has a built in function failwith: string -> ‘a, so you can print an error in those cases. If it’s a code path you ever think will execute, failwith “some error here” is probably better than assert false
baby 5y ago
Ah! Didn't know the `assert false` trick. I believe `failwith "..."` will not always allow you to run the program

pmoriarty 5y ago

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

WastingMyTime89 5y ago
> 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.
- pmoriarty 5y ago
  "you are most likely writing invalid code" Of course I'm writing invalid code: that's why I'm getting error messages. The problem is that I'm having trouble understanding why it's invalid. Error messages are supposed to help me here, but quite often they didn't.. they just led to more confusion... especially in complex code, where I needed help and clarity most.
- kragen 5y ago
  > 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 lowercase), but there were still references to things of the old type X. I think this has been fixed in recent versions of OCaml.
  - poorlydefined 5y ago
    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.
    - kragen 5y ago
      The fact that this problem took 25 years to fix is maybe the more damning thing. It wasn't a bug, exactly; it was a usability problem. Clearer demonstrations of development priorities could hardly be given.
      - octachron 5y ago
        That was mostly a man-power issue. The good news is that nowadays such nonsensical error messages are near the top of my personal development priority for OCaml.
        kragen 5y ago
        During those 25 years OCaml gained native-code compilers for new architectures, labeled arguments, and polymorphic variants, among other things. How could it be mostly a manpower issue?
        octachron 5y ago
        Work and time contributed by open source collaborators on their free or academic time cannot be magically converted from one subsystem to another. It is honestly very easy to have progress on the aspects that spark interest while some subsystem are starved from attention when there are no full-time developers working on a project.
gmfawcett 5y ago
> Error messages like "This expression is of type X but an expression was expected of type X" were not uncommon, and super frustrating. That particular error message has been gone from OCaml for years now.
kripke 5y ago
There is a balance to find between not enough annotations and too much annotations that one has to find. My algorithm is to write few annotations by default, and my answer to error messages I do not understand is to add "obvious" annotations (e.g. type of arguments) to tell type inference what I expect. Rarely does that solve the underlying issue, but it often makes the error message much clearer. With experience, I am more or less able to preemptively add the annotations that will probably help (e.g. aiming avoid accidentally polymorphic functions, the return type of mutually recursive functions, etc.). I don't think I have ever gotten "This expression is of type X but an expression was expected of type X" outside of the toplevel with type re-definitions, and recent OCaml versions have a nice error message for this now: Error: This expression has type t/1 but an expression was expected of type t/2 Hint: The type t has been defined multiple times in this toplevel session. Some toplevel values still refer to old versions of this type. Did you try to redefine them? In general the error messages have been continuously improving in recent years.

kragen 5y ago

Hey, thanks for that "assert false" trick! I never knew that! I don't know much about type theory but I did eventually manage to learn to interpret OCaml's type errors well enough to get things to compile. It still feels like driving a car by scraping it along a highway guardrail but it's often better than testing. I have to write twice as much code as in Python, it takes me longer to get it to run, and I still can't call it from C or Lua, but it runs twenty times as fast as Python and the process of thinking through the types helps me a lot to write code that works. I keep hoping I'll internalize the type system enough that my programs run the first time they way they do in Python, but it hasn't happened yet. I still often write a prototype in Python, though.

legobmw99 5y ago
OCaml also has a built in function failwith: string -> ‘a, so you can print an error in those cases. If it’s a code path you ever think will execute, failwith “some error here” is probably better than assert false

baby 5y ago

Ah! Didn't know the `assert false` trick. I believe `failwith "..."` will not always allow you to run the program