Dr. Dobb's Journal May 2001
I wasn't a member of the Dr. Dobb's Journal staff 25 years ago when Dennis Allison and Bob Albrecht created the magazine — more or less by accident — while trying to get a version of the BASIC programming language into the hands of early microcomputer users. I arrived later. The concept of a staff arrived later, for that matter. If there had been a World Wide Web back then, Dennis and Bob could just have uploaded the code, submitted the URL to all the usual search engines, and skipped the staff — and DDJ wouldn't exist today, or at least it would be a very different sort of publication.
But wait, you say: Granted there wasn't a World Wide Web, surely there was Usenet, or at least there were computer Bulletin Board Systems. Dennis and Bob could have posted the code to a BBS for downloading.
Well, no. In 1976, there was no Usenet. Also no AOL or CompuServe, and Ward Christensen and Randy Seuss wouldn't invent BBSs for another two years. It's true that there was an Internet, but that fact didn't help Dennis and Bob.
The trouble was, for those early microcomputer users to download code from anywhere at all would have required a connection and an account — a serious barrier for most. And even more crucially, it would have required software — at least some kind of communications program and a modem driver — that just didn't exist for microcomputer systems in 1976. This was the do-it-yourself era of personal computing: If you wanted a microcomputer system, you bought the kit and put it together. If you wanted software, you wrote it.
And unless you were prepared to write it in hex (although many early microcomputer users were), that meant you needed some programming tools. Hence the urgency about getting a microcomputer-friendly version of BASIC into the hands of these early microcomputer users. Hence the expedience of publishing the code in so low-tech a medium as print.
Example 1 shows what Tiny BASIC code looked like (this is coded in the Denver implementation, published in Dr. Dobb's Journal, Volume 1, Number 3, March 1976). Commands like PRINT and INPUT were abbreviated in this implementation to save memory, not, as in the case of UNIX, to save typing effort. Line 20 shows the multiple variable input facility of this implementation. The semicolon at the end of the PR statement suppresses spacing. LET has become optional by this time, but not arbitrarily so in this implementation: Using LET sped up execution, while dropping it saved memory. Reminds me of a fantasy I entertained once, of a language that had two versions of every command: one space-saving, one time-saving. Line 60 illustrates another implementation quirk, the chaining of relational tests in one line: The two IFs must both be True for the assignment to happen.
But I mustn't let my connection with Dr. Dobb's color my reporting. There was already a BASIC for microcomputers. It was a little costly and you needed a paper tape reader to use it, but Altair BASIC, written by Bill Gates and Paul Allen, was real BASIC. I don't have a snippet of Altair BASIC code handy, but Example 2 is some BASIC code from an implementation that Bill worked on.
There may be just enough clues in that short listing for someone to guess that this program was written in the BASIC for the TRS-80 Model 100 Portable Computer, reputed to contain some of the last code ever written for Microsoft by Bill Gates. This example paints the 240×64 pixel screen, then locks into an infinite loop to keep the interpreter from messing up the picture with its OK prompt. Nifty stuff for Model 100 users in 1982.
From 1976, fast-forward 25 years to 2001. BASIC is still alive and well, but no longer tiny. (Some implementations are pretty small by modern standards, though: I notice that Chipmunk BASIC, which I mentioned here six years ago, is available for Windows 2000. It's small, but not as small as HotPaw BASIC for the PalmOS, which is a 164K download.)
Now BASIC didn't arrive on the scene in 1976, of course; it was already 12 years old when Dennis and Bob and Bill and Paul were putting it on microcomputers. Still, the BASICs of 1976 were clearly the same language that Kemeny and Kurtz invented back in 1964.
But is the BASIC of today that same BASIC? I pulled down a fairly recent book with BASIC on the spine from my shelves, and Example 3 shows some of what I found in it (slightly modified to make a point, but still syntactically correct). That sure looks like BASIC. Straight procedural code, line numbers, LET for assignments, the READ and DATA statements for initializing variables, very BASIC-like I/O, and although we don't see one here, GOTO statements. (That's what the line numbers are: GOTO targets.) I said fairly recent. The book is six years old. It's BASIC for the Newton by John Schettino and Liz O'Hara (AP Professional, 1995). But with more research, I suspect that I could find an even more recent book with real BASIC code in it.
But it sure wouldn't be the REALbasic manual.
I've been working with REALbasic from REAL Software (http://www.realbasic.com/) for several months now, first with version 2 and more recently with the just-released version 3. This language fills a very real need, although it may be a need that only a few Dr. Dobb's readers feel. It's a useful tool, but — is it BASIC?
Given that it is sometimes viewed as the Visual BASIC equivalent for the Mac, you wouldn't expect REALbasic to look like the code samples in Examples 1, 2, and 3. This is a modern programming language, which means that it is object-oriented, something that stretches the old BASIC model, with its line numbers and GOTOs, beyond recognition. Example 4 shows what REALbasic code looks like. No line numbers, methods belonging to objects: not your father's BASIC. But I guess if Visual BASIC is BASIC, then this is BASIC, too. I don't suppose it matters much what you call a language.
What does matter, though, is that REALbasic is a serious developer's tool, particularly appropriate for prototyping, designing, and testing interfaces. Microsoft uses it in its Macintosh Business Unit (MBU) for just those purposes. Michael Connolly, Group Program Manager for the MBU, recommends it highly and credits it with MBU's ability to develop new features for Office and Internet Explorer for the Mac very quickly. This is a pretty impressive recommendation given that the MBU often gets features into the Mac versions of Microsoft products before comparable features make it into Windows versions.
I've examined a lot of applications written with REALbasic, and am impressed by the quality and power of software created with this tool. One such application is iCamMaster (http://www.icammaster.com/), which lets the webcam fanatic collect and view webcams, view multiple cams simultaneously, record webcams as QuickTime Movies, place webcams as desktop pictures, and send messages to webcam owners. Another is TBfinder (http://homepage.mac.com/fabianl/development/), an open-source app that creates REALbasic declarations of Mac OS API toolbox calls by searching the Universal Headers folder for the call you ask for, and translating it into RB syntax.
With the release of Version 3.0 in February, REALbasic now runs on and compiles for Mac OS X. It's a Mac-only development platform, but compiles to Mac or Windows; specifically, you can develop software with a single set of user interface elements and code to compile native applications for Macintosh, Mac OS X, and Windows without any platform-specific adjustments.
Version 3 is a major advance, with "an all new animation engine, revamped database features, enhancements to the Code editor and debugger, crash recovery, searchable online reference, AppleScriptable compilation process, [and] vastly improved Windows support." REALbasic costs $149.95 for the Standard Edition and $349.95 for the Professional Edition. Besides English, it's available in several languages, and REAL Software also offers academic and volume discounts and license-only options. REALbasic has a plug-in architecture and there's a plug-in SDK for those who want to develop plug-ins. The database capabilities of the Professional Edition require certain database plug-ins and allow access to OpenBase, CSV, PostgreSQL, DBF, OracleOCI 7.1, ODBC, dtfSQL, and 4D server databases.
The connection with Visual Basic is explicit: There's a VB Cleaner application that semiautomates the conversion of code from VB to RB and there's a web site dedicated to helping people do the conversion. It's not particularly hard.
For me, REALbasic makes a lot of sense, and I've begun to put it to practical use. The use has nothing to do with its cross-platform capability or with converting Visual Basic code, however.
Although I have Linux and Windows running on machines here at Stately Swaine Manor, I do all my real work on a Macintosh, and have since 1984. Some of the definitely-not-commercial software that I've developed to make my life easier has roots that go back to that first Mac in 1984. None of the code is that old, but one or two of the tools still address needs I had back then in ways that made sense to me back then. Starting in 1987, I began coding in HyperTalk, the scripting language in HyperCard, and for the things I wanted to do — personal information management, simple text processing, testing algorithms, or just noodling around — that was sufficient. Although I once made a living as a programmer, these days I'm a writer, and the coding that I do is squeezed into odd moments or stolen Saturday mornings. A simple scripting tool makes a lot more sense for my needs than C++ or Java. But it seems unwise to be dependent on HyperCard any longer. Apple hasn't updated it in years, the company isn't allocating any resources to it, and there are no visible indications that it will ever be updated to MacOS X. So for at least the past year, I have been looking for a new platform for my Saturday-morning programming.
REALbasic may be that platform. I've begun recoding those old HyperCard stacks in REALbasic. I tell myself I'm evaluating the product, but it begins to look like I've already made my decision. It's not a decision that all HyperCard users can make, though. I characterize my skills as those of a Saturday morning programmer, but there are a lot of HyperCard users who aren't programmers in any real sense, and for whom REALbasic is way too much of a programming language. These people have had the luxury of being able to develop software — including some highly useful courseware and beautiful CD-ROM multimedia products — without knowing much about programming.
For this more typical HyperCard user, there needs to be a gentle replacement: Something that doesn't break their stacks and doesn't require them to learn a radically new development environment or language. I've just been evaluating one candidate: Revolution.
I've been working with Version 1.0 Beta 3 of Revolution from Runtime Revolution Ltd., formerly Cross Worlds Computing (http://www.runrev.com/). Revolution is a very high-level cross-platform development environment built on top of Scott Raney's MetaCard, which is itself a high-level cross-platform development environment modeled after Bill Atkinson's HyperCard.
As with MetaCard and HyperCard, the central metaphor is a stack of cards. HyperCard users can directly open their existing stacks in Revolution's development environment, add features to them that HyperCard doesn't support, and save them as Runtime stacks, which require a (free) Runtime engine.
Revolution is available (like MetaCard) on a variety of platforms of the Macish, Winnish, and UNIX/Linuxish persuasion. Any version can be used to build stacks for any of the other platforms, with appropriate Mac/Win/Motif UI; and there is an option to let you preview the stack as it will appear with the target UI.
HyperCard's supply of widgets is extremely skimpy (buttons and fields, basically) and it lacks the drag-and-drop-from-palette interface that's become standard for this kind of rapid development tool. Menus can only be created by writing scripts, for example. Revolution has the expected palette of widgets and also has native color, something that HyperCard still lacks. The scripting language, Transcript, looks a lot like HyperTalk, but has features HyperTalk doesn't. For example, unlike HyperTalk, Transcript supports associative arrays, letting you access array entries by string or number, as in Example 5.
Because Transcript is not HyperTalk and because of other differences between Revolution and HyperCard, you'll probably see a lot of error messages when you try to open under Revolution a stack created with HyperCard. This is going to cause the company headaches because many of its beta testers are likely to be HyperCard users who are: 1. viewing this as a HyperCard replacement, 2. less tolerant of error messages than professional programmers, and 3. lacking the skills to deal with these error messages.
On top of that, the application looks pretty rough to me. A little more alpha might have been appropriate before going beta to an audience for whom Revolution in its present form may not meet expectations. That said, I think the developers have something good here, and if they can get the bugs out, it'll be a real boon to HyperCard users abandoned by Apple.
The following items, courtesy of my ever-vigilant readers, fall under the heading of addenda and errata. More addenda than errata, I'm relieved to say.
Robert Wisdom answers a question from a previous column, pointing out that, according to http://www.oakland.edu/~grossman/Erdos1, Stephen Wolfram's Erdos number is 2. The main page for the Eros number data seems to be http://www.oakland.edu/~grossman/erdoshp.html.
The folks at Wolfram Research wrote, too, to tell me of a new product from Wolfram. CalculationCenter is Wolfram's new midmarket technical calculation software product. Apparently "midmarket" means, no doubt among other things, a significantly different pricing structure. Readers who wrote in after my column on Wolfram's flagship product, Mathematica, to grumble at the price of Mathematica, should be pleased to learn that CalculationCenter will sell for $295 (at least initially) for Windows 95/98/Me/NT/2000 and Mac OS platforms.
The product presumably does some subset of what Mathematica does. It uses the same notebook format, and the target audience is engineers, scientists, and business analysts who are also described as "less technically demanding or more occasional user[s]" than the typical Mathematica users. These two characterizations may or may not be consistent. Maybe CalculationCenter's users are Saturday morning mathematicians. I have a review copy on order and will probably have more to say about it in a subsequent column.
Finally, Richard Couchman writes to ask if the line, "The idea of using the Greek letter pi for the ratio of the circumference of a circle to its radius..." was "a legitimate flub or one of those tidbits thrown in to see if the reader's paying attention?" Flub, I fear, and a really dumb one, too. I meant diameter, of course.
Hope you got something of value from this excursion into Saturday morning programming tools. And now, back to our regularly scheduled hard-core professional-level weekday programming.
DDJ