Designerings

I’ve just blogged over on my Artima Blog about choice of languages for AppMakerX coming down to Ruby or Python to replace the proprietary OO language in the original AppMaker v2 (which in turn replaced a truly horrible resource-based template language in AppMaker v1).

Delving deeper into the design-oriented thinking than that post, and deeper into my own psyche, I admit to Ruby being a bright shiny new toy in my mind compared to Python with which I’m comfortable and productive. I can quickly get into a spiral of doubt over my rationalising such a decision, without even going into the possible marketing cachet of a Ruby-based solution.

People with whom I may want to partner for AppMakerX are putting bets in both camps, although I suspect IronRuby and RubyCocoa are well-behind the Python equivalents. It seems, if you’re happy using wxWidgets 2.8, that wxRuby is now up to scratch.

Readers outside the confines of my own mind and possibly occasional ranting to friends will note that I’ve gotten over the Paul Graham effect and whilst retain a fascination for and intent to study Lisp, won’t be using it as an implementation language in any of my products soon. At least, not anywhere that I’m expecting to have collaborators or users fiddle with.

In terms of trying to quantify the trade-offs, I think it comes down to a fairly simple list. I don’t know how the prejudices of above-mentioned potential users work out either way. One of the factors influencing me more towards Python in the past was using it at CSIRO, which is no longer of course anything to worry about. If I do consulting work back there in future it will not be at a coding level other than maybe some C++ maintenance.

Pragmatically, whilst I should be able to claim to know a lot about the Python libraries, that kind of detailed syntax escapes me much of the time and I have to look quickly at the available methods at least. I have a similar feeling about Python as I do about C++ that I’ve internalised so much of using the language, the only main barrier on a given project is looking up the particular libraries and GUI framework.

Technical reasons:

• Python For – know it well, good performance
• Python For – lots of great libraries
• Python For – Komodo has a great debugger and IDE that is cross-platform
• Python Against – considerable worry about whitespace sensitivity in templates
• Ruby For – great example book in Code Generation in Action and suspect it embeds with less overhead than Python
• Ruby Against – some learning curve for the language
• Ruby Against – Komodo support for Ruby is much less mature than Python

Consulting reasons and future projects or playthings:

• Python For – I know there’s a lot of Python-based software development around Perth but honestly don’t know if these are places that will ever hire someone to consult at other than lowly web-developer rates
• Python For – Blender is scripted in Python
• Python For – my XO Laptop I’m picking up in March is programmed in Squeak and Python
• Ruby For – I have things I’d love to try to develop in Google Sketchup which is scripted in Ruby.
• Ruby For – at some point I suspect a Rails job will crop up if I want one, or if I have Ruby expertise will be able to get online from job sites.

Gut Feel: Ruby is strategic and may well be fun but not in the next few months. Komodo and other tools I suspect come at Ruby primarily for web developers using Rails whereas they expect Python to be used by a wider audience.

Decision: For the initial release of AppMakerX I’m going to use command-line invocation of Python. Later will investigate embedding Ruby in REALbasic and C# applications.