Apparently, I wasn’t very clear in my previous post, because almost all of the commenters seem to think that I was talking about using a dynamic language to script parts of a desktop application. That’s not at all what I mean. I think that it will be a success point when a dynamic language (I don’t care which one) is used to write a substantial portion of a desktop application that enjoys reasonably widespread success/distribution. I used Lightroom as my example because that’s the kind of application that is the target. While 63% of the code written by the Lightroom team is in Lua, only around 40% of all the code in the application is written in Lua. I am looking for a much higher percentage. I don’t have quibble with Lightroom’s percentages, because it’s very sensible for Adobe to reuse their C/C++ code for RAW processing etc, and there’s no commercial justification for even trying to rewrite that code in Lua.

We already know that dynamic language interpreters can be embedded in applications. That’s been happening for years and years. But since we are starting to see progress in the performance of dynamic language runtimes, it should be possible to write really good desktop applications using them.

If you are after large distribution, I’d also like to mention pygame. Mostly because there are games made with python and pygame that get millions of downloads. I guess the same is true of wxpython+python programs.

But seriously… there have been many popular desktop applications written in scripting languages for ever. Ever since basic – which is at the start of the desktop era.

Well, Basic is neither a dynamic nor a typical scripting language. Rather the opposite: All modern Basic dialects are compiled, and when you look at Basic-compilers like BlitzMax or PowerBasic, those use strongly typed and static languages that produce compiled code which is at least as fast as the one emitted by any available C compiler. So, no, Basic is not a valid comparison here, not even if it’s VB.NET.

Civilization IV uses Python for its game logic, but I’m still waiting for a success story for PyGame – even that project’s homepage does not name a ‘real’ product that uses it, where ‘real’ stands for a game that has sold at least a couple of hundreds of thousands of copies. The pyglet project also seems to be under more development recently than PyGame, and it looks quite promising – although there are also no high profile/high visibility apps yet being made with it, as it seems.

Unfortunately the same has to be said for wxPython – there are no visible successful applications with large customer bases written in wxPython. At least I haven’t heard of one except for maybe Boa Constructor, which is rather complicated to get running on my platform, OS X, and an IDE is not necessarily a mass market application anyway. I would be very happy to hear of a very successful commercial wxPython application.

In direct comparison and outside of large corporate environments (where plenty of Java desktop apps exist), Java has at least Tribal Trouble (a very nice commercial and successful 3D real time strategy game), CyberDuck (one of the best FTP clients for OS X), Limewire, Netbeans and Eclipse, which both are not only IDEs, but rich client platforms on which several large desktop applications can be and actually already are built (BlueMarie, e.g.).

Deployment issues could be one of the things that is holding Python back on the desktop. Not everybody feels good about distributing source code or easy-to-reverse-engineer-byte code in an application bundle (OS X) or encapsulated in an .exe file. But maybe that’s more of a psychological problem than a technological one.

The reputation of being slow – whether or not this is justified does not even matter – is another issue. This one is still holding Java desktop apps back, although there are success stories like Eclipse out there.

Other problems that I see could be the fact that Python does not necessarily come with a modern GUI framework out of the box, and it does not come with pyglet or Pygame either in the standard distribution.

Then, as a Mac user in the year 2008, you don’t want to be caught writing Carbon-based applications anymore – but that’s all that wxPython will give you. And if you begin using the pyobjc-bridge: Why would you want to do that in the first place? When you’re giving up multi-platform capabilities, you could as well go with the native Objective-C language which has higher performance to offer than Python but at the same time is still dynamic and even garbage collected.

On Windows, you’d face a similar situation with C# and the .NET framework, and you’d have to ask yourself the same question whether it makes any actual sense to use Python instead of the platform’s native language.

Linux might be a different story, but Linux is far from becoming a widely accepted desktop platform in terms of user base and market share. It’s a huge server platform, but still basically irrelevant on the desktop.

@Gus: Only Checkout was written completely in Python, Versions is mostly Objective-C, with the exception of some example comparison scripts we shipped. We do have two more releases lined up that are both ‘pure’ PyObjC apps.

Three of the most important caveats of building an entire Mac app using PyObjC are that (1) afaik. you can’t use breakpoints, (2) that you might have to wrap some low-level C stuff that doesn’t have an accessible API up in for instance Objective-C frameworks (so you’ll need to be moderately proficient at ObjC too) and (3) that you’ll have to port almost all sample code and documentation on any Obj-C API that you’re using in your head before you can apply it to your code.

Some of the biggest advantages are that you can use any Python library that fits a particular purpose and that you get to code in a language that imho. is inherently easier to read and write when you’re working on eg. business logic, complex data structures, text manipulation, and almost anything that’s somewhat fuzzy in it’s implementation.

“I think that it will be a success point when a dynamic language (I donâ€™t care which one) is used to write a substantial portion of a desktop application that enjoys reasonably widespread success/distribution.”

How about emacs?

I also read an article once by one of the lead developers of Microsoft Word that said that all versions of Word up to 6.0 were mostly written in WordBASIC, with only the BASIC interpreter and low-level functions written in C.

Winfried: “Deployment issues could be one of the things that is holding Python back on the desktop.”

Exactly, plus the spelunking necessary to figure out how to do it. +Licenses, Libraries and Eggs–O My!
Deployment needs to be relearned for each platform, expected, but it leaves one wondering which features may not be implemented yet on the next platform.

Thanks for running with this Ted. Things are getting better but still a hard sell since Chandler was announced. When it was announced we heard of this cross platfrom Python app that not only required a lot of GUI, but also a lot of communication and data handling. This project seemed a mercenary for finding and making strides in these apps. Lots was done, but platform specific tools still win out, and as for cross-platform, easy to GUI (build and view) and deploy still are much more attractive when considering language platforms.

* Winfried Maus – I think basic is one of the original scripting languages. Also modern basic still has ‘eval’… which makes it quite dynamic in my mind… but still not really dynamically typed I guess. Definitely highly interactive, and meant to be a ‘RAD’ language.

I mentioned that single games made with pygame have had millions of downloads. That’s a fairly ‘real’ success by anyones standards.

pygame has more people writing code for it, and more new features than pyglet. Not to say that a lot of good work is not going into pyglet(Alex is a coding machine). However there’s another dozen or so game libraries available for python. Including things like blender, crystalspace, ogre, soya3d, and panda3d (used by disney for a few popular games). In the disney games for example(written using panda3d), a lot of the application level code is written in python, with the other languages being C++, asm, shader languages.

Bittorrent uses wxpython, and is one of the most popular desktop programs of all time.

You seem to have defined commercial as a pre-condition for realness or success in this conversation. In terms of software, I think people using the software is one of the most useful metrics of success… but like selling software… it is only a small part of how success for software should be looked at. Especially for software that is more art, than utility – other criteria for success are far more important.

I also think that ‘pure’ programs are often missing out on things. Using multiple languages provides the best way to use the best tool for the job. Certain languages are way better at doing certain things, so mixing languages gives you the best of all worlds.

Maybe Sketch/Skencil? It’s all Python, about 50kLOC. Jokosher is 7kLOC of Python. Likewise Mercurial; bzr? MayaVi? (But they’re fairly small compared to the Python interpreter.) And obviously Emacs, which is 1.3 million lines of elisp on top of only 350 000 lines of C. (Numbers from find and wc -l.) How much of QGIS or Miro is in Python? How about IDLE?

I regularly use AptOnCD.

I don’t think Mozilla qualifies; less than 50% of the code by volume is in JavaScript, although maybe more than 50% by functionality.

So, Ted, any interest in collaborating on an OSS Lightroom/Aperture competitor, using a dynamic language for large portions of the work?

I’m half-serious on this — it’s been a dream of mine for a while (and I have lots of ideas of specific goals I’d want it to work on achieving), but with a collaborator or three, maybe it could become a real project??