REALbasic 2005, Release 4
Developer: REAL Software
Price: $100 (standard edition); $400 (professional edition, introductory price)
Requirements: 600 MHz G3 with Mac OS X 10.2.8, 512 MB of RAM; executables require Mac OS 9.1 or Mac OS X
Recommended: 800 MHz G4 with Mac OS X 10.3.9, 768 MB of RAM
Trial: Fully-featured (15 days)
I have long been searching for my Holy Grail of database development. My primary job is to create software to allow users to access databases in a business environment. Usually, I create this software on my PowerBook, but when the client is using it, it generally needs to run under Windows also.
So, the Holy Grail for me is going to be an environment that allows rapid development and cross-platform builds. For over a decade, I’ve been using FileMaker Pro to accomplish these two goals, but FileMaker, even if it’s easy to use and allows powerful custom databases, has a number of limitations that have grown more and more annoying over the years. FileMaker doesn’t create compiled software, which means that to use a FileMaker database you need to either have FileMaker or a runtime version of it. Capturing events with FileMaker (such as when a user exits a field) is difficult at best. This means that many things users request either require a plug-in or some fancy programming, when, in my opinion, it should be easy. Finally, the interface of FileMaker databases has to be built from scratch. If I want the system to look like a Mac’s Aqua interface, I have to recreate the graphics for such an interface, and when the program runs on Windows, it will look exactly the same, rather than like a native Windows program.
Now, if I were building just for the Mac, I would use AppleScript Studio, part of Apple’s Xcode development environment. But since I need to create cross-platform solutions, I’ve long considered looking into REALbasic, which ostensibly gets around all of the limitations of FileMaker. This review is written from that point of view, so you’ll often find comparisons between REALbasic and FileMaker, as well as AppleScript, which is another language I’m familiar with.
What Is REALbasic?
REALbasic is a complete object-oriented programming environment available for either Mac OS X, Windows XP/2000, or Linux. In addition to being able to create software for all three of these platforms, it can also compile for Mac OS Classic.
REALbasic is an integrated development environment, which means that everything is done within the program, from laying out the interface widgets to writing the code that gets executed. It comes in two editions: Standard and Professional. Given my cross-platform requirements, the Standard edition is useless to me, as it will only compile for the platform it runs on. The software comes with a built-in single-user database engine, although the Professional edition is required to connect to a database server. That server can be any of a number of SQL servers, including MySQL, or even FileMaker Server.
The pricing for REALbasic is somewhat complex. You can buy the Professional edition for $500, although at the time I write this it’s available at an introductory price of $400. The Standard edition is available for $100. Whichever edition you purchase includes six months of updates. In general, REALbasic is updated every 90 days or so, which means that the purchase will include at least two and perhaps three updates. Once this subscription expires, you can continue to use the version you have, or renew the subscription for one year. This annual subscription seems to be half of the purchase price, so that the Standard edition subscription is $50 while the Professional edition subscription is $200.
Although these prices are comparable to the prices for FileMaker Pro and Advanced, two facts should be kept in mind: first, when building a system in FileMaker Pro, the only way it can be used over a network is if each of the client Macs has its own copy of FileMaker. Since REALbasic programs are compiled, this isn’t an issue. Second, REALbasic offers many options for the backend database server, including MySQL. Depending on how you are licensing your own software, you may be able to use the MySQL server for free, or for as little as $295 (or as much as $4,995 for higher levels of service from the publishers of MySQL). In all likelihood, the lower cost license, if a commercial license is required, will probably be sufficient. The point being that using REALbasic with MySQL will probably result in lower costs to your customers.
BASIC in REALbasic
As the name of the product suggests, REALbasic uses a dialect of the BASIC programming language, which was actually the first programming language I ever used, back in the Atari 800 days. REAL Software has extended the language to include object-oriented features. For a programmer, learning the language will only take a half hour or so, but it’s also simple enough to be a good introductory language for the beginning programmer.
In fact, sometimes I find the language a bit too geared toward the beginner. For instance, in most programming languages, the case of variable names matters. A line reading a = 7 and another reading A = 7 are completely different in, for instance, Objective-C or PHP. In REALbasic, these are the same. Case never matters in REALbasic. Not only are variable names case-insensitive, but the language keywords, such as if and dim can be written in lower case, upper case, or mixed case. I personally prefer lowercase, which is what I use, but REALbasic occasionally uses initial-caps without letting the user change it (when defining methods that return a value), leaving me with the choice of either ignoring the instances I can’t change, or of ignoring my preference to be consistent with the default.
A prime feature of object-oriented programming is the ability to define a new class that has all of the properties of another but that can be customized with new features, a process called subclassing. For instance, REALbasic comes with an EditField class that allows users to type information into a text field, among other things. However, by default, the text within an EditField object isn’t selected when the user enters the field. I can subclass EditField and change the behavior so that my subclass does select the text when the field is entered.
REALbasic doesn’t allow all of its built-in classes to be subclassed, which just defeats the purpose of subclassing, or more precisely, REALbasic blurs the difference between raw data types (such as integers and strings) and class data types (such as windows and edit fields). A string is a raw data type in REALbasic; it can often be treated as a class, but it can’t be subclassed because it isn’t a real class.
Most languages include not only variables, but also constants, named pieces of data that do not change. Unfortunately, constants can’t store just any data type. Classes seem to be off limits, and so are arrays, which means that when a constant of either type is required, a variable or property has to be used instead, which defeats the whole purpose of constants. I should note that this is a common complaint for me with regards to programming languages. I’ve recently found myself complaining of the same limitations while programming with PHP.
Even with the data types that can be stored as constants, if a string constant is very long, editing it is difficult because the text field for doing so is rather small. This is especially an issue with database development, as the code that defines the database’s table and fields should be a constant (as it won’t change during the execution of the software), but can be rather long, since the single string is defining the entire database. I did find a workaround, but it shouldn’t be necessary.
Editing a Lengthy String Constant
Regardless of these minor annoyances, REALbasic makes object-oriented programming easy to understand and easy to use.
The greatest portion of programming is spent typing text, so the code editor of a programming environment is key to how efficiently software is created within it. In this, REALbasic again makes things easy. FileMaker effectively has two code editors: one for entering calculations, which are typed directly, and another for creating scripts, where each script step isn’t typed in, but selected from a list. After one becomes proficient with FileMaker, double-clicking a script step every time gets tedious, and it’s refreshing to be able to simply type all of the code. In fact, REALbasic has spoiled me in at least one major sense: the text editor includes auto-complete, where a language keyword or variable name can be entered by typing the first few characters followed by the tab key. After using this for a while in REALbasic, I’m sorely missing the feature when creating calculations in FileMaker and Web sites with PHP in BBEdit.
There are some interface glitches within REALbasic that are annoying. For instance, you can choose from the menu to hide the toolbar (which I never used). This tool bar has a location field that displays which object of your software is being viewed. But even when the toolbar is not being viewed, sometimes the location field still shows up over the tabs of your objects. It seems that this happens after running the project, and I believe that REALbasic was written with REALbasic, which brings up the question of whether this kind of interface glitch will show up in software I create.
Tabs/Location Field Interface Glitch
When creating classes, REALbasic offers a hierarchal system for navigating all of the parts of the class, such as constants, properties, and methods (functions and procedures). Except for event handlers, anything listed is created by the user.
Event handlers are available methods of interface controls that will execute code when the event takes place. For instance, if I have an edit field in a window, an event handler exists called GotFocus. Any code within that event handler will execute whenever the user enters that field.
Most event handlers of most interface controls remain unused and empty. Generally, the only event one needs to capture for a button is the Action event (when the user clicks the button). If I remember correctly, FaceSpan, an environment that works similarly to REALbasic, offers the ability to hide event handlers that are empty. Such a feature would be nice in REALbasic. When a window includes dozens of interface controls, showing all of the event handlers, including the empty ones, makes for a cluttered window and requires a lot of scrolling.
Navigating Event Handlers
Probably the most important piece of a development environment after the program itself is the documentation, and this is REALbasic’s weakest area, especially when compared to FileMaker. FileMaker’s built-in help system is easy to use, complete, and accurate, and I use it daily to look up functions and script steps. In contrast, REALbasic’s documentation is mediocre to use, incomplete, and inaccurate in many places.
The documentation comes in two primary forms: a user’s guide, which supposedly covers how to use the program in general (i.e., how to create a subclass or edit the layout of a window), and a language guide (describing how the language works and providing a reference to the built-in objects).
The language guide is the most important part of the documentation. The user’s guide is great when you’re first learning the program, but once you know how to use the software, if you’re using it regularly, you’re not going to forget how to use the software. Remembering each and every built-in class and each and every method and property of those classes is impossible, however, which means that accessing the language guide is a regular occurrence, and it needs to be complete and accurate. However, after using the software for only a couple of months, I’ve found numerous places where the documentation is either unclear, incomplete, or inaccurate. The language guide includes non-existent methods while it’s missing methods that are available, and given that my primary use for REALbasic would be to create database applications, I found the information regarding databases to be rather sparse.
Here is where REAL Software’s Getting Started mailing list has been invaluable. A number of times more experienced users who frequent this list were able to help out where the documentation failed. Honestly, if you begin using REALbasic, I can’t recommend highly enough joining this mailing list.
REALbasic does an admirable job of guiding interface creation toward human interface guidelines. When building an interface, the final look of it will depend on the platform the software is run on. REALbasic goes toward assisting with this by allowing the ability to view menus as they will look on any of the platforms, but the final look of windows can only be checked by running the software on each platform. A nice feature would be the ability to see what windows will look like as we can with menus.
Possibly because of the cross-platform nature of the software, not all of the Aqua interface elements are available, and those that are don’t include all of the options one would have if creating software with Interface Builder. As an example, Interface Builder offers different sizes for many interface elements. Checkboxes can be either regular, small, or mini sized, and I actually prefer the small size to the default regular, but REALbasic only offers the regular size. There’s no option for an oval search field like what is shown in Safari. After some searching on the Internet, I’ve found custom classes and plug-ins that will offer these features, but these generally seem to be platform specific, and therefore not an option for software I write.
REALbasic’s target market seems to be divided between two types of users: the beginner and the professional developer. If you’re trying to learn programming on the Mac, you’ll save some money by beginning with AppleScript as the language and AppleScript Studio when you want to build software with a graphical user interface. Everything you need comes with your Mac, and the programming concepts you learn in AppleScript are easily carried over to REALbasic if you later need cross-platform compilation.
If you make your money from making software, and need a cross-platform solution for a backend database, REALbasic is a good solution. It has its own, different, imperfections when compared with FileMaker, and the documentation issue, while major, is offset by the helpful and experienced people on the mailing list. The simple ability to capture events, enabling much more powerful user experiences, makes REALbasic at least worth looking into. A major question for me that only time will answer, is how quick development will be within the software once I’m familiar and comfortable with it. My gut feeling, however, is that the learning curve will be worth it.
Reader Comments (7)
I've worked with both Applescript and REALbasic. I think applescript is a terrible language for beginners. Although it reads well, it writes terribly -- it has a picky syntax, its easy to make mistakes and hard to figure out what your mistakes are. Futhermore, you don't get a gui until you go to Applescript studio. With REALbasic in minues you can instruct a complete novice to write a program that has a user interface and a button that does something. There are other good instructional languages, but applescript isn't one of them.
A second comment is that I've been working with REALbasic for about 2 years and haven't had any interaction with a database. Writing a general column about REALbasic when the author's experience is only with database development gives an extremely limited view of the breadth of the language. I realize that Mr. Ross qualifies the scope of the review early on, but the title and context give a different impression.
Another comment. Twice Mr. Ross says that a limitation of a feature "defeats the whole purpose" of the feature. In neither case is he correct. He says, for example, the fact that you can't subclass all classes "defeates the purpose of subclassing". Huh? Does that mean that the ones that can be subclassed are useless? Not in my experience.
One point he makes is a very good one; the blurred distinction between datatypes and classes. I stumbled here when learning the language. A much clearer distinction, at least in the documentation, would be very helpful. Mr. Ross only touched on some of the differences between the two that a programmer should be aware of.
Thanks very much for your comments. I hope that readers will be able to add your insight when deciding whether to purchase REALbasic.
However, I have to disagree with some of your comments. I think that most of the trouble with AppleScript has less to do with the language than to do with the implementation of scriptability given by application developers. If AppleScript is used only as a programming language rather than a scripting tool, as it may be in the context of AppleScript Studio, I think it's just as easy to learn as REALbasic, and for the beginning programmer, has the benefit of being free.
Also, saying that AppleScript doesn't include a GUI until one moves to Studio is, I think, ingenuous. You may as well say that BASIC doesn't include a GUI until you move to REALbasic. Given that a beginning programmer could start with AppleScript Studio as their introduction to AppleScript, the GUI is available right away. As far as an introductory programming language, I see no advantage to REALbasic over AppleScript Studio.
I never said that my only experience with programming is with databases. However, about 75% of my income is currently generated from database development of some sort. I do build other software as well, and even though I did qualify my review, everything I wrote applies regardless of one's anticipation of using the software for database development. The only two points I specifically made regarding my database experience were the inability to easily edit lengthy string constants and the lack of good documentation for this feature of REALbasic. A reader could mentally edit out these portions, and I think everything else will stand on its own. Regardless, I find it difficult to conceive of a large program that couldn't make use of an easy database interface of some sort.
I should not have used "defeats the whole purpose" so freely, however. You're correct that some ability to subclass is better than none, but the ability to subclass any "class" would be much better. I don't think I'm far off that a lack of allowing any datatype, including objects, to be stored in a constant is nearly a defeat of the purpose of constants. I would have immense use for constants that could store anything, much more so than for constants that can only be a number, string, boolean or color.
Finally, ATPM has a different style for reviews than many other publications. Our reviews aren't meant to be all inclusive, feature driven reports, but to give a personal account of the author's experience with the software. This is part of the reason I spend so much time at the beginning to describe my background and what I'm hoping to find by trying the software. Since your background might be so different from mine, having never used the database features of REALbasic, you might consider submitting your own review with your experience written into it. Overall, I'm positive about REALbasic, and have already begun to use it to create a commercial application (database driven, of course), rather than use FileMaker, for the reasons I discussed at the beginning of the article.
You're welcome. I agree, the REALbasic IDE is easier to use than Xcode and the language is easier than Objective-C, but it does come at a cost of power. Xcode with Interface Builder offer, I think, better interface feedback and control, and a wider range of widgets (barring using plugins with REALbasic). Not to disuade you from REALbasic, which I think is a good environment, you may want to check out AppleScript Studio (see my comments earlier today regarding AppleScript). If you're only building software for the Mac, it may be a viable option.
Thanks for your reviews and comments of Real Basic. My 6-month license period just expired two days ago! I was quite pleased that RB2006.1 was released just a few days before that. I started with 2005.1; RB has put out an impressive 5 releases in this period, and each seems to address some of the (many) annoying issues. I have the single-platform product
I am surprised that neither messrs Ross nor Kubie mentioned (or noticed?) another target audience that RB seems to court somewhat aggressively, that is, former (and perhaps, disenfranchised?) Visual Basic developers. I am not from those ranks,; my background is 20-odd years software development primarily on VAX/VMS platforms, with wide exposure but focused on VAX-BASIC and what was formerly Digital's RDMS database product.
Since retiring from that, I have been dabbling - rather extensively - with Applescript and Visual Basic, and now Real Basic. Applescript is, for me, quite disappointing; I echo and amplify Mr. Kubie's complaint that it is very picky about syntax, as well as frustratingly unhelpful (I admit I'm spoiled by the VMS online help & documentation, hands-down superior to everything else I've seen). I echo Mr. Ross' observation that Applescript is somewhat at the mercy of uneven implementation among the many applications that support it; of course, that broad reach is also its major advantage. Too bad it is so dog slow. VB runs slow circles around it.
Despite VB's critical shortcomings, it has some very nifty, unique features, for example the immediate mode interactive programming (I'd love to see this from RealBasic). However, I would sentence to a painful drawn-out torture anyone remotely responsible for the dire, dismal, dreadful documentation - no, it cannot rightfully be called that; VB doesn't have documentation. So woeful, so erroneous, so egregious; it bespeaks unbelievably callous disregard for the customer, and for a product costing hundreds of dollars, and years - decades - on the market. Completely unacceptable.
RealBasic would be hard-pressed to begin to reach that level of incompetence and thoughtlessness - unfortunately, they do seem to try. By far the weakest component of their ambitious, object-oriented, multi-platform undertaking. Just hiring high-school seniors to proofread it would improve.
I haven't had much luck with the "community links" they provide for alternative support (more like, commiseration?) but on Mr. Ross' advice I am joining the mailing list with renewed hope.
I'll end this awful rant with this simple reminder: with good documentation, a very bad programmer can produce surprisingly good results; without it, the most skilled programmer is severely undermined.
In general, it also seems more complete and up-to-date than the printed / pdf documentation (which I agree is mediocre at best).
When looking up an object in the language reference, first of all, that object should actually be correctly documented. I found numerous places where it wasn't. Second, the documentation should be complete. According to research I've done via the mailing list, this was not the case. Finally, it should be clear. Often it seemed that there was an entry on a method simply to make sure that the method had an entry, not to ensure that the entry was helpful in any way. For instance, a useful feature that I think should be required for every method is a sample of its use. Many methods include a one-sentence description of the method and a table of the parameters, with a sparse description of them.
Still, keeping all of this in mind, with the assistance of the helpful people on the mailing list, the developer can, eventually, figure out how to use the language, and I've begun building projects for clients using REALbasic, so I must like the software overall.
Add A Comment