Registered: Sep, 2005
Re: Programming with "Duh" Typing
Posted: Jul 9, 2007 8:56 AM
> Dynamic typing, on the other hand, lends itself better to
> exploratory programming, where you’re not even sure what
> the design is. For example, a field named “address” may be
> a simple string today. Tomorrow, you may discover that a
> simple string won’t cut it and change the field to point
> to an object that breaks the address down into component
> fields. Dynamic typing gives you stronger guarantees that
> your design works, by giving you immediate runtime
> feedback without a lot of superfluous typing.
> Now, regarding the topic of type inference, I’ve spent
> quite a bit of time using Haskell, which is another
> language that uses type inference. I agree that at first,
> it feels like you’re using a dynamic language, but with
> some extra sanity checks provided by the compiler. After
> you do some more exploratory-type programming, though,
> you’ll soon be reminded that it is not a dynamic language.
> Taking the example above, say you want to change the type
> of the “address” field to be an object for the purposes of
> unit testing the verifyZip() method. You’ll discover that
> it isn’t an easy process. Not only do you have to change
> the verifyZip() method to treat the address as an object,
> you have to change ALL of the other methods/functions that
> interact with address in order to get the change to even
> compile. (Then, you have 50/50 chance that the design
> change doesn’t work well and you have to change it all
This is a good concrete example and I'd like to continue with it.
Now, when you say you can change the address to be an Object in the dynamic language without changing the rest of the code, I assume you are making this new object so that it acts like a string object. If this is not what you mean please humor me and clarify a bit.
In Scala, I believe you can get around changing any declarations that refer to the address as a String (mostly method declarations, I would imagine) using implicit conversions. The downside is that the implicit conversions are a bit opaque but not much more so that duck-typing, in my estimation.
In addition, the information provided by static typing allows for automated refactoring of the kind you mention here. The time that it takes to make this kind of change is not significant with these tools.
One reoccurring problem I have in Python is that there are changes that cannot be made without updating calls in other places. For example, if I find that I need to change a method to use a generator instead of returning a list-like type, I have to go and update any calls to the result that uses list methods. In a static-typed language this is easy, and can often be automated. In Python, I use a run-debug, run-debug, cycle until I fix all the code. Perhaps this is just ignorance on my part but this concerns me when contemplating large complex systems written in dynamic languages.