This post originated from an RSS feed registered with Agile Buzz
by Wilkes Joiner.
Original Post: Static vs. Dynamic is missing the point
Feed Title: Fuming Incense Stencher
Feed URL: http://feeds.feedburner.com/FumingIncenseStencher
Feed Description: a geek prattling on
I'm too lazy to link to the myriad of post on this topic, google it. The arguments have been stated and rehashed over and over again. One pro dynamic typing is argument go something like, "Dynamic typing is safe with a good set of unit tests." I think this is true of any system, static, dynamic, manifest, implicit, ... Whenever I am speaking with a Smalltalker who has worked on "enterprise" systems, I always asked them if they encountered problems with objects being of the wrong type. The reaction is usually a quizzical look wondering why I am asking the question followed by search through there memory and then a simple, "Nope, well, maybe once, but it was caught very quickly." These are developers whose systems began in the 90's and they were not doing any "unit testing." Lispers have given me similar answers. Talk to a C programmer and you will get a much different answer.
So why aren't they experiencing the typing problem without the benefit of unit test. I've got a couple of theories, but the dominant one is interactivity. When I'm writing a program in Smalltalk, I may just start off with a Workspace. Type in some code and evaluate it and open it up in an Inspector. As the program grows, I start refactoring the code in the Workspace into classes and inspecting it. Now is where things get really cool. At this point, I have an inspector open on some object. I can go in and modify or add methods in the class and evaluate them in the Inspector. I can open up inspectors on the results of those method calls, and so on...
When coding Ruby, I'll do a similar thing with files and irb (Interactive Ruby), albeit without the nice GUI tools.
So what does this have to with Static vs. Dynamic? I think the real issue is early vs. late binding. In languages that allow you to interact and modify the objects and their definitions at runtime you gain a huge productivity boost. Your feedback loop is much tighter, and you can verify behavior and correct behavior on the fly.
I'm am a strong advocate of unit test, and I recommend writing unit test in these late bound languages. In fact, transforming the Workspace / Inspector approach to a unit test / debug and inspect approach will provide the most bang for the buck. Here is an article by Ron Jeffries on this style.
Previous Topic
