Living in the Tech Avalanche Generation

A while back I went through the personal struggle of trying to decide which .NET dynamic language I was going to adopt. After some fairly lengthy consideration and with a bit of help from Michael Foord, I chose IronPython. Recently I posed this question to Michael: are .NET developers experiencing some *romantic* attraction to IronRuby? Michael I think was a little taken aback and not sure how to respond, most likely I didn’t frame the question eloquently nor clearly enough and so I will take another shot at it here.

Let me explain what I mean by “romantic”. I am noticing that people (I know) in the .NET development community are leaning more towards IronRuby when faced  with the choice. Perhaps my perspective over the so-called community isn’t broad enough to make any sweeping generalisations here, I understand that, nonetheless, tucked away here in my small corner of the universe I get a sense that I am observing a kind of default (if not romantic and sometimes perhaps envy driven) choice of IronRuby over IronPython.

What are the contributing factors? Some very high profile .NET people have jumped the .NET ship in favour of developing with MRI in the recent past. The most obvious connection I guess may be that ASP.NET developers (who by far number the majority in the .NET employment pool) have an vested interest in the successes of ROR which may account for this perceived phenomenon. I also get the feeling the feeling that Ruby gets a better deal in the hype stakes and that could also be having some impact.

I wonder has anyone else noted this? Figment of my imagination? Way off the beam? One thing is for sure, neither seem to be playing a real part in the commercial world yet; a search on seek.com.au (a well known job market web site) for IronRuby or IronPython or DLR, will sadly produce no results. This is understandable as IronRuby in only just recently gone RC1, but IronPython has been around a little while and some people in some parts of the world do make a living with it already.

UPDATE:

Oh I did forget that perhaps people just think Ruby is the better of the two languages?

Well it hasn’t taken long to get some excellent bang for buck from IronPython. The entire team with whom I currently work are all furiously learning Python courtesy of an almost Googlesque free learning time and I have already documented my learning path with respect to Python here before.

As I said at the top of this post, we are already reaping some benefit and there is certainly not an Python guru amongst us (yet). Most recently we were asked for a fairly trivial application (as far as complexity goes) but one that was very valuable to the business nonetheless. Without going into the gory details, what was requested was a desktop application that digitally processed documents (imaging) and produced the output fast, and I mean really fast. The last part of the request was for a design that would allow the document list to be compiled from almost any source, database, xml, Microsoft Office files, txt, etc etc. Let’s deal with each of these concerns in order of their being mentioned.

Steroidal Processing Speed

This part was really not that hard to design and the choice was a simple one, in one word, NServiceBus. What was needed essentially was many workers all doing the same work on a given set of files and this of course mapped brilliantly to one way messaging using NServiceBus and it’s distributor to manage balancing the load amongst the workers. By spreading out the work across any number of worker nodes, our project managers could scale up and down according to their needs to adhere to a given SLA. If you want to read more about the Distributor in NServiceBus please check out Ayende’s review.

Convention to the Rescue

As I said earlier, we were asked to provide a method of very quickly adding or “plugging in” new ways to access data that would produce the list of files for processing  and furthermore this needed to work without needing to recompile any part of the application. Given these conditions and the convention that our messages were always derived from data that included a list of files to be processed, it was pretty clear that IronPython was a perfect fit.

The UI itself was built using C# with the exception that the list box contents would be populated by an IronPython script and the same script would call-back into the C# code with the list of results (file paths). Having IronPython scripts call-back into managed code is trivial, you just need to pass a function from the executing managed assembly and have that function stored as a variable on the executing Script Scope. Then you just call the function. For example:

public void callback()
{
    Debug.WriteLine(“Test Callback method got called”);
}

public string funcback(string calledwith)
{
    Console.WriteLine(“Test Callback function got called with “ +
        calledwith);
    return calledwith;
}

private void SetDefaultScopeVariables(ScriptScope scope)
{
    scope.SetVariable(“test_callback_method”,
        new Action(callback));
    scope.SetVariable(“test_callback_function”,
        new Func<string, string>(funcback));
}

What the sketch of the UI (above) points out (see the red arrow), is that by dropping scripts into the application we were able to load up any number of ways in reading data to produce the list of files that would be used in creating our messages (sent via the distributor). So by simply dropping in a new IronPython script, another item would be loaded into the list box, offering a new method of accessing data requiring processing. Every scripted plug-in would provide an input, a description and it’s own particular method of accessing data (which could be anything).

On a side note, the UI sketch was produced using SketchFlow in Expression Blend 3 which looks quite promising.

Question: Does IronPython support Multiple Inheritance / Mixins?

Ans: Yes!

Question: Can I use my C# classes from IronPython (in the IP runtime)?

Ans: Yes!

Question So, I should be able to use my C# classes in a multiple inheritance scenario from IronPython?

Ans: Yes!

Making it all work

If you create a class in managed C# you are free to pass it along for use to the IronPython runtime and thus access it using IronPython. Let’s take the following class created in C#:

public class Person
{
    public string Name;
}

Using my IronPython WPF interactive console control, I can interactively create new classes with IronPython and use my C# Person class as the base class in an inheritance object graph. Here’s the code as typed at the interpreter:

As you can see, first up I imported the relevant namespace (module) where the C# Person class is defined. The first class derived from Person is Employee and then I have derived WarehouseManager from Employee which leaves our Inheritance tree like this:

• Person
  • Employee
    • WarehouseManager

You can also see that both the derived classes have access to the Name property of the C# Person class which proves that the Person class has been included in the inheritance of the Employee and subsequently WarehouseManager classes.

So that’s some plain old inheritance using C# classes. Now lets take a quick look at multiple inheritance using the same C# class.

When should I use this feature?

Probably never according to some people, yet for every objector there seems to be fan. Languages that do support multiple inheritance, often come with a disclaimer for programmers to avoid their usage and Python would appear to be no exception in this case. The above is a good example of why multiple inheritance isn’t necessarily a good thing, given that a manager is presumably an employee and at the very least a person. Nonetheless it demonstrates the intent and this post isn’t so much about the ‘why’ but mostly for now it’s about the how. I will follow up soon with more about the ‘why’ and ‘when’ in a subsequent post.

Carefully managed, I can see it’s potential uses could be enticing. Yes, yes I know “composition over inheritance” etc…There is never one shoe fits all!

Just in case you where wondering

If you were thinking of doing something like this in C#:

public class WidgetA
{
    //….etc
}

public class WidgetB
{
    //….etc
}

Followed up by:

You will see that we cant in fact use two classes created in a CLI compliant language. This will effectively stop crazy stuff like this:

class MutantUi(Form, Button):
    def SetTitles(self):
        self.Text = “What happens here“

But I am completely free to do this:

from Org.TechA.Wpf.ControlsHarness import *

class PythonMixin(object):
    def method(self):
        print ‘method‘

class Mutant(PythonMixin, Person):
    def MutantMethod(self):
        print ‘mutant method‘

 m = Mutant()
 m.method()
 m.Name = “Simon“
 print m.Name
 m.MutantMethod()
 

So there you have it, Multiple inheritance / mixins with C# (well kinda)!