Comments on: What’s the fuzz about ducktyping?

By: Frank

Frank — Fri, 23 Mar 2007 23:33:08 +0000

Thanks for the comments guys.

I can imagine ducktyping causing readability problems. Someone who relies too much on ducktyping could easily lose both his mind and the control he has on his own application. In fact, the link that Duck Skeptic put opened my eyes on some issues. In small doses (or just for testing/debugging), I’m still convinced that ducktyping is awesome. But I agree we should be careful of not overusing it. I’m going to experiment more on that to make up my mind.

I also really enjoyed the comment by Nate. Performance might be the catch, you’re right. However, I still ask to be proven that it can make an application run “dog-slow”. =) Of course, I guess it all depends on the level of performance you need. To me, a few milliseconds slower is still acceptable.

Thanks again for your input!

By: Duck Skeptic

Duck Skeptic — Fri, 23 Mar 2007 16:06:34 +0000

There are quite a few things wrong with duck typing, and code readability and maintenance is one of them. Read this for more details:

http://beust.com/weblog/archives/000269.html

By: dagny

dagny — Thu, 22 Mar 2007 15:12:02 +0000

Duck typing is a whole lot like late binding, where the object.method call is evaluated at the moment it is called. What’s very ruby-ish to me is adding a method to an instance of a class, vs adding a method to a class.

By: Nate

Nate — Thu, 22 Mar 2007 12:45:16 +0000

The catch is performance. Strong typing (including languages that do type inference, like Haskell) allow for compile-time binding to methods. This can allow for the actual call to the method to be decomposed a single JMP instruction. I’m not familiar with Ruby’s implementation of duck-typing specifically, but at best it will require a seek through the object’s method table, and at worst, it will require an operation on the level of reflection — which is essentially what you’re doing with the respond_to? statement, if I’m not mistaken.

There’s nothing WRONG with duck-typing, per se, but it trades off cpu cycles for programmer cycles. They said the same things about C vs. assembly, though, of course… :) Software engineering is all about understanding costs of certain actions, so as long as you recognize the cost of duck typing, then there’s no real problem with using it. (Although, Ruby doesn’t give you much of a choice…)

Beyond performance, my major issue with duck-typing and Ruby in particular is that it destroys the clarity that you get when using a strongly-typed language (say C#). In C#, if an object extends a given supertype or implements a given interface, it’s asserting that it supports the functionality of that subtype/interface. Said another way, an instance of the subtype IS an instance of the supertype. (This is referred to as the Liskov Substitution Principle.) Inheritance can be thought of as a contractual relationship between the inheriting type and any external code that consumes it — the type is offering a guarantee that it supports the functionality of the supertype.

With Ruby, you don’t get the same guarantees, since the contractual assertions are moved from the type level to the method level. All you’re REALLY doing is delaying the contractual checks from compile-time to run-time. This certainly makes it easier to write an application the first time, but it significantly raises the overall complexity of the project, making the application more difficult to maintain in the future. Not to mention making it run dog-slow… or is that duck-slow? :)

Just my opinion!