First, I recognize that Python is a big subject, one that long ago passed the capacity of any individual to understand entirely, and certainly far past my ability to summarize adequately in an hour. I knew I'd have to choose just one or two key ideas to get across. After juggling at least a dozen different approaches, I decided that the one proposition I most wanted the audience to carry with them is that IronPython is uniquely capable in the role of an extension language.
Working .NET programmers already have comfortable ways to put together their projects with C# or VisualBasic or so on; while IronPython has advantages as a development language, they're largely a matter of taste, and frankly little different from those of IronRuby, Nua, or so on. The two great themes of Python's origin, though, were that:
- it be easy to learn, even for those unfamiliar with computing languages; and
- it "play nicely" with others, in constrast to the comparative insularity of, say, Smalltalk or Forth or Lisp (of that time).
Suppose you've written a good application, one so successful that your end-users are starting to want things from it you hadn't planned: they're eager to design their own game characters, or write novel algorithms to model chemical processes, or alter the business rules for control of a pipeline network. Rather than write all the new functionality yourself, it's a great, great idea to give those end-users a general-purpose programming language that happens to manage, or "hook", selected parts of your application. At that point, the end-users can configure and even create the enhancements they need: brilliant!
What language should it be, though? Certainly not something as difficult as C++, or esoteric in the way Haskell is; on the other hand, a language designed to be a good "first language" ought to work well. It would have to be a good teammate to your existing application, though ...
That's exactly Python's ancestry! IronPython builds on that base a commitment to track Microsoft technologies that at least matches any other DLR language, and exceeds many.
In this case, the promise is actually fulfilled: embedding IronPython within DLR applications, even those not designed ahead of time for extension, is generally straightforward and effective; end-users take to Python well; and IronPython has consistently kept up with new Microsoft frameworks or techniques as they're released.
That idea seemed to go over well on Tuesday evening as I explained it. Even better, though, a couple of developers had just wrapped up exactly such a project: this winter, they embedded IronPython in a hardware-testing application, and they were able to describe a bit of their experience.
Every .NET programmer ought to take a moment to think about embedding IronPython in his or her application(s). It's an opportunity with consistently high rewards.