Code by Kevin

About
Code by Kevin, Programming, code, business, and other pursuits

Your Host
Kevin Walzer, software developer.



Home

Subscribe to RSS Feed
Get a syndicated feed of my weblog.

Archives
2020
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
2007
2006

Categories
Business
Software
General

Privacy Policy

Site design: Skeleton

 

Fri, 11 May 2012

Scripting languages for desktop apps on OS X: Why not?

I recently ran across a blog entry by Chris Adamson, in which he discounted the idea of a Ruby-based development environment for iPhone, and it got a bit of steam coming out of my ears. I have no special interest in using Ruby to develop iPhone apps, but the basis of his reasoning grates in my craw: a major effort by Apple to make scripting languages a "first-class environment for Mac development" was a bust, and therefore, scripting languages aren't suitable for application development. Here's a quote:

The reason I can say that is that Ruby was already tried and rejected as a first-class language for Mac development. In Leopard, Apple made Ruby and Python first-class languages for Cocoa development, creating Cocoa bindings for those languages and fully supporting them with Cocoa-Ruby and Cocoa-Python project templates in Xcode. Tutorials were posted... code was open-sourced... developer sessions were presented... And yet, there's no indication that there was any significant developer up-take. The Ruby and Python project templates disappeared in 10.6s version of Xcode, a seemingly quick admission of defeat, or at least irrelevance.

And this:

I'm not going to say that the C-based languages are ideal for desktop and mobile development, but the fact that they haven't been seriously challenged by the scripting languages, despite all the interest in and shared knowledge about scripting languages, makes me think that that they're the best choice we have.

To which I reply: the best choice for whom?

This circular reasoning--scripting languages with Cocoa bridges haven't become popular, therefore they are lousy choices for desktop development on OS X--grates in my craw. His corresponding assertion--that because scripting languages are unpopular, therefore C-based languages are the best option--is even more dubious. Speaking as the developer of a half-dozen commercial desktop apps, all in scripting languages, I find the suggestion that scripting languages are unsuitable for desktop development to be not only absurd, but patently false.

First, Mr. Adamson, popularity is not a measure of any intrinsic value. It simply measures the quantity of individuals who have a favorable opinion of something. No one should make development decisions using the logic of the Facebook "like" button.

Second, Mr. Adamson, your summary of Apple's push to make scripting languages first-class development environments is superficial. I'm not an expert on Ruby, but I can tell you that PyObjC (the Python-Cocoa bindings that Apple briefly supported in Xcode) existed long before the release of Leopard, and still exists even following the removal of the Cocoa-Python Xcode templates in Snow Leopard. PyObjC has been continuously maintained since the days of NeXT. Its developer community is small, but those developers are releasing successful commercial and open-source applications based on it.

Finally, Mr. Adamson, you appear fundamentally unsympathetic to the viewpoint that scripting languages can be used to develop desktop applications. Outside of arguing that scripting languages are unsuitable because they are unpopular, the only technical point you make is by referring to the "inescapable overhead" of a scripting language--i.e, that they are not as fast as a compiled language. But mostly you speak of popularity contests:

It is not plausible to think that lots of developers haven't already tried to use scripting languages for desktop apps. Surely they must have, and the results haven't yet been compelling enough to dislodge the compiled C-based languages.

I would challenge the statement that lots of developers have tried scripting languages for desktop apps. A sympathetic argument suggests that Apple has touted Objective-C/Cocoa for a long time, most developers have become competent with Cocoa, and are disinclined to try anything else. A cynical argument would point to snobbery on the part of some Cocoa developers, that they believe scripting languages to be developer toys and unsuited for serious development. (Mr. Adamson, I think you are guilty of this to a degree.) Regardless, a two-year effort to promote Ruby and Python as alternatives to Objective-C for Cocoa development isn't going to have a huge effect on the installed base of Cocoa developers.

I'd also like to make an alternative case for scripting languages, outside of the context of scripting language bridges to Cocoa. My preferred GUI toolkit is Tk, which is based on the Tcl scripting language, and which has bindings to a number of other scripting languages, including Python and Ruby. Tk runs on OS X, Windows, and various flavors of Unix, and it is the only major GUI toolkit that is optimized for scripting languages instead of being based on a C/C++/Objective-C framework.

I first gravitated to Tk as a beginning developer, about a decade ago. At the time, Cocoa seemed intimidating, but learning Tk was dead simple. The canonical beginner's exercise in Tk is this simple line of code:

pack [button .b -text "Hello" -command {tk_messageBox -message "Hello world!"}]

This code, saved in a script file or executed in an interactive session with the Tcl/Tk interpreter, draws a button that, when pressed, pops up a dialog saying "Hello world!"

This friendly, low-friction way of programming--quickly specifying a UI in code and testing it--led me to develop more complex programs fairly quickly. I began programming with Tcl/Tk in 2003, and a year later, I released the first alpha version of PortAuthority, my GUI for the MacPorts software installation project. Even with my relative inexperience, PortAuthority gained a user base because MacPorts at the time lacked any kind of GUI tool, and it has remained the leading GUI tool for MacPorts (and my best-selling program) ever since. Along the way, I also developed some skills with Python, and began releasing Python-Tk programs as well. Over the years I have developed a file search application; a GUI for another software installation system, Fink; a browser for man page documentation; a domain search tool; and a GUI for a command-line network monitoring tool. And I have other applications under development as well.

Tk's appeal reflects the appeal of scripting languages in general: the rapid development cycle, the ability to achieve great power in fewer lines of code, and the lower learning curve. Further information about Tk can be found at a superb documentation site by Mark Roseman, TkDocs, and the main Tcl/Tk website.

This brings me to the biggest objection against Tk: because it is cross-platform, it is not optimized for the Mac, and provides a poor user experience as a result. It looks somewhat out of place, and does not hook into a great deal of system-native functionality that is provided by Cocoa applications. That is a fair criticism, and the answer to it is to find ways to integrate Tk more fully into the Mac. I have attempted to do this by learning a good deal of Objective-C and writing various libraries to integrate Tk and the Mac, to the point where I am now one of the core maintainers of Tk on the Mac.

Even though I prefer developing with scripting languages, being a maintainer of Tk on the Mac has forced me to become competent in a number of Cocoa APIs and design patterns, as well as C and Objective-C. Apart from having a basic knowledge of NSView, NSWindow and other APIs for maintaining Tk's Cocoa port, I've written Tcl/Tk extension packages that hook into the NSServices API; drag and drop; printing; icon display and manipulation; and more. (Browse the Subversion archive at http://tk-components.sourceforge.net for examples of my Objective-C code.) Nonetheless, although I can find my way around these APIs, I have no interest in using them for application development. My view is that Objective-C is a low-level systems programming language, necessary for accessing native APIs and necessary at times for raw speed; in these respects it is very powerful. But embracing the entire Cocoa application development gestalt, writing applications in a complicated low-level compiled language and trusting my entire development process to Xcode and Interface Builder, is uncomfortable for me. Xcode and C/Objective-C are heavy, complex, and cumbersome, when my development practices stress lightweight, simple, and agile practices: write my code in a text editor, run my code in the Terminal.

I suspect that my long experience in writing Tk GUI's in code has made it harder for me to embrace the Xcode approach. Most of the main code packages of my applications don't exceed 2,000 lines of code, and the no-compliation nature of coding in a scripting language means that I don't have long delays in trying out different ideas, then waiting for the application to compile again. If your experience with GUI development is coding UI's in C++ or C, then perhaps the Xcode/Interface Builder approach is a big win. (One of the reasons Tk become so popular on Unix in the 1990s was just this--the prevailing method of coding UI's, using the Motif C API, was extremely painful, or so I'm told.)

To bring this back to the main point of my rant, and the suggestion that lack of popularity signifies that scripting languages are unsuitable for desktop application development, let me conclude with a challenge: Do you want proof that scripting languages can be used to develop desktop apps on the Mac? Just download one of mine, and see.

[/general] permanent link

QuickWho for Mac OS X still in review

I'm pleased to report that QuickWho 1.1 for iOS is now available in the iOS App Store. I had submitted this release to Apple at the same time as QuickWho for Mac OS X, but the OS X version has been delayed over a period of weeks because of issues that Apple's automated upload process had flagged with the Mac version. These issues, which had not been previously flagged by Apple, required some significant under-the-hood restructuring of the application before the upload would even go through. That process is now complete, and now QuickWho for Mac OS X is now being reviewed. Hopefully it will be released soon.

The specific technical issues that Apple's automated upload process flagged concerned how some supporting libraries, or "frameworks," were bundled inside the QuickWho application package. Apple's guidelines require these libraries to be organized in a certain way, and the automated upload tool said that some files were missing from my upload. After correcting this issue, Apple still said the files were missing, although they were correctly included in the package I uploaded. After several efforts to get the application submitted, it became clear to me that either Apple's tool was in error or the application package was somehow being corrupted during the upload. Regardless of the cause, I had to shift gears and do some significant adjustments of how QuickWho is laid out "under the hood." This required moving away from the tool I had long used to build QuickWho, py2app, to cx_freeze, which structures its applications a bit differently and avoids the issues flagged by Apple. (This also required me to do some coding on cx_freeze's internals themselves, because cx_freeze's support for OS X is quite new and untested; this is a classic case of yak shaving.)

Now, finally, I've gotten QuickWho sucessfully uploaded, and I hope that it will be approved in a timely fashion.

If you're reading this and you're a Python developer who is submitting Python applications to the Mac App Store, I'd recommend checking out cx_freeze as a potential tool to add to your toolbox. py2app is terrific and handles things in a more Mac-native way, but I'm glad I was able to find an alternative deployment tool; otherwise I would have been stuck because Apple's opaque submission process left me unable to troubleshoot the problem via py2app.

[/software] permanent link