IronPython in Action and the Decline of Windows

June 26, 2009 — originally posted on Neopythonic

While CPython still rules on python-dev, especially with the excitement around Py3k, Python's alternative implementations are growing up: PyPy is now capable of running Django, Jython just released version 2.5, and IronPython has been releasing significant milestones like clockwork. I get a lot of satisfaction out of such milestones: they help establish Python as a language you can't ignore, no matter which platform you are using.

Seeing a book like IronPython in Action, by Michael Foord and Christian Muirhead, is another milestone for IronPython. This is a solid work in every aspect, and something nobody using IronPython on .NET should be without. The book is chock full of useful information, presented along with a series of running examples, and covers almost every aspect of IronPython use imaginable.

After reading the table of contents and the introduction by IronPython's creator Jim Hugunin, I couldn't help myself and skipped straight to appendix A, "A whirlwind tour of C#." This is a useful thing to have around for readers like myself who haven't really kept track of things in the .NET world. Maybe I'll comment more on C# another time. For now, let me just say that it seems a decent enough system programming language. The more relevant thing about C# is that you can't avoid learning it if you are developing on .NET, even when using IronPython. There just are too many issues where IronPython has to work around a limitation of C#. This happens often indirectly where a particular API was designed purely with C# in mind. And then there's the issue that Microsoft's API documentation focus on C#. (And VB.NET, I suppose, which after seeing some samples of in this book I have less desire to know than ever.)

There are some introductory chapters -- some fluff about .NET and the CLR, an introduction to Python, and an introduction to with .NET objects from IronPython. The Python introduction has a slight emphasis on differences between IronPython and CPython, though there aren't enough to fill a chapter. This is a good thing! The chapter does a pretty good job of teaching Python, assuming you already know programming. In general, the book is aimed solidly at professional software developers: unless you are paid to do it, why would anyone want to get intimate with Windows?

Yes, Windows programming is what this book is really about. I'm sure that doing Windows programming using IronPython is a much better proposition than Windows programming using C++; but it's still Windows programming. Fortunately the authors maintain a slightly ironic attitude about Windows. I can't help admiring their persistency in getting to the bottom of the many mysteries presented by Windows(and in some cases by IronPython's wrappers).

Many, many years ago -- so long ago that I can't even recall when -- I did some Windows programming myself, using Mark Hammond's Win32 extensions for CPython. That package maps the Win32 API pretty directly to Python. It lets you work with Windows in much the same way as you can in IronPython -- the main difference is that IronPython lives in the more modern .NET world, while Win32 is showing its age.

But is life with IronPython all that much better than in CPython+Win32? It still looks incredibly tedious to create the simplest of UI. Each button in the UI has to be tediously positioned and configured (width, height, padding, font size, etc.). The book maintains a running example throughout many of the chapters, and one of the earlier versions (with many features not yet developed) clicks in at a "mere" 258 lines. Fortunately, the source code for all examples can be downloaded from the book's website. While the downloaded zip file is a whopping 33 megabytes, there's actually only half a megabyte of source code in it (and much of it multiple versions of the same running example) -- the majority of the download is not source code but DLLs that are probably included by the authors because Microsoft scatters them around half a dozen or more different support websites. (Plus, there seem to be multiple copies of IronPython.dll and a few other DLLs included.)

This then, was the big eye-opener for me: that despite all the hype, Windows UI programming is as tedious today as it was in 1995. Sure, the new UI looks a lot better. But that's mostly glitz: 3D effects, color gradients, video, and so on. Sure, it's all object-oriented now. But it hasn't really gotten any less complex to create the simplest of simple UIs. And that's a shame. When is Microsoft going to learn the real lesson about simplicity of HTML? Instead, Microsoft is doing the same thing to HTML that it does to anything it touches: adding cruft to the point where the basic functionality is buried so deeply that most people can't even find it. You can't really blame the average Windows developer for focusing on eye candy instead of usability -- it's all mashed together in the APIs, and by the time you've got something that works at all, you're too exhausted to look at it from your users' perspective.

It's no wonder that users are switching to the web as the platform for everything that used to live on the desktop -- with all its flaws (which I will discuss another time), web development still feels like a breeze compared to Windows development. And that means less time to release, and hence more frequent releases, which in turn means more opportunities for developers to learn what their users actually do. Which as a user I really appreciate.

Comments (25)

Jonathan Gilbert — June 26, 2009

The thing that gets me, apart from the rapid descent to ascerbity in this discussion, is the focus in this discussion on how one represents a UI layout as first and foremost, rather than how flexible and consistent the UI system is in its architecture.

In my experience, the Win32 architecture, for all of its failings, is a much more solid design than the web browser architecture. Generally, once you have a part of the code working, it stays that way, and is relatively oblivious to other parts of the same application changing. Though there are a number of flavours of Win32, most of them published by Microsoft, your application will run the same way on all of them. Finally, though Win32 design is far from 100% self-consistent, its consistency greatly outweighs that of HTML, CSS, JavaScript and such. Web development completely fails in these regards for me.

XAML is a useful tool, and in some cases virtually essential if only for the vast reduction in verbosity it affords when laying out a UI, but XAML should not be confused with WPF itself. XAML is a way of encoding WPF, but it should be seen as part of the same family that includes C#, VB.NET, JScript.NET, Boo, Cω, F#, J#, Nemerle, not to mention IronPython. It is a programming language, albeit a very constrained one with no flow control, whose primary goal is expressing the instantiation of WPF objects. For this purpose, it may not achieve the brevity that HTML can sometimes, but its expression offers something else very important: Because it is XML, it can be read and written by standard XML tools/libraries, vastly simplifying the work required to make any kind of designer (and there are a number of fundamentally different kinds of designer that are all appropriate for WPF).

Jonathan Gilbert — June 26, 2009

So, what is WPF really about? I can, off the top of my head, think of at least 6 things it brings to the .NET UI world that the competition, and specifically S.W.F, in its clean but relatively thin wrapping of Win32, sorely lacked:

1) Self-consistency. Throughout, WPF behaves the same way. All panel-like controls are Panels. All content-containing controls are ContentControls. All controls that allow you to select one or more of a list are ItemSelectors. All properties work in the same way, all events work in the same way. When you put a certain hierarchy of WPF objects in different containers, different forms, it tends to behave in much the same way, and that behaviour is very easy to predict. There's also no special-casing. For example, in Win32, a window's menu is a special entity, an HMENU attached to the HWND. Its rendering and behaviour is handled separately by the desktop window manager, and you simply receive notifications. What if you want to do something unorthodox with a menu, like put complex controls into an item or instantiate it in a place other than docked to the top of the screen? Well, in WPF, the Menu control is just another control. You can put it anywhere you want. Under normal circumstances, you start out your UI hierarchy with a DockPanel and use it to affix the menu to the top of the window.

2) Comprehensive support for binding. Through dependency properties attached to dependency objects, virtually everything, almost without exception, can be tied into a complex binding system that can do two-way binding, arbitrary conversion, link parts of the UI, express views of underlying models.

3) Completely revamped event model. Much closer to what is offered by the unholy union of HTML and JavaScript, input events first "tunnel" from the root UI object down to the control that holds focus, then "bubble" back up. Events that are tunnelling can be intercepted by a parent control and handled independently, and if they are marked as handled before they reach the target, then the second half of the event is also suppressed. Events that are bubbling allow a single, common handler to intercept an event type from any one of a number of child controls. This model is vastly stronger than what any previous UI system for .NET has offered.

Jonathan Gilbert — June 26, 2009

This comment has been removed by the author.

Jonathan Gilbert — June 26, 2009

4) The ability to treat any piece of data, regardless of its type, as a UI object. This ties into the powerful templating system. You can, for instance, create a simple POD type that describes a record and add instances of that type directly to a ListBox. By default, the list box will call .ToString() and you will have a list where every item says "MyProject.MyRecordType", but you can trivially define a template matching that data type and replacing it with an arbitrarily complex hierarchy of child controls. The list box (or tree view or list view or button or tab control item header) will happily embed absolutely any subtree of WPF controls, even including video or 3D content. You can define this template not only directly in the list box but also in any parent, creating a template that matches any child control trying to display an object of that type.

5) Automatic layout. S.W.F played around a bit with the concept, but its implementation was unconvincing and ultimately a failure. WPF is designed from the ground up around the idea of having container controls that can lay their children out in a sane fashion. Think of it like HTML's flow layout, except where you are actually in control of what's going on without having to resort to browser hacks and other black magic. Sure, WPF has a Canvas control that lets you position things explicitly at any (X, Y) offset you want, but its use is discouraged and unnecessary for the vast majority of user interface design. You have to build up some familiarity with the controls, but once you have a good feel for the Grid, UniformGrid, StackPanel, WrapPanel and DockPanel controls, in my experience it is quickly evident how best to lay out the controls in a window, and more often than not, you can simply let the window set its size automatically based on what is in it.

6) Resolution independence. Everything in WPF is a vector graphic. By default, a plain Windows installation treats its pixels as though they were exactly 1/96th of an inch. To simplify development in these default configurations, WPF's units are also 1/96th of an inch -- however, they are always 1/96th of an inch, regardless of what you change the setting to in Windows. So, if you tell Windows that you have a display that has, say, twice the resolution at 192 DPI, WPF will automatically create a form twice as many pixels wide and tall, and all of the content within it will automatically be scaled perfectly to fit, including text. It really does work!

I'm sure there are many other points, and different people will be enamored of different ones, but it is shortsighted to dismiss WPF as merely gradients, video and 3D charts for boolean values.

rgz — June 26, 2009

WPF => Microsoft XUL.

Rudd-O — June 27, 2009

"Indeed, in comparison to other operating systems, modern DLL management on Windows is drastically simplified, since version conflicts can often be solved simply by ensuring the correct versions are kept in the same directory as your program binary. I know of no mainstream Linux distribution, for example, that supports such simple resolution."

This is an exceptionally ignorant paragraph. To do this in Linux, you ship the libraries and install into your program's directory (say, /usr/lib/programname), and all your program has to do is set the LD_LIBRARY_PATH environment variable to the path of the program. There are quite a lot of programs that do this, for example VMWare or Skype. This technique is not exactly "the correct way" of doing things, but it's just as possible as with Windows, and the only reason you need the environment variable is for security reasons.

Anonymous — June 27, 2009

@Rudd-O: the UNIX approach requires the end user to know about process environments or passing flags to the linker (which implies understanding how to build things). Additionally to do it on Linux in an acceptable way, the user must additionally understand sonames and symlinks.

On Windows, an end user can be guided through a problem using nothing but Explorer, a telephone, and 5 minutes of her son's time (speaking from experience).

In any case this is tangential to the post. Guido made it clear this is not what he was talking about.

shevy — June 27, 2009

to Rudd-Q

to use the "/usr/lib/programname" approach and then require LD_LIBRARY_PATH is a big design constraint imho. You gain only pseudo-AppDirs that way in a very limited and confusing manner - what if everyone would use that LD_LIBRARY_PATH approach? Why would or should we need -rpath also?

Seems like a pile of hacks to me.

It is interesting to see that the FHS itself allows for this approach though, see http://www.pathname.com/fhs/2.2/fhs-4.7.html

I just look at my /usr/lib and saw mono/
and mono-source-libs/ I do not understand why there is not a single mono/ dir (but then again, I don't understand the advantage of the FHS model either ...)

protege — June 27, 2009

This comment has been removed by the author.

Marius Filip — June 27, 2009

Hm ... HTML programming like Windows porgramming? Not a bit, no, no.

As long as web developers have to run their pages through several browsers and check visually they look the same, it's no comparison to Windows.

In Windows you can write a program for Win95 and run it unchanged in WinNT (not anymore since they killed Win95), let alone apps which went from NT 4.0 to Vista and will also run in Windows 7.

Considering that the HTML standard isn't even implemented by the major browsers, I'd say Windows as a platform is better. Obviously, I don't compare it with other OSes - but in terms of Linux, I'd say it's the same situation as with HTML, too fragmented.

Blabla Bla — June 27, 2009

I'll take C#/Silverlight any day over the complete mess that is known as HTML/CSS/Javascript.

Maybe you'll catch up in 2015 when HTML5 is released.

Anonymous — June 27, 2009

Well, dismissing WPF as "eye candy" is just not fair: i mean, i'm well aware that HTML's been there for a while now and microsoft should drop its "if it's not our property from beginning to end we ain't gonna do it" attitude but XAML is actually a joy to edit by hand. No designer (Blend included) does a better work than tools like kaxaml that render what you're typing JIT. And it's so declarative... like HTML is. If you're telling me they should've tried to stick close to HTML instead of creating a(nother) markup language almost from scratch i'm behind you but WPF is not just glitter: there's DirectX behind it and Win32 is almost not beign employed anymore.

Anonymous — June 28, 2009

This comment has been removed by the author.

Anonymous — June 28, 2009

Come on... still the desktop applications are the real thing for serious business, e.g. MSOffice/OpenOffice/Latex vs Google Docs, Photoshop/Gimp vs ..., and so on. It is has been dumb easy to develop Windows/desktop applications since Borland Delphi/Lazarus FreePascal/... appeared.

I respect Python but probably there are better yard sticks for Windows vs web comparisons.

Soubhagya — June 28, 2009

In my point of view, you should have done a bit study before writing this post as you seemed to be out of touch with UI programming on Windows.
We need to choose the right tool for the job. No body does UI programming in 2009 using win32 APIs. And in C#.NET + VisualStudio it can be done much more faster than developing any web UI and UI in any other platform. The reality is that UI programming is tough if you are going to do it using Python irrespective of the platform.

Art Vandalay — June 29, 2009

I'm a little surprised nobody has yet compared Windows GUI programming with its true competitor. It isn't Web tech, which despite growing success stories isn't yet suitable for doing many of the same interfaces as desktop apps.

The true competitor is Apple Cocoa, which indeed trounces Windows. And of course, even with a better API, people build interfaces using a devoted tool (Interface Builder) that, funny thing, uses an XML format underneath. (I don't know XAML so I can't actually compare the formats.)

Hobbit — June 29, 2009

You couldn't be more misinformed about .NET and the current state of Windows programming.

I hope that google is paying you well to say that all applications should be done on the internet. Seeing how well their Google Office Apps worked out.

Steve — June 29, 2009

Guido:

Remember that the vast majority of Windows users never see the command line, let alone develop GUIs. Then look at the reasonable IDE's that are available for the Windows platform, and tell me where the open source alternatives are.

There are many things about Windows that suck, but sadly open source can suck too, and sometimes just as hard. I just deleted the "Python Projects I'd Like to See" slide from my EuroPython presentation, but now I am tempted to put it back in again :).

Sorry about those who assume you are promoting Google misinformation. I know both you and Google better than that. It does, however, show you how seriously your opinions are taken ...

I saw you voice your reservations about this post on Twitter, and would like to thank you for making me feel like less of a curmudgeon :)

Warren — June 30, 2009

Using Python to write GUI apps on windows, is a primitive idea, one very few people stick with very long.

I myself tried using wxWindows wrappers in Python, Boa Constructor, and every other thing, including that pile of horrors known as tkinter.

Eww.

Then I went back to Delphi and never looked back. Python is a great language for writing command line scripts, but it's a crap system for writing GUI desktop applications.

Warren

Unknown — July 02, 2009

@Warren:
It is not true that it sucks to write GUI applications in Python. Maybe it sucks using wxWindows as a toolkit (I tried and gave up), but it doesn't suck at all with PyQt, in fact it rocks and is much easier then writing Qt applications with C++. There is a useful GUI builder available, the GUI is saved as XML or Python code can be generated from this XML. The Qt API is very intuitive and easy to understand. With Eric there is even a complete IDE coded with PyQt, and it doesn't suck like Boa Constructor.

Anonymous — July 03, 2009

Guido,

> Plus, I don't believe that a GUI
> generator suddenly makes your app
> more user-friendly. More likely it
> helps generating more useless eye
> candy.

obviously, you haven't used Delphi yet.

As pointed out by the others: nobody who seriously develops Windows UIs is doing it by hand.

Anonymous — July 13, 2009

Ahah! This degenerated into a Windows Vs Linux/Web Programming flame war pretty quickly!

Both Windows GUI programming and Web development have their flaws... and both of them look pretty bad compared to the joy that is OSX GUI development :)

However, that aside, let's focus on something more productive. Python as a dynamic language can make both web and GUI development easier. Right now a lot of GUI and web software is being written and Python.

Rather than complaining about how bad GUI dev is... why not do something to make it better? Who is in a better position anyway?

Right now if you want to ship a cross platform GUI written in python, the program can end up being well over 100 megs because of the need to compile QT and related libs into the app (see the osx binary for http://ichi2.net/anki/). If something like pyqt were part of the standard python distro, developers could ship much smaller cross platform executables. This is especially true on OSX, which ships with python itself...

Unknown — August 02, 2009

Would be highly appreciated to know Guido's opinion about viability of running IronPython ported to Linux's MONO.
That would be authoritative for sures. Can be found out there many voices encouraging to 'don't' this is, running the IronPython stack on Mono. Better yet if we can now what would be worthy of such thing.
IMO I'd prefer to use Python on Ec2 , S3 or simpleDB. It's cool to see that the bookstore sells infrastructure either. It atracts mere mortals and that include old procedural minds developers , myself began with RPG on a mainframe.
Free quotas is music for our ears, isn't it ? A bonus that deserves ourselves to jump in OOP asap.
Rafael

kilon — November 19, 2009

I would have to agree with Kmd. .Net is the child of one of the ex-developers of Delphi. Its meant to be used from inside an IDE, not to be hand written.

Sure python has simpler syntax than Delphi and , python GUIs follow the simple to code rule as closely as they can.

But its virtually impossible to claim, that hand coding can be faster that true drag and droping RAD GUI development. IT want matter even if the syntax and libraries are pythonic.

ITs too bad that there is no good enough IDE for python. I love python syntax and coding but I certainly miss my old Delphi days...

André Moraes — May 27, 2010

I could not agree more with the comments about windows programming.
I've used IronPython to do small things in another project, basically glue-code.
The use of the Mono project combined with IronPython can increase the user base of both technologies.