Code by Kevin, Programming, code, business, and other pursuits
Kevin Walzer, software developer.
Subscribe to RSS Feed
Get a syndicated feed of my weblog.
Site design: Skeleton
As I noted previously, I'm open to experimenting with new approaches to developing my applications. Toward that end, I spent the past couple of weeks playing with RealBasic, which is used by many independent Mac developers to develop their applications. At $100 for a Mac-only license, RealBasic was inexpensive enough that I was willing to give it a try. (RB has a two-week demo period, which I found to be insufficient.) RealBasic hooks into much more of the Mac out of the box than do Tcl/Tk or Python, my primary development languages. Plus, with a nice drag-and-drop utility for creating slick GUI's, I thought RB might be a good addition to my toolkit; it would help me build nicer-looking, more powerful applications, more quickly.
Unfortunately, I'm disappointed. RB doesn't feel like it's going to be a solution for me.
Some of this disappointment stems from my own learning curve, of course. I experienced this with Python at first, before getting my bearings in the new language, and then finally shipping a finished application in Python. RealBasic is very different from Tcl and Python. Getting proficiency would mean a period of months, most likely.
Still, in just a couple of weeks, I have bumped into some barriers that make RB a bad fit for my needs, or not worth investing more time in.
First, some of the GUI's I built proved unexpectedly ugly. The images in toolbar icons didn't display correctly--it turns out I need to install a free third-party plug-in that supports my image format (png). Why does a commercial IDE lack this (pardon the pun) basic functionality?
Second, despite what RealBasic's promotional materials say, my development time didn't seem to be reduced much. Throwing together a GUI is faster, but everything else is slower, because you have to compile everything. I learn a programming language best by playing around with it, and trying different things; such an approach is very feasible with a scripting language, where code is executed by an interpreter. You don't have to wait for things to compile. Unfortunately, that's not the case with RealBasic. Worse, even if I'm willing to accept the additional time required by compiling, the $100 version of RB doesn't let you build real command-line (console applications)--I'd have to spend an additional $400 to get the Professional version! (Console applications are easier for learning the basics of a programming language itself, because you are not adding the overhead of graphical components.)
Third, the biggest disadvantage of my current programming environment--its lack of full Mac polish in the GUI components--is rapidly going away. After posting some questions to a Tcl/Tk mailing list about how to render a certain GUI item in a Mac-like style--the standard search toolbar--someone posted a coding solution that solved the problem. Another recurring complaint about the "look" of my applications, their lack of a Cocoa-style toolbar, is also easily solved, it turns out; a bit of coding on my part has produced some samples that work quite well, so it won't be too hard to integrate this into my programs, and I will in turn share this code with others under an open-source license. Scripting languages, in general, have large, supportive communities that make it easy to find freely reusable components for that programming language; RealBasic, by contrast, has less of this kind of code and more proprietary extensions that require additional cash outlays.
Fourth, the kinds of applications I still have on the drawing board aren't really feasible in RealBasic. One of the applications, a file-transfer program, will be simple to do in Python. Achieving similar functionality in RealBasic would require the purchase of expensive additional components, and even those components wouldn't fully implement what I need.
Finally, RealBasic would be much harder to integrate into my current development frameworks. I have a very large library of Tcl code that manages various utility functions of my applications, such as checking for new versions. Adding Python as a development language wasn't easy, but it was worth the effort because Python's Tk GUI bindings allow me to call my Tcl code without modification. This wouldn't be feasible in RealBasic.
There's no doubt that my three years of development experience with scripting languages--particularly Tcl--have given me a strong bias in favor of that approach. It works for me. At this point, since I am an independent developer and have the luxury of choosing my own tools, that's my criteria: any tool I choose has to work for me, and has to work with what I already use. That's why, despite the difficulty and frustration of learning even a rudimentary amount of C--the lower-level language that Tcl itself is built with--this was helpful to my work, because it allowed me to code a extension to Tcl that accesses Apple's Help system. RealBasic, however, doesn't integrate smoothly with what I already do. (Neither, for that matter, does Cocoa/Objective-C.) So, at this point, I'm going to stick with what works for me. In this sense, I consider my experiment with RealBasic to be a success.