Why are dynamic languages on the CLR (and the JVM) such a hot topic these days? Jon Udell wrote a very insightful article on this very issue called 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?
If you have a VM that can run code written in dynamically typed and statically typed languages, you can focus on using the best tool for the job. Right now if you’re writing a Ruby application, you can write parts of it using a strong, dynamically typed language (Ruby) or a weak, statically typed language (C). If you’re using RubyCLR/IronRuby/Ruby.NET you now have the additional choice of a strong, statically typed language (C# / VB / F#).
You can and should write different parts of your application using the most suitable technology. Things get even better if your entire application can run inside the same virtual machine, since you can leverage the platform benefits that come ‘for free’ with the VM: tools, debuggers, performance, and security.
I for one believe that this is the way we’ll be writing our applications in the near future. And I’m doing everything that I can to make this happen for Ruby and the CLR as quickly as possible.
