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.
"But is life with IronPython all that much better than in CPython+Win32?"
Outside of UI development (which I thankfully do not have to do), IronPython makes it much easier to use the Python languages in MS or .NET centric shops, where there would be a (subjective) policy barrier to installing the CPython stack.
Thus, life with IronPython is better than life with no Python at all!
I'm largely a big fan of your work, not least Python and a lot of what's published on your blog, however this post seems a little below par and somewhat rhetorical in many respects.
For a start, writing code against .NET in almost every respect feels *nothing like* working with Win32, be it Windows Forms or access to system-level stuff that previously would have meant hours spent painfully reading TechNet or MSDN.
Your biggest complaint in this department appears to be the 'difficulty' with which GUIs are constructed in code – the same can be said about wxPython, PyQt, PyGTK, etc. Fortunately few complain about this since for the past 20 years we've had amazing tools to help with this bit - GUI designers (Glade, QT Designer, Visual Studio, and in more recent .NET releases - WPF). Your comment is perhaps no more true than when speaking about development of web applications – where endless hours can be spent writing CSS rules to make DIV elements act like tables just so you can align things properly (wait - what?!), or of course we could just use something like GWT, in which case, back to writing those manual GUI instantiations in code again.
As someone that has spent considerable time with HTML, WinForms, and wxPython, there is absolutely no doubt in my mind which I'd prefer to work with in the future (the one with the cleanly designed class library, that wasn't built with C++ in mind!).
Aside from this, the only evidence you seem to show for "Windows UI programming is as tedious today as it was in 1995" is that the demos provided with the book included a bunch of DLLs. You appear to be alluding to the shared library situation on Windows being something like it was 15 years ago, a problem that has never existed for .NET, nor generally in any modern version of Windows since at least XP.
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.
You then begin to talk about HTML for reasons completely unknown. Was some poor example included in the book? Modern ASP.Net HTML is pretty indistinguishable from HTML produced and understood by many tools these days. Perhaps you're instead conflating WPF or Windows Forms development with web development? It's completely unclear. In any case, your vague view that Microsoft adds cruft to anything it touches seems to be firmly rooted in the mid 90s, particularly in the context of HTML.
Finally, as much as I sometimes wish things were different, the dream that all applications will someday be web applications is a very, very long way off, regardless of how much R&D money the likes of Google pour into it. Nothing emphasizes this more to me than the recent CSS animation specification – something that WebKit / Safari 4 require 80% of a dual core MacBook's CPU resources to render a simple demo for. Nope, desktop software will be around for a while yet.
>>simplicity of HTML?
But, Microsoft has learned. There is now something called WPF, which takes the HTML markup style of UI development to the desktop.
Also, you can use IronPython to do web development with with Asp.Net WebForms or Asp.Net MVC.
Guido, this is an incredibly true statement:
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 developmet.
I've recently become a Sharepoint Developer, and I must say that having IronPython has made my life significantly easier and it couldn't happen without Python around.
Web dev is certainly very prolomatic with web standards being all over the place, but ANYTHING is better than developing on .NET. :)
I found Windows programming tedious in 1991. But not in 1995, because then I used Delphi, which had an IDE with an integrated editor for all those kinds of things.
True, there was some tricky bits in that, but the same goes for HTML+CSS and probably most ways of making an UI.
I'd expect .NET development environments to have some sort of resource editors that can do these kinds of things. Everything else would be shocking. I'd be less surprised if you can't use them with IronPython, and if you really can't, then that is probably a shortcoming that must be fixed for IronPython to really take off.
What NEEDS to happen is get imported module "intellesense" in visual studio with IronPython. TabCompletion works fine for imported object models in the ipy.exe interpreter, but not in visual studio.
of course ironpythonstudio wasn't made by the makers of ironpython :)
And you can take CPython, install PyQt4 - API for the QtSoftware Qt library, write a GUI app and make the source code work on Windows, Linux/Unix (including for example Maemo mobile platform), and Mac OS X. Then build a standalone Windows binary with py2exe (7MB for a QtCore/QtGui App), and binary for Mac OS X with py2app (12MB for a QtCore/QtGui App)... and setup.py install script for Linux/alike systems :)
And the application will look native on every supported system (and this also covers system icons, system notifications and so on :))
One code to rule them all :D
You should look at Windows Presentation Foundation. It is new as of the .NET 3.5 framework, and can replace traditional WinForms completely. The UI's are defined using a declarative, XML based syntax called XAML, but can also be built programmatically. It is the driving technology behind Silverlight, but is available independent of it. In addition, it offers transparent, out-of-the-box hardware acceleration. It would be very fitting to use IronPython to drive WPF-based apps.
Sorry, there is no designer for building WinForms or WPF applications with IronPython.
In C# all that code is generated for you.
It would be more appropriate to say that it is generated for you in Visual Studio. That being said, WPF UI's are much easier to craft by hand due to the fact that you can do it declaratively. And, being that it is a neutral language (XML), you could, in theory, use the WPF designer in Visual Studio and write the backing code in IronPython. With Windows Forms, the form designer generates the UI programmatically in either C# or VB, which makes it completely useless for generating UI's for python.
Thanks for all the feedback. It seems though that some commenters haven't read the book. (Also, please share your profile. Otherwise it feels like an anonymous comment -- and I might well delete those.)
No, I wasn't referring to DLL hell -- the inclusion of DLLs in the sourcecode.zip file did not affect my view at all, I just noted it with irony.
Yes, the book discusses WPF, so I'm aware of it. But no, it doesn't seem all that much of an improvement except in the eye candy department. (Color gradients! Video! 3D color charts representing 1 bit of information!)
As for tools that generate all that tedious UI code for you, the book mentions and then largely ignores them -- one author admits he prefers code himself. 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. (Animation effects! Document inclusion! More fonts!)
Guido - I know its hard to imagine but we both know there is still a lot of people in windowland. Look at IE6 usage! Of course they dip their toe in tweetspace, frequent facebook but remember we are way ahead of the curve.
That is changing, too slowly for us code-or-die types but it will. Windows' half life passed around 1995. As for developers-developers-developers? Sure go ahead guys waste your lives assimilating this VB .net ..nextbuzzwordhere... bloat, - I'm even older than Guido! I've been through that sales-cycle at least twice. But never again (last time was around 1995 too). All the time you spend in the winzone you aren't competing with me. (sorry if that sounds crass but 'times is hard folks!') and don't tell me as you post your witty retort online that you too haven't accepted this as fact...
All you need is python...
in terms of Web UI development, what's your opinion on GWT vs. Pyjamas ?
Martin van NIjnatten
Funny that, because JavaFX is really terse to whip up a UI with.
Guido, your long winded diatribe about wanting a declarative UI model shows you didn't try WPF/XAML at all.
it is exactly that, simple XML declarations for layout.
This reminds me of your tail call fiasco.
Actually, the fiasco is people who still believe that XML is meant for users to type.
Now JavaFX, I'd have to agree to a point, although the marketing around it seems to emphasize 3D! Video! Gradients! instead of usability. But I'd take its syntax over XML any day.
(Come to think of it, *nobody* who is marketing UI creation tools seems to care about usability. It's all about Animation! Fonts! Colors!)
And the difference between typing HTML and XML is what Guido? You seem to support the concept of UI's defined in HTML.
You should stop now, its ok to be completely and horribly wrong now and then.
Admit that you didn't even give a passing glance to WPF before writing this pile of malarky.
"I know of no mainstream Linux distribution, for example, that supports such simple resolution."
Actually they all do. There have been various techniques for this over the years, the modern methods work pretty well I think.
Here's an post on the lgp blog about their various approaches which seems to cover the basics.
I haven't read the book, but it sounds like it makes no effort to make a case for WPF/Silverlight+IronPython. Writing UIs procedurally in Win32 or WinForms is nuts in my opinion, but it's completely unnecessary in the modern Microsoft frameworks.
I don't see how you can appreciate the simplicity of HTML without respecting the same simplicity of XAML. In SL, you can create complex, functional layouts with only markup and without specifying pixel positioning. That markup can be equally well used by an app written in IronPython, C#, etc. And if you really think that humans shouldn't write XML, then there are designers that output XAML (and only XAML-- no codebehind necessary if you don't want it).
Also, the platform does include plenty of less flashy features designed to make creating UIs easier and to make the UIs more usable. Data binding is a great example, as are form validation and accessibility features. I actually work on the pretty graphics features of Silverlight, but I think the platform is capable of building useful UIs.
I have read this post several times and I am still wtf.
I like python and it is wonderful in amy ways but I wouldn't use it for windows development. Nor would I use c++. Both suck at it for entirely different reasons.
If you are going to design a windows gui, you use a gui designer. End of story. I know that there are prefer writing a gui in code, but they are few and far between, and not the sort of people you want to hire if you want to actually produce something.
A gui designer won't make your design any more user friendly, but neither will writing a gui in code
I agree Guido. Windows is just painful to develop for. Also your point about not typing XML is dead-on.
I didn't even get why anyone would use XML until I figured out that it's meant for machines and not people (years ago). Jonathan, you are completely wrong -- quit while you're ahead.
I just keep waiting for the day my employer lets me use Linux on my workstation (we use it on the servers! Why not on the workstations? Oh... can't find desktop support people that know anything other than windows? Bugger).
Guido laments that HTML is the holy grail of user interface design, ie:
[input type = 'button' /]
My point is that .NET offers exactly that in WPF:
(Changed < to [ because of stupid Blogger rules about HTML in comments)
The fact that Guido didn't know this, and went on a long rant on having to programmaticly define UI's, instead of declaratively define them, shows that he either didn't bother to do any real research, but wanted to bitch and moan anyways.
I called him out, and I calling you out.
Guido wants a declarative model of UI definition, and his casual dismissal of WPF as "Gradients and charts" shows that he actually hasn't spent any time looking at it.
All of which aren't a problem with WPF.
Guido is a great programmer and a somewhat of an icon, but he is wrong here... and there is nothing wrong that.
I've been wrong on my blog before.
While, I am a religious python user; I have to say that this article is mostly silly. I totally agree with David, Jonathan Holland, and Sean. Web development is simpler only if you don't care about usability or you never actually face with your users in person.
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.
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).
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.
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.
WPF => Microsoft XUL.
"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.
@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.
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 ...)
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.
Maybe you'll catch up in 2015 when HTML5 is released.
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.
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.
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.
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.)
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.
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 :)
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.
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.
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.
> Plus, I don't believe that a GUI
> generator suddenly makes your app
> more user-friendly. More likely it
> helps generating more useless eye
obviously, you haven't used Delphi yet.
As pointed out by the others: nobody who seriously develops Windows UIs is doing it by hand.
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...
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.
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...
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.
Post a Comment