Does .Net have a dynamic-language deficiency?

Dynamic programming languages have been around for decades. With LISP (LISt Processing) and Smalltalk as progenitors, today's popular examples include Perl, Python, and Ruby.

Often labeled "open source scripting languages" and regarded as useful mainly for data mining and automated system administration, their well-kept secret is that these highly-productive languages power more mission-critical services than enterprises like to admit. In the Java world, a Java/Python hybrid called Jython has built a cult following among developers who want to manipulate Java APIs with the ease and flexibility of Python.

The .Net world lacks a Jython equivalent. ActiveState's Perl .Net and Zope Corporation's Python for .Net bridge these languages' VMs (virtual machines) to the .Net CLR (Common Language Runtime). But they don't achieve the deep integration that comes from implementing a language directly on the CLR, as Jython implements Python on the JVM.

Despite lots of second-guessing, there's no consensus that the CLR is inherently unfriendly to dynamic languages. The JVM doesn't bend over backwards for such languages either, and yet Jython is a great success thanks to the heroic efforts of its inventor, Jim Hugunin. Now Hugunin has turned his attention to .Net, and reports promising results with a prototype Python implementation for .Net called IronPython.

Such projects always seem to spring from an inspired individual or small team. In fact, Microsoft Corp. has such a team. It created JScript .Net, the most dynamic of Microsoft's .Net languages. But JScript .Net is the unloved stepsister of C# and Virtual Basic .Net.

Dynamic languages are rooted in a culture that is simply not indigenous to Redmond. That may change, but for the time being, the future of dynamic languages in .Net lies with non-Microsoft innovators.

Join the newsletter!

Error: Please check your email address.

More about ActiveStateMicrosoft

Show Comments

Market Place