|
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.
Update: Another shoe drops. The JRuby maintainers are joining Sun. Quite a week!
|