IronPython Demo for John Udell

Tim Bray tossed me a link to an IronPython screencast given by Jim Hugunin for Jon Udell.

On the surface, it does look fairly impressive. However I'm not impressed for the reasons some folks might be. So here's the notes I took while watching this demonstration...take them for what they're worth.

IronPython with Avalon demo

Here Jim demonstrates instantiating and manipulating a small Avalon UI in an interactive python session. This is essentially the same as the demonstration I gave at JavaOne using IRB to script Swing components (and no, I'm not claiming to be the first to do such a demo). It shows that Avalon produces very impressive and beautiful UIs, and the XAML under the covers is pretty big and ugly. It also shows that IronPython has some nice integrations with .NET code. Beyond that, I wasn't any more impressed than I was when I got the IRB stuff working. It's cool, to be sure, but it's not new.

Notes:

• Tab completion is nice, but in an interactive shell it isn't very exciting. IRB already does this in Ruby (not in JRuby unless you have a ReadLine library wired in), and completion against running code is easy.
• Importing a whole namespace from .NET is really, really nice. We would love to be able to efficiently support the same, but there's currently no capability in Java to get all classes or subpackages in a package. That's the reason why you have to include each class you want. You can include a whole package with JRuby, but for each package you include we have to brute-force search them for all Java classes from then on. O(n) to locate a class, where n = number of packages imported. It sucks. Including the classes directly has no unreasonable overhead, though.
  
• It looks like IronPython has a few nice wrappers around the delegate-based events in .NET. That's the b.Click += some_handler...some_handler is python code that becomes a delegate instance; the += adds it to the Click event. Nice and simple. Everyone feels differently about events+delegates versus listener interfaces, however, and in Java we've got the latter. We'll need a different way to make things nice and simple.
  
• Most of the UI interaction stuff we can already do with JRuby, though it's not wrappered quite as much; you're basically just calling Swing methods directly. We could add a lot here by making something smart that handles common UI use cases for you. This demo somewhat reminds me of the Groovy demo at JavaOne 2006, where the presenter used OLE automation to work with an Excel document. It was a great OLE demo. It was a pretty good Excel automation demo. However it was only a mildly entertaining Groovy demo because it just called OLE methods like any other language could. The Avalon stuff in this demo is similar.
• Almost all the functionality shown, including XAML manipulation, etc, is .NET code, not IronPython code. Ignore anything about XAML and Avalon to see what's really interesting...the various little ways IronPython makes .NET components available to python. Again, an impressive Avalon or XAML or .NET demo...but only a pretty nice IronPython demo. But pretty nice is pretty good. IronPython looks pretty nice so far.
  

Visual Studio demo

VS 2005+ is very nice, but I think most folks already knew that. However the python support looks much better than I expected, on par with what RDT has built for Ruby in Eclipse, though maybe a bit more polished.

Notes:

• It was a bit of a dodge that he didn't admit how Jython compares performance-wise to IronPython. Of course, Jython has been around longer, and I'd wager that it's faster. I've made it perfectly clear that Ruby is still faster than JRuby, because I don't think distracting folks from JRuby's performance issues will make them any less of a concern. It's too slow. We'll fix it.
  
• I've given a lot of thought to where we'd need to hook into JRuby to be able to online debug code, and it won't be terribly difficult to do. We also might be able to simply get Ruby's normal debugging hooks working with a little effort, and just use those remotely. Either way integration into the IDE is just icing on the cake.
• I completely disagree with the long-standing idea that programs should be implemented in Python or Ruby (or some other dynlang) and then migrated toward C# or Java (or some other static lang). I application code should *stay* Python or Ruby, because much of the value of those languages is in the long-term maintenance of the code you write. The minute you port that code to C# or Java (or C) you've lost that benefit. You've set it in stone, as far as I'm concerned. Is any application code ever to a point where you want to set it in stone? Wouldn't we rather just code in dynlang all the time?
  
• I didn't see any code completion or refactoring of python in Visual Studio, unfortunately. There was a little C# completion only, which is well-known and deserving of praise. That's a big area Ruby IDEs could jump ahead. The editing capabilities for python are also only touched on briefly, since he presents a pre-written python script and then writes and calls some C# code.
• The online debugging in Visual Studio looks really nice...I want that for Ruby. The JRuby compiler I've been working on will include .rb filenames and line numbers in the eventual stack trace from the compiled code, so eventually you'll be able to step through Ruby code using my compiler...even after it's compiled to Java class files:

  at MyCompiledScript.fib_java (samples/test_fib_compiler.rb:2)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  

PowerShell

I read a bit about the PowerShell stuff the other day and I don't really have much to say here. It's basically a set of .NET objects that are interactively available to dynamic .NET languages for interacting with the system...a nice set of OO components to provide what UNIX command-line utilities do on UNIX, in a sense. It's neat and all, but it's not relevant to IronPython except that you can script those components in python.

Other notes

Using import clr in IronPython is a clever way to add in .NET decoration of python types; we could probably add that, so that Ruby strings automatically have Java String methods.

Conclusion

My opinions are sour grapes, perhaps...but I could do almost all of the non-IDE stuff in a screencast of my own. The IDE stuff will come soon. It's still a very nice demo, and kudos to Jim for what IronPython has become. I'm impressed.

I think it's safe to say that we're behind IronPython on having a fast, well-integrated implementation (a detriment of the legacy code from the original port) but way ahead on completeness and compatibility with C Ruby (a benefit of the legacy code from the original port). The IDE stuff is not yet as nice for us, even counting the Eclipse-based RDT. NetBeans and Eclipse are in many ways not as nice as Visual Studio, so there's some additional catchup to do there.

I'd like to know how folks out there feel about our approach to JRuby, working to make it a drop-in replacement for C Ruby so it can take advantage of all the libraries and applications out there. As far as I know, neither Jython nor IronPython can actually run most of the major Python applications, and certainly nothing as complicated as Rails. Our choice has made some things harder, but I think the value of making Ruby work on the JVM would be greatly diluted if you couldn't run real Ruby apps.

FWIW, I've had a long-standing task to do a nice screencast like this for JRuby using Swing and other libraries, and I dir a very similar UI demo for JavaOne. Hopefully soon I'll have time to do a longer, fancier one.