Dynamic vs Static... no wait make that DBC!

I need to blog this basically to toss it in my archive. There have been some interesting posts on the religious debate of static vs dynamic languages. I don't know why I always get drawn into these lines of thought, but I do. (in fact I just added a "versus" label)

I say drawn in because my underlying philosophy in all of these things is to choose the right tool for the job and leave it at that. I know, hardly original thinking, but despite the mantra and the collective nod that this is true we still get very heated on issues that are not actually at odds with each other.

I'm NOT arguing that with you. I'm not arguing that with YOU. I'm not ARGUING that with you. I'm not ARGUING that with you Harry! Harry... Harry... Yeah Harry... but can he DO the job. I know he can GET the job but can he do the job?
Mr. Waturi, Joe vs the Volcano
Still there is fun to be had in the whole exercise. For the record I tend towards the static languages. Despite my recent fun with Python I have spent the last four years neck deep in C# and really am loving it. Our application uses over 75,000 lines of JavaScript, and every opportunity I have to decrease that number I will take. (Part of my excitement about Silverlight is just not having to write as much JavaScript anymore) I see the power in dynamic, I've done some really cool things with JavaScript and I've really enjoyed working in Python again.... but I believe there is less of a ceiling for static languages then there is for dynamic in terms of tool set, performance and the ability to handle large projects with large teams.

Anyway, Mat Podwsocki presents a great summary of the debate with links to a few bloggers here :


The original Steve Yegge presentation is here :


And the response that I enjoyed the most is here :


I enjoyed Greg's response because it just really got me thinking. I honestly know nothing about the design by contract research that's going on, but it just feels like something that makes sense. I got excited just imagining seeing errors like the ones described showing up in our project at compile time. I believe that if we were using such a system we would see a real improvement in quality. I can see how some would see this as an unnecessary burden on the developer, but these are probably the same crowd not writing their unit tests.

Design by contract is really a great example of what I mean when I'm thinking about the potential for statically typed languages in tool sets.