AstroPlanner

Having written part 1 while suffering from a severe bout of quasi-depression because I was unable to get my software compiled with the almost-final-release of the IDE I use, I was all ready to make Part 2 a meandering diatribe about software quality, etc. However, after several hours of scouring my code I finally located and fixed the problem that was causing the IDe to crash. Hence I’m somewhat mollified. The howling gale in my sails is now just a stiff breeze.

Perhaps I should talk a bit about my choice of development tools, which seems to make some of my more software-development-savvy users’ eyes roll.

My current tool-of-choice is a language/IDE called REALbasic. Eyes start rolling. “BASIC? Surely that’s for 13-year-olds and amateur software developers. Are you saying that AstroPlanner is a collection of code that looks like:

10 REM Code starts here
20 LET A1 = 12
30 GOSUB 1200
...

?”

Well, no. REALbasic is a full-blown compiled (not interpreted) object-oriented language with some pretty sophisticated syntactical features. It’s about as close to 1970’s BASIC as an ox cart is to a Maserati. It’s far from perfect, but it does have some compelling advantages (for me).

When I first started programming AstroPlanner, Mac OS X had been announced, but I was still using the Mac Classic OS (Mac OS 9). The only compiler IDE vendor was Metrowerks, and it was vanishing faster than a puddle in Nevada. I had used it over the years to develop code in Pascal, and that was dropped in favour of the Flavour Of The Day, C++.

I don’t “do” C or C++. C is a crude, non-object-oriented, assembler replacement language, designed to write low-level code. C++ is an over-engineered object-oriented edifice built on top of C. It’s very easy to write completely obscure code in C++, and difficult to write code at a fast clip. I like strongly-typed OO languages that are designed to assist the programmer.

I briefly dabbled with Java, a half-way decent language, but my bookshelf filled so rapidly with ever more voluminous books about the frameworks, that I very soon was unable to stay current. Also Sun was not helping by ignoring the Mac, leaving Apple to do all the engineering (that has now changed, and Mac OS X is now the platform of choice for Java development, I’m told).

I had for many years used Borland’s Delphi for several large and complex projects. A very nice, very stable IDE based around object-oriented Pascal. However, it had one major disadvantage – it was Windows-only. Fine for the (salaried) work I was doing, but not for Mac development.

Then I discovered REALbasic for the Mac. It was an object-oriented language, with several very compelling advantages (the Pro version):

• RAD (Rapid Application Development) IDE made it very easy to throw together simple apps.
• Compiled code (no run-time interpreter or libraries required).
• Built-in SQL database support.
• Built-in scripting language (also REALbasic).
• Compiling applications to various platforms from one set of source code (Mac Classic, Mac OS X, Windows, Linux).
• Remote debugging (debug a Windows app from the Mac).
• Not terribly expensive.
• Excellent support and user support forums.

The IDE also runs on Mac, Windows and Linux, and compiles to all the other platforms.

Pretty cool huh?

So I assimilated this product, mainly for it’s ability to run on the Mac and produce Mac applications.

Of course, there’s always some downsides (apart from the BASIC stigma), some of which have accumulated over the years:

• The IDE is enormous. My 2GB RAM PowerBook is constantly thrashing. This is a side effect of the IDE being written in itself (yes, the REALbasic IDE is now written in REALbasic), and many large frameworks.
• Applications (even Hello World) are large. They include all the required frameworks, which can be many megabytes in size.
• The IDE is buggy. This is a side effect of the vendor being a small company with limited resources, together with the fact that they are using a faulty product to develop the faulty product (eating their own dog food, as the saying goes). Each release fixes a bunch of stuff and breaks a bunch of stuff. It deserves a long blog entry of its own. That being said, the vendor does seem to be moving towards spending more time on fixing bugs.
• Cross-platform apps are difficult to get right. This isn’t only a problem with REALbasic. A cross-platform app is largely a compromise, especially if the GUI elements are shared.
• Flawed release regime. REALbasic has a new release every 90 days or less. I used to think this was a good idea. Not any more. 90 days is not long enough to get bugs out of the software.

However, that all being said, REALbasic allows me single-handedly to create, support and update a complex cross-platform application in a reasonable time-frame. If I was using Java or C++, we’d still be on AstroPlanner V1.1.