Having started with C++, I was intrigued and interested in the possible uses for duck typing and runtime evaluation. These tend to appear together in dynamically-typed, interpreted languages and do not appear in statically-typed, compiled languages. There are exceptions such as C#, a statically-typed language that allows duck typing. After using several languages supporting these features, I have realized few legitimate uses. In this article, I explain my conclusions and suggest what I believe the appropriate uses are. Please feel free to express your views in the comments.
Duck Typing versus Interfaces
When I started studying C#, I found it interesting how you can take an object of an unknown type and attempt to call any method on it (see C#’s dynamic) . Later on, after finding many benefits of polymorphism and interface contracts, I failed to recognize why you would be willing to lose the elegant governance of interfaces and when you would ever need a “duck type.” As far as I can tell, there is no operation you would want to perform on an object of unrestricted type. Would you hire someone before knowing their skills? If you can write the method ahead of time, then you can predict what operations the object must support and thus what interfaces it must implement. If the interfaces it implements—the contracts it obeys—are not matching the method’s parameter type, you can always wrap it an an adapter.
Runtime Evaluation
After discovering some languages can execute code created dynamically with an eval() statement, I seeked cases where I would want to use it. With much consideration, it seems there are few benefits other than allowing a user extensive control over a program.
It would make no sense to use an eval() call on a hard-coded string. That isn’t to say it has never been utilized in such a way. Under normal circumstances, you can just paste such string’s contents in the code as code. Alternative behaviors in code can be implemented using regular flow control. The only case runtime evaluation is needed is when some piece of code is not known at compile time, and therefore, determined by an external source. An example of such case is when you need a program to be user-extended or customized.
While the concept may be tempting, I will most likely not use it as it is rare to encounter one of its more suitable scenarios.
What Is Duck Typing Good For?
I don’t doubt that a lot of very useful frameworks utilize duck typing. However, if duck typing did not exist, a more structured design would have been used.
The one benefit I see in duck typing is for rapid prototyping. Having less temptation to think about types, contracts, and object hierarchies reduces analysis paralysis and speeds up development. The lack of type safety and clever structure can be remedied easily after patterns emerge in a mostly procedural-style draft. Instead of having to change both the argument sent to a method and the type of the parameter, you can just change the argument.
An upcoming article on my preference of Python over Java will illustrate this rapid prototyping benefit.
Conclusion
Though these features are not necessities, I argue that the great flexibility of Python allows for quicker development (Python includes duck typing and an eval() function). While it does seem that less options in a programming language reduces improper use, the flexibility of unsafe features allows you to test a new idea faster without having to build the perfect design up front. To avoid losing your train of thought, you may want to test an idea as soon as possible and find the fastest way to invoke an eval() statement. You can always refactor to limit uses of the “sketchy” features. I find I develop most productively when I write quickly first and refactor to a better design after seeing patterns emerge in the code.
Thank you for reading. If you have a thought, feel free to share below. If you would like to follow more discussion on programming, subscribe to this blog.
The Pythonic Solution 