An excerpt (original emphasis): "Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark...What it says is that he finds writing containers like lists of ints and maps of strings an unbearable burden. I find that an odd claim. I spend very little of my programming time struggling with those issues, even in languages without generic types...But more important, what it says is that types are the way to lift that burden. Types. Not polymorphic functions or language primitives or helpers of other kinds, but types."
It seems to me that people program heavily with types because that's what compilers are really good at. Therefore that's what most languages give us. But I don't want to be constructing huge, complex type hierarchies with every application. If I'm spending more time on that than the actual problem domain, generic type systems are more of a problem than a solution. I don't use a hammer because I love driving in nails, I use it because it's the best way to stick two pieces of wood together.
(edit: perhaps I should clarify that I'm referring to type hierarchies within the application itself as an intrinsic part of design, not language type hierarchies)
> It seems to me that people program heavily with types because that's what compilers are really good at. Therefore that's what most languages give us. But I don't want to be constructing huge, complex type hierarchies with every application
That makes no sense, most languages with good generics support barely have type hierarchies (let alone complex one).
What's wrong to think that types are important? From mathematical point of view, types are interpreted as theorem statements and functions(values) that typecheck are considered proofs of those theorems. Types are fundamental.
I don't disagree. I'm not saying types are bad or unneeded, simply that they can be overused. I think we are encouraged to use types to solve so many problems because they're one of the few things that compilers can easily check, rather than because types are the optimal solution.
An excerpt (original emphasis): "Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark...What it says is that he finds writing containers like lists of ints and maps of strings an unbearable burden. I find that an odd claim. I spend very little of my programming time struggling with those issues, even in languages without generic types...But more important, what it says is that types are the way to lift that burden. Types. Not polymorphic functions or language primitives or helpers of other kinds, but types."
It seems to me that people program heavily with types because that's what compilers are really good at. Therefore that's what most languages give us. But I don't want to be constructing huge, complex type hierarchies with every application. If I'm spending more time on that than the actual problem domain, generic type systems are more of a problem than a solution. I don't use a hammer because I love driving in nails, I use it because it's the best way to stick two pieces of wood together.
(edit: perhaps I should clarify that I'm referring to type hierarchies within the application itself as an intrinsic part of design, not language type hierarchies)