Came across a short piece I wrote about IronPython while looking for something else - it was in response to some questions from Kathleen Richards in September of last year for
Redmond Developer News (which I think was for this
Article, though none of the content made it in - cest la vie).
At any rate, I figure I might as well post it here, it may be of use to someone... somewhere... who could say? Looking over it briefly I'm not even sure I agree with some of the points I made any more :P
IronPython Article
How are you using IronPython?
At Syzmk (
http://www.syzmk.com/) we are using IronPython as a rich embedded scripting language within our core product, we expose a large part of the .Net server engine (written in C#) to the IronPython runtime, and offer key extension points which can be hooked into with python code – we chose python because the language is rich, dynamic and doesn’t suffer from the verbosity that most of the compiled languages do. At the moment we are moving beyond using IronPython as just an embedded scripting language and are evaluating how best to implement a number of domain specific languages in it for our server, firstly around the business rules and behavior of our application’s core logic, and secondly for performance and diagnostic evaluation and control of the underlying server platform.
Why did you choose this implementation over C python or Jython or other dynamic languages?
IronPython was attractive because of its first class support for .Net types and especially its excellent support for delegates (and because there wasn’t any marshalling) – we were attracted to the python syntax and language structure, more than support for the standard python libraries, so the compatibility sacrifices that were apparent with many C Python libraries, especially during the beta, were of little consequence to us, especially as IronPython has full access to the base class libraries (BCL).
What types of applications are you building?
The core application we have used IronPython for is a server technology, the “Rich Media Processor” (working title) – it’s in production, but has only been going to market for the last 6 months. Effectively you can place it into an organization as a front end processor for rich and largely unstructured messages (think Audio, Video, Email, SMS and MMS messages from phones, images dumped from digital cameras, security camera feeds etc) with the end result being a structured and conforming set of messages and rich content (appropriately formatted images, videos, audio etc) suitable for passing onto line of business systems, or a product like biz talk.
When dealing with transforming this kind of content, python (and IronPython) is a great language to augment the message transformation process – strong string support, access to all the functionality of our underlying application and it’s easy to develop and deploy – IronPython never seems to be working against us, I could never claim the same for any scripting language I’ve implemented into a product before.
Does the .NET environment offer any advantages?
Yes, I think it offers serious advantages for Python (access to the BCL!), developers and customers.
First off the business case for building .Net applications is immediate within our home country of New Zealand, customers are generally expecting to host Microsoft tools and solutions, and our IT industry is geared towards this expectation, there is an implied trust which is worth taking advantage of.
Business cases aside however I think the .Net platform is very engaging for us, our company has a love for technology, and in the last few years the .Net platform has been satisfying that need very well - it offers stability, security and productivity increases that we can’t find elsewhere (and certainly not in an unmanaged language), also the language-agnostic approach and ability to build dynamic languages (like IronPython) in the CLR make the choice all that simpler.
Disadvantages?
We haven’t really discovered any disadvantages with .Net or our approach, IronPython does everything we need and then some, as does the .Net platform – however I think it might be some time yet before dynamic languages on the CLR (or any language other then VB.Net or C#) will be acceptable recommendations from the consulting masses – perhaps more a reflection on the lack of education and published case studies I think.
For instance we already have languages competing with C# on the .Net platform, such as Boo (
http://en.wikipedia.org/wiki/Boo_programming_language), which offer some advantages over the current version of C# and are very suitable for building domain specific languages (DSL’s) – but I believe in many bespoke development houses it would be very hard to get buy-in for using these languages in upcoming projects, even if they will save time and money or just be a better fit for their problems.
Do you think dynamic, object oriented (scripting) languages (Ruby, Python) will start to play a larger role in enterprise development?
I think the short answer is yes, the languages are often just a catalyst for methodologies and practices (such as functional programming, or the ruby on rails web development approach) – the elegance, simplicity and speed at which dynamic language guru’s can deliver results is enviable for a lot of us who have cut our teeth on C++ & Java and known the other end of the spectrum.
If I am in a corporate environment should I be looking into these languages?
I think at this point it should not be on the top of your list – if you’re a Microsoft shop, or in an environment dedicated to employing solutions on top of Microsoft technologies then .Net 3.0 should be your key focus - however I think it’s certainly worth having a few dynamic language books at your disposal (perhaps on the bedside table), they make for compelling reading, and will get your initial buy-in, so you feel comfortable considering a dynamic language on the .Net platform as a good idea.
That said, if you’re not a Microsoft shop, and particularly if you are committed to open-source technologies I would look seriously, probably first at Ruby, it’s very engaging story – though of course you can run IronPython on Mono with a little bit of tweaking … and IronRuby is getting better every day.
What are some of the key issues from an application development standpoint?
I can only talk from the perspective of deploying IronPython as a scripting engine, hosted within another application, though some of these points will probably apply elsewhere, I think it all comes down to one thing - being prepared.
First off, you must change your point of view and adapt some of your practices, as they will confound you with the introduction of a scripting language that has access to your own .Net classes. As you develop classes, try them on for size and make sure the selected scripting language doesn’t have trouble accessing them – for instance heavily overloaded .Net methods in IronPython can be a recipe for frustration later on, same goes with using multiple out or ref parameters – that’s not to say IronPython can’t access them, just that it’s awkward and unpleasant (something your scripting language should not be).
Second to this is security – dynamic languages effectively introduce a surface area to your application that didn’t exist before – our server allows configuration (including iron python scripts) to be applied via a web service – you want to make absolutely sure there is sufficient trust between endpoints, and don’t repeat mistakes of the past with other scripting languages (think injection attacks).