I'm not sure I follow the argument (or agree with where the author places the blame).
Notwithstanding Ruby's handling of type safety or its implementation of arrays, isn't it my job (as the programmer) to know what kind of object I'm getting from the helper library? That is, when I get 'h' (in his example), the black box is how 'h' gets filled, not what kind of collection object it is.
Duck typing basically assumes that the programmer knows what he is doing. Duck typing especially assumes that the programmer does things more clever than a static type system would be able to express right now. But that is fine. Since this is duck typing, the programmer knows what he is doing by assumption.
Of course, however, this works in both directions. Duck typing puts a lot of burden on the programmer. Yes, you don't have to annotate things with types, but in fact, you have to worry MORE about types than using a statically typed language. In a statically typed language with type annotations all over the place, the compiler checks for simple and maybe even less simple errors. If you have duck typing, the programmer needs to do this work, by defining clear interfaces with clear documentations about the expected behavior of an object passed in here or returned over there.
In my opinion, this is again an instance of more defensive or more aggressive languages. Duck typing is more aggressive, as it requires more care of the programmer but allows the programmer to do more things, while static typing requires less care, but allows less things.
"If you have duck typing, the programmer needs to do this work, by defining clear interfaces with clear documentations about the expected behavior of an object passed in here or returned over there."
A compiler does not define clear interfaces with clear documentation for you. If you are implying that to use duck typing, this is more likely to be done by a programmer then this is a good thing; no matter what the typing.
In practice duck typing helps to get rid of needless duplication, and extended class hierarchies in code, and proponents would state that less code is easier to verify.
Yes, it's your job to know these things. But when you make a simple mistake like this one, duck typing can hide it and make its effects much more serious.
5 comments
[ 3.9 ms ] story [ 22.9 ms ] threadNotwithstanding Ruby's handling of type safety or its implementation of arrays, isn't it my job (as the programmer) to know what kind of object I'm getting from the helper library? That is, when I get 'h' (in his example), the black box is how 'h' gets filled, not what kind of collection object it is.
Or am I confused?
Duck typing basically assumes that the programmer knows what he is doing. Duck typing especially assumes that the programmer does things more clever than a static type system would be able to express right now. But that is fine. Since this is duck typing, the programmer knows what he is doing by assumption.
Of course, however, this works in both directions. Duck typing puts a lot of burden on the programmer. Yes, you don't have to annotate things with types, but in fact, you have to worry MORE about types than using a statically typed language. In a statically typed language with type annotations all over the place, the compiler checks for simple and maybe even less simple errors. If you have duck typing, the programmer needs to do this work, by defining clear interfaces with clear documentations about the expected behavior of an object passed in here or returned over there.
In my opinion, this is again an instance of more defensive or more aggressive languages. Duck typing is more aggressive, as it requires more care of the programmer but allows the programmer to do more things, while static typing requires less care, but allows less things.
"If you have duck typing, the programmer needs to do this work, by defining clear interfaces with clear documentations about the expected behavior of an object passed in here or returned over there."
A compiler does not define clear interfaces with clear documentation for you. If you are implying that to use duck typing, this is more likely to be done by a programmer then this is a good thing; no matter what the typing.
In practice duck typing helps to get rid of needless duplication, and extended class hierarchies in code, and proponents would state that less code is easier to verify.
- Paddy.