How Personal it feels when Something Stops Working

I know this sounds a bit of a silly title because feelings are about things being personal but that was the phrase that came to mind. (Followed about 30 seconds later by blast, I’m writing in Safari again). I live in Safari and the need to fire up FireFox just to edit a post with a few paragraphs is driving me crazy. (Yes, I know about MarsEdit and other blog products but I’m trying to immerse myself in a certain consumer experience, even if it has lumpy bits.)

Anyway, this started out being about the REALbasic bug that just bit me and a particularly irritating one it is too – something broken when I open an old project. In a sense, it’s about the arrogance and greater responsibility of binary formats and owning the user’s entire life.

All Bound Up

As of RB2008R1, REALbasic versions are still shipped with the IDE, language (ie: compiler) and framework all irretrievably bound together and no way to mix versions. For a start, that possibly keeps their support costs lower, although they could just outright refuse to answer a tech support issue for someone with mixed versions. It certainly would keep engineering costs lower in terms of the initial outlay required to unbundle the product. In the longer term, I think they are possibly missing out on a great market as well as inflicting vulnerability on users.

In contrast to my experience with say PowerPlant, the lack of framework source code and the inability to mix things means I might just be stuck. I might need to use a certain compiler version but have a framework bug I can’t work around or be bitten by an IDE bug. Some long-standing RB users with many clients report having as many as four current versions installed (thankfully easy on OS/X) because they need to balance the mix of bugs and features for those clients.

So, on balance, I would strongly encourage RS to consider unbundling as part of a push into a more professional marketplace.

File Format Compatibility

One of the problems of success and longevity is dealing with legacy file formats. In particular, for a programming environment, example code may still be highly relevant from many years ago, especially if it is not particularly sensitive to OS changes.

Even when people write simple apps to demonstrate algorithms, file processing or other utterly non-GUI code, they tend to do so with a simple GUI and a Desktop Application style of project. Indeed, prior to RB5.5 you couldn’t write anything else and a surprising amount of useful code predates 5.5.

You might be looking at a sample because you are interested only in the non-GUI portions of sample code. It is intensely annoying if you can’t just load and run the sample because of bugs importing older formats.

I would like to conclude with a recommendation for people to save their sample code in XML format rather than binary, so it can be guaranteed to import into later versions of RB. I’m not actually sure, now that I write and think about it, how much that would help. True, it gives hope of having a textual format you can at least retrieve bits from by hand. Being XML, if there’s a major incompatibility in future someone could write a transformer from old XML to a contemporary RB format. I’m just not sure there’s enough documentation on the intended and actual variation in the XML project format and parsing quirks to make this worthwhile.