En un lenguaje con duck-typing, la función equivalente tomaría un objeto de cualquier tipo e invocaría los métodos caminar y parpar.
Los usuarios de lenguajes con tipificado estático al iniciarse con lenguajes de tipificado dinámico a menudo se ven tentados a agregar chequeos de tipo estáticos (previos a ejecución), desaprovechando la flexibilidad y beneficios del duck typing y restringiendo el dinamismo del lenguaje.
Si se traduce este algoritmo a Ruby o Python por ejemplo, el resultado de la ejecución será: Así, el duck typing permite polimorfismo sin herencia.
El único requerimiento de la función calcular para las variables es que soporten los métodos "+" y "*".
Las interfaces pueden proveer algunos de los beneficios del duck typing pero este es diferente en cuanto no se define explícitamente una interfaz.
Una crítica citada a menudo dice: Los defensores del duck typing como Guido van Rossum argumentan que el asunto se maneja con pruebas, y con el conocimiento del código necesario para mantenerlo.
[5][6] Las críticas acerca del duck typing tienden a ser casos especiales de aspectos más amplios relacionados con la disputa entre la tipificación estática y la dinámica.
En C# 4.0 el compilador y la ejecución colaboran para implementar dynamic member lookup.
Si un objeto no implementa un método solicitado, se arroja una excepción en tiempo de ejecución que puede ser capturada y manejada adecuadamente.
El estilo usual de desarrollo en Common Lisp (usando un Lisp REPL como SLIME) permite también la reparación interactiva: De este modo se puede desarrollar el software extendiendo código duck-typed que funciona parcialmente.