I'm not super familiar with OCaml but I have written a fair amount of code in F# which is supposedly based on / very similar to OCaml. In the end I had to convert it all to C# because none of the others developer at my company could grok it. I agree with you that the type inference is really neat but writing F# (and probably OCaml too) consistently in an imperative style is a bit of a pain in the back; it feels like the langauge is simply not meant to be used like that. And, as I said, functional programming is difficult and most programmers never even heard of it. (I wish I could use FP at work but jobs like that are really rare here in London.)
When writing code, sure. When reading and/or maintaining code, not so much. Especially when it stretches across function or method boundaries. Languages like C++ and C# have the right happy medium in my opinion: `auto`/`var` keywords for type-inferenced local variables, but explicit parameters and return types for all methods.
I think of type systems much more as a static analysis mechanism the compiler can use to identify programming mistakes rather than a concept that helps reading or maintaining code. In my opinion, in well written code the types of various symbols should be obvious due to the context, names, etc. without having to look at type names.
In theory, perhaps. But there is a lot more information in syntax than in names in my experience, such as the number of arguments to a function.
For example, suppose `f` is a function of type `int -> int -> int -> int`. In python, semantic differences are obvious between:
a = f(x, y, z)
b = functools.partial(f, x, y)
Where as in OCaml this difference is glossed over:
let a = f x y z;;
let b = f x y;;
Even though the names "f" and "x, y, z" are relatively evocative of their types, the two expressions are very different without any particular indication as to why.
That's why I think that there is a happy medium, where syntax is very helpful in determining types such that there is no need to give explicit types to "a" or "b" in these examples, but there is enough information explicitly available to declare that "f(x, y)" is an invalid function invocation, not a curried function of the type `int -> int`.
