I need a format for the documents stored by AppMakerX that allows for storing abstracted interface documents. The format needs to store a sufficiently flexible UI description to allow for mutating objects and people sketching vague interfaces where they know something might be in a given place but aren’t sure what type of control they want. The question is whether XAML is sufficiently flexible to fill this role because having a tool-chain that works with XAML is attractive from a marketing position. (more…)
Archive for the ‘AppMakerX’ Category
I’ve been debating for a while the Ruby vs Python choice for writing a code generation template. With a (self-imposed) deadline to get something working at least roughly to show off at REALWorld and the research into Python template engines being more distracting than I’d considered, I am now rethinking.Specifically, I’m thinking about hard-core REALbasic users wanting a wholly-RB product and how they might feel about being asked to customise templates written in another language. As I think more about the patterns for how templates are written, I think I can not only quickly throw together some pure-RB templates but also that the exercise will teach me more than trying to decipher other people’s template logic. (more…)
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.
- 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.
Full rights to AppMaker were acquired some years ago from Spec Bowers but due to failure of Apple to document some things and the source code being in an older version of CodeWarrior, it didn’t really make it to OS/X.
The new version separates out the code generation side in the Python language, replacing the proprietary OO language which Spec had created and working on an intermediate format closely related to XAML. The initial cross-platform GUI editor is being written in REALbasic and will invoke the Python-based code generator.
A Windows-specific .Net editor is also being developed. Source code for both will be available for licensing.