I don't understand what the phrase "you either have it or you don't" means.
Not having something can cause significant departures in logic (or make some operations altogether impossible or meaningless). The ability to insist that a value is present is extremely valuable because it dramatically simplifies the specification of a unit and dramatically simplifies its implementation. More importantly, it dramatically simplifies the review and understanding of code, since types are the best source of trustworthy information about your code (Every day I curse the inability for me to ensure fields aren't null in Java, because I have to spend so much time manually determining whether or not they are, and most of the time I still don't end up very sure)
Further, as specifications change, types are a help, not a hindrance. If you change a business requirement which leads to many files needing to be changed because their types are now in conflict with the new business requirement... Then those files are wrong under the new business requirement. They would be wrong in a dynamically typed language too! It's just that in a dynamically typed language, you would never know! And, in the statically typed language, you have accurate refactoring tools which can safely manage large, multi file changes which have to be done manual in a dynamically typed language.
Cool, agreed on all points. I suppose I'm thrown because, as Michael said, I can see the logic behind most other Hickey quotes. This one just doesn't seem like a useful or relevant statement to me, neither a point for or against dynamic typing. It's just kinda nonsensical.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I don't understand what the phrase "you either have it or you don't" means.
Not having something can cause significant departures in logic (or make some operations altogether impossible or meaningless). The ability to insist that a value is present is extremely valuable because it dramatically simplifies the specification of a unit and dramatically simplifies its implementation. More importantly, it dramatically simplifies the review and understanding of code, since types are the best source of trustworthy information about your code (Every day I curse the inability for me to ensure fields aren't
nullin Java, because I have to spend so much time manually determining whether or not they are, and most of the time I still don't end up very sure)Further, as specifications change, types are a help, not a hindrance. If you change a business requirement which leads to many files needing to be changed because their types are now in conflict with the new business requirement... Then those files are wrong under the new business requirement. They would be wrong in a dynamically typed language too! It's just that in a dynamically typed language, you would never know! And, in the statically typed language, you have accurate refactoring tools which can safely manage large, multi file changes which have to be done manual in a dynamically typed language.
Cool, agreed on all points. I suppose I'm thrown because, as Michael said, I can see the logic behind most other Hickey quotes. This one just doesn't seem like a useful or relevant statement to me, neither a point for or against dynamic typing. It's just kinda nonsensical.