Cocoa v. REALbasic
Posted January 21st, 2003 @ 01:24am by Erik J. Barzeski
Matt's got an interesting article up at his blog about the difference between Cocoa and REALbasic. I've written articles about this in the past (one was taken down when I restructured Cocoa Dev Central, some others might be found at MacOpinion). Matt asks the simple questions: Which is easier to learn, which is better, and are RB apps more buggy? My answers? RB, Cocoa, and Yes. But let me explain…
First, which is easier to learn? REALbasic. I'll give it the edge here for the reason Matt lists: it's more intuitive to 'get up and go' by double-clicking on some UI element and writing code. Code auto-completion is there from the get-go. The built-in help has a moderately useful search feature. Granted, it took me about twenty minutes to figure out how to add a freaking menu item once, but overall, the stuff in RB is fairly intuitive. I found using the "debugger" straightforward, for example, and RB apps can "compile on the go" encouraging developers to test their applications early and often. RB is easier to learn. (It bears noting that "easier to learn" is not the same as "easier to use.")
Which is better? Cocoa, hands down. It's free - Apple doesn't milk you for $200 or whatever every six months with upgrades that don't provide much - RB is subscription software. Cocoa is based on industry standard toolchains like GCC and GDB, and plays nice (either out of the box or via extensions) with industry standard languages like Objective-C, C++, Java, Perl, Python, etc. It integrates more easily with the BSD underpinnings on Mac OS X. It has a wide variety of classes, a rich, stable framework, and knowledgeable Apple and NeXT developers supporting and enhancing it (though RB's community may be larger, RB's may not be "as professional" - a weak point I might do better to omit entirely). Cocoa "is" more the Mac, whereas RB is merely a shim on top of Carbon. Anyone remember the "really colorful text" bug RB apps had on Mac OS X?
Are RB apps more buggy? You bet your ass they are. But here's the reason: it has little or nothing to do with RB itself. Instead, it's related to the answer to question one: RB is easier to "pick up and go." Thus, the developers that are drawn to RB may not be as skilled as the developers attracted to Carbon or Cocoa or Java or C++ or WebObjects or whatever. Instead, these "hobbyist" developers, who often have no clue how best to optimize memory use or avoid badly written loops or what have you, churn out code that "looks ok" more frequently than is done in Cocoa simply because the barrier to getting an app up and running in Cocoa is a little higher.
I've got exactly one piece of RB software out there (no, I'm not telling you where it is). My software company does all of its work in Cocoa (and Carbon). I run a Cocoa development site. But I've run a whole lot of RB apps over the years, and I can't tell you how many times I've seen the phrase "a nilObject exception has occurred." It's infuriating and I delete the app immediately after seeing that little message.
Scanning /Applications and /Applications/Utilities I have approximately 150 apps, and two of those are RB apps: Package Tracker (which I actually use on the rare occasion that I need to track a package) and NavBar Builder (which I keep around because sometimes the graphics included with it give me an idea).
We've seen some fairly large-scale Cocoa applications come onto the scene, largely from Apple or Omni Group (OmniGraffle, Omn, iPhoto, Project Builder, iDVD, Keynote, DayLite from Marketcircle, etc.). All we've seen from RB is a utility to track a package or something. This is what you get when small-time "newbie" developers take on a project, and what they can accomplish in a limiting environment. RB is, for all intents and (practical) purposes: a great RAD app for newbie developers wishing to make a small utility. Heck, Stone studio, etc. can easily be added to this list.
And so it goes…
Donate Life
Posted 21 Jan 2003 at 9:13pm #
Amen, brother :-). To your list of reasons why RB sucks, I would like to add the fact that the interfaces are almost always terrible. One of the great things about using Cocoa is that you get a "proper" OS X look and feel. Of course, this doesn't stop a good many Cocoa developers from creating hideous looking apps, but at least it makes it harder.
I try not to act too superior, but I've got to admit that sometimes the flood of crap on VersionTracker depresses me as a developer. Unfortunately, the ease of use of RB (and even Cocoa, to some extent) seem to encourage a lot of hacky developers to spend a weekend, release a half-baked log viewing tool (or something to that effect) and charge $10 for what should really have been freeware at most.
I'm increasingly coming to the conclusion that weblogs are the antidote (at least for me)--peer recommendation goes a long way toward helping separate the signal from the noise when it comes to deserving OS X apps.
Posted 21 Jan 2003 at 9:48pm #
Oh, no. I feel a letter from Geoff Perlman coming.
Posted 24 Feb 2003 at 9:06am #
Some people think subscription software is the future. That - eventually - we'll all be paying for our software by the hour, month, year, whatever. Guess what? For some, it's already here: REALbasic 5.0 is out. REALbasic seems to have seen yearly upgra...
Posted 31 Oct 2003 at 12:53am #
In response to the comment from Brad, "Sorry it took me so long."
Let me address some of the issues from the article above. REALbasic makes it easy for people to both learn to program and to easily create applications for Mac, Windows and soon, Linux. And naturally, the easier it gets to create software, the more people will be doing it and you're going to have some lesser quality stuff just as a result of the number of people writing software.
I'm sure the people that programmed in assembler looked down their nose at the first users of C or C++ saying that those are not REAL programming languages. And that's what I see here.
REALbasic uses a language that is very close to Visual Basic which has 6 million users. And I agree that the REALbasic community is probably far larger than the Cocoa community so it could easily be argued that REALbasic is a more "industry standard". Objective-C is certainly not an industry standard language. Outside of the Mac OS X community few have heard of it.
There are also a growing list of sophisticated applications written in REALbasic. Here's just a few. I've included URLs for those of you that want to check them out:
Microsoft Query for Mac OS X
Caststream
Whistle Blower
Auto-Illustrator
SpamFire
MediaEdit Pro
RealCADD
TouchCAD
These are just a few examples. There are many, many more.
The bottom line is this: You can create software with REALbasic that is as native on Mac OS X as anything you create with Cocoa. And while there may be a minor thing here and there that isn't supported, the same holds true for a Cocoa app. Try command-clicking on a URL in a Cocoa app. Nothing happens (haven't tried this in Panther so I don't know if Apple has addressed it or not) whereas this works as expected in Cocoa apps. Cocoa and Carbon on peers on Mac OS X. Apple did the right thing by porting only as much of the Classic APIs as they needed and by only adding to Cocoa only as much of the Classic functionality as needed to get Mac OS X going. Over the last several releases Cocoa and Carbon have become nearly identical.
Yes, we charge for REALbasic but then Apple charges (indirectly) for their tools as well. You have to purchase a Macintosh in order to run their tools. Remember, Apple is a hardware company. The software is essentially a loss leader. You pay for both one way or the other.
The author of the article above says that anytime he sees an application display a nilobjectexception, he gets mad and deletes the application. Well, at least REALbasic apps have the ability to exit somewhat gracefully. Cocoa apps simply crash or unexpectedly quit. I'm not trying to bash Cocoa here. Applications crash that's a fact of life. Why doesn't the author drag iPhoto to the trash when it crashes on him?
You can write quality software in Cocoa and in REALbasic. The fact that REALbasic is accessible to a far larger audience shouldn't be discourged or insulted. It just means that more people can create software than before. Like with any development tool, there will be some flowers and some weeds.
Posted 31 Oct 2003 at 1:06am #
Geoff, I edited your post to actually use HTML. Y'know, those <a> tags are a great help.
Geoff, your list can easily be countered by a much, much longer list of crappy, crappy software done in your IDE. I doubt the same is true of Cocoa.
Your counter-arguments about VB having 6 million users is quite irrelevant: what's popular is not always best, and what's best is not always popular. You can't play the numbers game with Mac users!
Posted 31 Oct 2003 at 1:21am #
I almost wish REALBasic's name described it as well as AppleScript Studio's acronym does. hmph.
Posted 05 Nov 2003 at 11:16am #
Made with RealBasic!
Audiobook Studio Okay, I’m going to have to agree with Erik about something here. Anything made in RealBasic, well, sucks. Further, it lets people get off the ground that probably shouldn’t. What does AM3 have that TR does not? Little...
Posted 07 Nov 2003 at 4:30am #
We use Realbasic to produce Complex Database querying tool for a niche of users. We couldn't effort the developement of such apps and deploying in windows and Macintosh with cocoa.
Also with Rb you can build rude internal tools to do complex tasks saving time and money.
So, I agree whit you, cocoa is a far more advanced tool and cocoa programmers are far more skilled than RB ones, But the existance of RB multiply the choice for users, and that's a real value you can't just skip or ignore.
I'd only like to add that you can find a lot of "pieces of crap" made with cocoa, or perl, or codewarrior or anything from the bad interface to not user-friendly behaviour to incompatibilities and to total useless applications.
It's not the tool that make the software, it's the designer of the software (yes, not the programmer, the designer).
Thank you anyway for the space for comments and discussions.