1. 8

  2. 7

    My thought is that “duck typing” in Ruby is merely a consequence of object polymorphism. Like Smalltalk that so influenced it, Ruby allows requests (messages) to be sent to an object which might handle them or not. For example, one might have a collection of objects and request that each “fly”. Whether they can or not is determined at runtime.

    So I contend that it doesn’t “encourage it”. Rather “duck typing” in this context is a name indicative of how object polymophism in Ruby is achieved.

    1. 12

      “Duck Typing” is just interfaces without the type system.

      An interface is a set of methods implemented by an object. An object can be explicitly declared as fulfilling an interface (like in Java) or it can be implicit if the object implements all off the interface’s methods (structural typing, like in Go).

      The problem with doing this with dynamic languages is, of course, that you won’t know if your object correctly implements all of the interface until runtime. Worse, with “Duck Typing”, there is no formal definition of the protocol that you can check, even at runtime.

      In SmallTalk, interfaces are called “protocols” (in fact that’s the name I typically use to talk about that concept, even though I include a little bit more in the notion that just the interface, but I digress). The fact that protocols are not formalized in SmallTalk is not a design choice, see Future Work here:

      [In Smalltalk-80] message protocols have not been formalized. The organization provides for protocols, but it is currently only a matter of style for protocols to be consistent from one class to another. This can be remedied easily by providing proper protocol objects that can be consistently shared. This will then allow formal typing of variables by protocol without losing the advantages of polymorphism.

      Incidentally, it looks like Pharo did formalize protocols.

      This is not to say that using Duck Typing in languages that provide no typed option for structural typing is bad, but a little more formalism and safety cannot hurt in that respect.

      1. 6

        Ruby - the project and community - does encourage it, through it’s use in the stdlib and in general practice.

        Interestingly, this hasn’t always been the case, the push towards making Ruby a duck-typing ecosystem and adopting it as a strategy was with 1.8, shortly before Rails. See https://viewsourcecode.org/why/hacking/rubyOneEightOh.html, “Duck typing and to_str”

        1. 1


          Also, I feel that it’s natural to use duck typing in the context of a dynamically typed & fully object-oriented language such as Ruby.

        2. 4

          It lets a maximum of control to the developer. The developer is responsible of the code that it produces.

          In an article that seems to be contrasting static and dynamic typing, this strikes me as wrong. The alternatives (to duck typing) don’t lack control.

          1. 3

            Speaking in vague enough terms allows one to seldom be wrong.

            That’s a reason why you should always be wary of an “engineer” describing a technology as “expressive”, or “it gives me freedom/control”.

          2. 1

            Ad-hoc polymorphism is a side effect of dynamic languages. Since the compiler generally doesn’t make any guarantees about the types that flow through your code, you’re effectively always practicing duck typing even when you don’t mean to.