2 ms·
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
by octachron 4y ago
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 anymore. Moreover, those delayed mistake are here to allow room for an expressiveness that you are not using yet. This is a genuinely frustrating situation. And I do hope to improve OCaml type error messages to better highlight type difference at some point in the future.
- muglug 4y agoThanks 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.
- yawaramin 4y ago> 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. That's exactly the style OCaml excels at. > OCaml currently seems great for people who are better at getting it mostly-right first time That's because they got it wrong a lot at first, then learned how to get it right. You've heard of people talking about how they internalized the Rust borrow checker's rules after some time, right? Well, internalizing a typechecker's inference rules works very similarly (faster if you read OP). > I’ve seen a lot of OCaml code written by people with PhDs and backgrounds in type theory. That's unfortunate, it's a nearly perfect language for industrial work. Tiny example of how easy it is to hack together useful tools with it: https://dev.to/yawaramin/practical-ocaml-314j#proof-of-concept https://dev.to/yawaramin/practical-ocaml-314j#proof-of-conce...