Duct Typing September 26, 2009
Posted by stochasticresonance in ramble.Tags: duct tape
trackback
Today people were tweeting up an old interview with Al3x Payne and some devs from Twitter about using Scala.
Al3x or anyone else has the right to use for whatever programming language they want. No questions asked…
But today I was reflecting on Al3x’s rationalization of the type system motivating a move to Scala. I mean we’ve heard this before and the whole thing got a lot of Ruby panties in a bundle when it first came out.
But checking for nil and kind_of? all over the place is not Ruby’s failing… that’s a big ball of mud in any language and I’ve seen people resort to the (null != foo) && (foo instanceof Bar)) anti-patterns in Java.
Al3x asserts this is an inherent property of large systems in dynamic languages. I’ll assert it is a property of systems that have grown organically to the point where the programmers can’t reason about what is coming or going. I’ll further argue that you get more out of thinking functionally towards solving this issue than you do from stricter typing.
If you find yourself constantly checking for nil/null or really being concerned with types except around the edges of a system, that’s a code smell IMHO.
But maybe another layer of duct tape will fix it…
totally duct'd
Issues with duck typing always interest me, particularly because I’ve never run into them.
I’d like to see actual instances where people ran into issues to see if there are differences in coding style or other practices that lead to the problems. It does have bad code smell, but I’d like to see one up close before I make too strong a statement.
I would love to see the code or representative code that necessitates type checking.
In conversation with @nasrat, I was introduced to this short comment by Martin Fowler which also contains some statistics from Ruby code projects (presumably at ThoughtWorks).
I think you have two class of problems that lead to type checking. The first is you don’t understand the contracts between collaborators in your system and are getting unexpected types sent to a method, the second is you don’t understand OO/polymorphism/duck typing and are adding conditional logic to fill in that gap. (I suspect the ‘tests’ probably have their own technical debt as well in both cases, if they exist.)
I’d think both cases should avail themselves to some analysis and refactoring. Would that be faster than rewriting the functionality in a new language? Hard to say…
I’ve had experience with systems that are hard to reason about, but dynamic language or no, whenever systems get to the point where you have to code defensively to protect yourself from your own system, it’s probably time to put down the duct tape and take a step back.
Indeed, thinking correctly about programming is a good way to avoid type checking all over.
Static and/or strong typing (i’m talking Scala/OCaml, not C++ or Java…) has the advantage of allowing you not to worry about such type checking once you’ve defined properly the type system you’re dealing with.
So, yes, these awful type checks are unavoidable once you have dynamic languages and confused projects. In Scala or OCaml, you simply replace the time you waste on type checks by the time you spend designing a well suited strong/static type system.
Depends on what you value…
But something like “(null != foo) && (foo instanceof Bar))” in OCaml? You must a damned twisted soul to even get the opportunity to write a similar thing…