Hide full article
A computer is to program. Otherwise, it just sits there, like a big empty box. Of course, we mostly use programs written by others. But sometimes you want to have that box do precisely what you tell it - because there's no program that does just what you want, to save money, or because it's just plain fun. That's why I wouldn't buy my first Mac until its characteristic interface bells and whistles came easily under my control through a software construction kit - HyperCard (see "HyperCard 2.2: The Great Becomes Greater" in TidBITS-213).
<http://db.tidbits.com/article/04075>
HyperCard is unparalleled for constructing a bare bones interface rapidly. But it's showing its age and limitations. It's superb for textual storage and hyper-linkage, but less good at search and retrieval. Further, certain graphical or interface functionalities - such as color, drag & drop, or real scrollbars - are clumsy to implement, require third-party extensions, or are downright impossible. Large projects can be a pain to create and maintain. Most important, a stack runs inside HyperCard itself, so disk and RAM footprints are big, and speeds are sometimes poor: you're not writing a true compiled standalone application.
Even while editing a Mac programming magazine and dabbling with cool tools (such as Prograph - see "Get Your Hands on Prograph" in TidBITS-312), I found no magic bullet, no environment where an amateur - reasonably intelligent but with no will to manage the Toolbox or pore over Inside Macintosh - could implement a true Macintosh application with HyperCard-like convenience. Like Virginia doubting Santa Claus, I wondered if such a thing would ever exist.
<http://db.tidbits.com/article/01160>
The REAL World -- In 1997, a shareware product called CrossBasic began quietly making waves. It had a single author, Andrew Barry, who had been developing it in his spare time for some years (while writing such programs as the Prince of Destruction game and the debugging tool Spotlight). In October 1997, CrossBasic was picked up by FYI Software, Inc.; when the name proved to be already trademarked, two rechristenings took place - REALbasic and REAL Software.
<http://www.realbasic.com/>
<http://www.wr.com.au/mars/mars/pod_home_ page.html>
<http://www.onyx-tech.com/spotlight.html>
Installing REALbasic is a pleasant shock: it occupies a mere 3.1 MB of your hard disk. Starting it up, you see a typical interface construction kit: a blank window and a palette of control types (text field, push button, radio button, checkbox, and so on) you can drag into it. You can also make other windows. When a control in a window is selected, a windoid lets you change its inherent properties (such as position or color). You add menus and menu items in an equally intuitive graphical way.
Already at this point you can "build" your application as a stand-alone; more likely, though, you'd test it from within the REALbasic development environment. (This environment is partially dynamic: you're generally, either running the application or editing it, but you can edit a running application somewhat.) You'll see your window, which you can drag, resize, and close in the normal way; your menus will appear at the top of the screen. If there's a text-field in the window, you can edit text there, and there are Copy, Cut, and Paste menu items that work - so does Quit. But generally your menu items and window controls have no powers because you haven't yet written any code for them.
That's done in the Code Browser, which appears when you double-click on your window. Down its left side the Code Browser lists your menu items, and your window's controls along with the system-level events they will automatically receive. Selecting a listing lets you edit its code in the Browser's main pane. You write the code in a BASIC-type language that's easy to learn.
The REAL Object -- For demonstration purposes, I've posted three simple applications I wrote while learning REALbasic:
- TinyText, a minimal text editor based on the REALbasic Tutorial
- Whack, a game where you must click each rising "mole" before it vanishes
- Odummo, an Othello game without "intelligence" - the computer plays correctly, but randomly (hence the name)
<http://www.jetlink.net/~mattn/downloads/ TinyText.hqx>
<http://www.jetlink.net/~mattn/downloads/ whack.hqx>
<http://www.jetlink.net/~mattn/downloads/ Odummo.hqx>
These applications are remarkably small (except Odummo because it's a fat binary), remarkably speedy, and remarkably persuasive: TinyText edits styled text files larger than 32K; Whack animates smoothly; Odummo plays a non-trivial game and is surprisingly addictive.
But the real point is that these programs were astonishingly easy to write. TinyText took a week or so because I was reading the documentation. Whack took several days while I learned how graphics work, but ultimately required only 80 lines of code. Odummo took less than 24 hours, including eating, sleeping, and other normal activities.
That's because of REALbasic's class-based object model. Everything - a window, a button, a graphic - is an object representing some class. Any object can send a message to any other. In a class or an object, you define responses to messages, as well as internal variables maintained by each object. You can also subclass a class to specialize its behavior. Thus, object-oriented principles of messaging and encapsulation help you organize your code - and your thinking.
Whack requires little code because nearly all the code is in classes. The window contains eight moles constantly rising and vanishing; but they all instantiate just one mole class, and are activated by instantiations of just one thread class. Similarly, hits, misses, and elapsed time are maintained by three counting fields; since they behave identically, I had to create only one counting field class.
Odummo was even easier, though I feared it would be much harder. The board has 64 squares; must I maintain a complicated two-dimensional array describing it? No! Each square is an object of just one class, and the window itself is my array, so it is sufficient to teach one square what to do. A square knows whether it contains a piece, what color it is, and how to draw it, and the whole game is just a matter of a square responding when the user clicks it and sending appropriate messages to other squares.
I kept a diary of the Odummo development process, in case you're curious about the arduous life of the programmer:
- 6:00 PM. Draw the window.
- 7:00 PM. Make dinner.
- 8:00 PM. Teach a square to draw a piece inside itself.
- 9:00 PM. Teach a square to find its neighbor in any given direction.
- 10:00 PM. Go to bed.
- 6:30 AM. Teach a square to ascertain whether a given direction leads, through pieces of the opposite color, to a piece of the same color. It turns out that the square can do this just by asking its neighbor two questions.
- 7:30 AM. Teach a square to know whether it is legal for a given color to play there.
- 8:30 AM. Go for a run.
- 9:30 AM. Shower, dress.
- 10:00 AM. Drive to laundromat, do wash. Go home, hang clothes on line.
- 11:00 AM. Teach a square to reverse its color and to tell its neighbors to do the same.
- 11:30 AM. Teach a square, when clicked, to play white there if legal (and beep otherwise).
- 12:00 PM. Teach a square to know what color moved previously, so that it can play the other color when clicked. I can now play a game against myself.
- 12:30 PM. Lunch.
- 1:00 PM. Teach a square to play white when clicked, then to ask all other squares whether black can play there, and then to tell one randomly chosen square which said Yes to play black. The computer is now playing against me! Run around house screaming and waving arms wildly!!!
- 2:00 PM. Add logic knowing when game is over, totalling score, and what to do when a player can't move.
- 3:00 PM. Done! Nap.
REAL Ability -- Listing REALbasic's various capacities would be a Herculean task. Windows can be of all the normal types, including floating windows and windows that stay above any application. A window can contain push buttons, checkboxes, and radio buttons; editable fields with styled text (as in TinyText); canvases, which are clickable graphic regions (the Whack moles are canvases); sliders and scrollbars; list boxes; pop-up menus; and tabbed panels.
With REALbasic, you can read and write file data and resources, access the clipboard, and accept drag & drop. You can run QuickTime movies, play MIDI notes, display contextual menus, show help balloons, grow a progress bar, animate "sprites," and spawn threads. You can operate over the serial port, communicate via TCP/IP, and send and receive Apple events.
REALbasic's functionality is further extensible through pre-compiled code in various formats: compiled AppleScripts; XCMDs and XFCNs; shared libraries; and C++ plug-ins, for which a developer kit is supplied (these can also define new window control types).
The range of REALbasic-generated applications by various users - at REAL Software's FTP site, at their Hotline site (cafe.realbasic.com), on the program CD, and at users' own sites - bears astonishing witness to the program's powers. There's a batch file-typer, a Tetris-like game, a magnetic core calculator, a sunrise calculator, a spelling quiz, an address book, a random "art" generator, a chat server - even an email client.
My favorite REALbasic success story is from the July Macworld Expo. The REALbasic team had rented a badge "swiper" so their computer could store names and addresses of visitors to their booth, but the supplied software didn't work. However, the swiper was a serial device, so they quickly wrote their own software using REALbasic - and then modified it so they could read credit cards as well!
Getting REAL -- It is hard to praise REALbasic sufficiently. It is reasonably priced. It is small, quick, easy to learn, and easy to use. The language and the development environment clearly result from deep, thoughtful insight into the needs and mental processes of users, encouraging rapid, improvisational development of well-behaved applications with pleasing interfaces.
The documentation consists of Acrobat PDF files: a tutorial, a 14-chapter Developer's Guide, and a language reference duplicated as online help. The documentation is good but not great; at this writing, there are major errors in the tutorial, documented features don't exist and existing features aren't documented, and nearly every sentence contains some careless fault of grammar, omission, or spelling.
Many aspects of the program have an undeniably inchoate quality: windows aren't listed in the Windows menu, and their positions and states aren't remembered; the debugger is primitive; the code browser handles long lines badly. There are problems in built applications as well: printing support is crude; certain system-level events aren't triggered properly; applications sometimes work differently when built than when run inside REALbasic. The REALbasic mailing list, needless to say, keeps busy.
Still, that mailing list has also forged a community of avid users, and has contributed to REALbasic's maturity. Andrew Barry and the team have a constant presence and have shown themselves to be well-organized, principled but open-minded, responsive, gracious, conscious of the program's shortcomings, and attentive to users' needs and suggestions. Furthermore, they're quick to fix bugs, implement new features, and issue new updates and developer releases. The program is basically sound, and full of wonderfully thoughtful and ingenious touches; on balance, this seems an appropriate moment for commercial release. If REAL Software can maintain their present pace and attitude, without becoming overly entangled in new paths before resolving outstanding problems, early adopters will find themselves well served.
A 30-day free demo is available as a 2.2 MB download. REALbasic sells for $100 ($60 academic). An update that will compile Java applets is expected around January 1999, and eventually an "enhanced" version that can compile Windows programs will be available for around $300, and will include database and SQL capabilities.
