Why argue about dynamic versus static languages when you can use both?

With yesterday's release of IronPython, the story of dynamically-typed programming languages comes more clearly into focus. A core virtue of such languages is that they enable individuals or small teams to work in a rapid and exploratory way. A core virtue of statically-typed languages is that they enable larger teams to work in a declarative way that's friendlier to large-scale collaboration. Much virtual ink has been spilled debating the pros and cons of these two approaches, but why argue if you can have the best of both worlds?

We saw a hint of this in episode 2 of The Screening Room, on Adobe Flex, when Christophe Coenraets talked about the value of ActionScript 3's optional static typing. "When you already know what your types should be, declare them," he said. "When you don't, don't." One language, two styles, complementary benefits.

In episode 8, Jim Hugunin makes a related point:

I'm not a dynamic language zealot, and in general I don't really understand zealots. I wrote the first three versions of the IronPython compiler in Python, but today it's written in C#. Part of the reason is that now I understand it, so the values of prototyping, and the looser thinking that really helped a lot in the early days, don't really help as much any more. Also there are now more people working on the compiler, and there are some real benefits to the static typing, and the support you can get from Visual Studio.

That's a more radical rewrite than will make sense in most cases. But as shown in the screencast, such conversion can also proceed incrementally -- even on a per-method basis.

From a strategic perspective, Microsoft now has a stake in the ground. It aims to make dynamic languages, in the managed environment of the .NET Common Language Runtime, safe for the enterprise. Sun has shown some interest in doing the same for dynamic languages on the Java Virtual Machine, but not much, which is ironic given that Jim Hugunin started working on JPython -- now Jython, the Java equivalent to IronPython -- nine years ago.

Former URL: http://weblog.infoworld.com/udell/2006/09/06.html#a1519