Dr. Dobb's Journal June 2001
In a slightly more perfect world, at the very end of every software installation process, a dialog box would pop up asking, "Would you like to erase all memory of the past three hours?" Click Yes and you'd be left with a three-hour fugue and a slight pain between your eyebrows, but no recollection of the agony of installation. I'd consider that a fair trade. Since there is no such button, I have a very clear recollection, supplemented by copious notes, of my not-lost weekend installing and testing the official release version of Apple's most ambitious operating-system upgrade since 1984. Not only that, I even remember installing and familiarizing myself with Wolfram Research's latest offering, CalculationCenter, the week before. Like MacOS X, CalculationCenter is the biggest software news for its company in something like a decade. Unlike MacOS X, it runs on Windows. What follows here are my impressions of these two programs.
Random thoughts during a software installation...
Apple released MacOS X on March 24. To add "right on schedule" would be technically correct, since March 24 was the latest of several scheduled release dates, but this would ignore the past 10 years of failed attempts to replace the original MacOS with something more robust, and the past three years of direction changes spiraling toward release. During the Jobs reign, a two-OS strategy morphed into a one-OS strategy, something called "Rhapsody" came and went, and a very public beta program invited Mac users to veto many NeXT-inspired features of OS X as Apple crafted the final, user-vetted release...which was still missing a few critical pieces at launch date, such as CD recording, DVD playback, and iDVD support.
At least we know the answer to the all-important version number question. The copy I have in hand (the last copy in my local Staples store, purchased 15 minutes after the store opened) is named MacOS X 10.0 (Build 4K78). Logically, it ought to be MacOS X 1.0 (if X is part of the name), or MacOS 10.0, or MacOS X.0 (if X means Version 10), or even more logically MacOS X.i (because Roman numerals don't have a zero). But logic has nothing to do with Thinking Different.
I confess that my whining about the agony of installation was not warranted by my MacOS X installation experience. I more or less followed the instructions and it went without a hitch. It took forever, of course, but when it was done, I began using OS X immediately and never had occasion to go back and change any settings or preferences.
So on to the experience. I did spend a fair amount of time tweaking the user interface. Aqua's throbbing buttons and whooshing windows and active icons and general lickability could easily get to be a bit much, but the most intrusive features can be turned off. And some of them are useful indeed. I'm already hooked on the Mail app's active icon, which, sitting in the Dock at the bottom of the screen, displays a live update of the number of items in my e-mail inbox.
Not all the UI t's and i's got crossed and dotted by March 24, though. The transparency slider in the clock app, for example, is either mislabeled or misoriented: For more transparency you have to slide it to the left. I'd say it's really an opacity slider.
My main initial concern with OS X was with the Classic environment — where apps run that are not yet Carbonized to run natively under OS X. Backward compatibility is what Classic is all about, and backward compatibility is not a Steve Jobs strength. But for it to make any sense for any user less crazy than I to upgrade before third-party apps arrive, Classic has to run just about all our existing apps just about as smoothly as the naked OS 9 we were already using.
Short answer: It does. Double-click on a familiar old Macintosh application and this OS X application named Classic launches, if it isn't already running, and it then opens and runs the familiar old app.
After the first launch, Classic is pretty much invisible. Classic apps sit beside OS X apps in the OS X dock, looking just like OS X apps but with clunkier icons. OS X apps are listed along with OS 9 apps in the OS 9 app menu, with no clue that they are anything special. You can click back and forth between Classic and OS X apps at will. Functionally, Classic creates a smooth integration between what actually are two different operating systems.
Visually, it's a different story. The Classic apps impose their own Classic user interface and window styling and menubar clock and so forth, creating a certain degree of interface dissonance. It's particularly noticeable where the OS X and Classic interfaces overlap: When the Dock pops up in front of a Classic app, it knocks out the background in chunky white rectangles. And there are other anomalies: Microsoft Word sometimes seems to place characters in strange places, like halfway between two lines of text, but these turn out to be just surface blemishes — shrinking and enlarging the window clears them up. That wasn't happening under plain OS 9. And my Recent Applications menu item got confused and refused to show me anything, which wreaked havoc with my workspace organization strategy — which is: Do nothing; if it's important, I've probably used it recently and the operating system has put it in Recent Applications or Recent Documents. Of course, those Classic apps may crash. Installing OS X involves upgrading, if necessary, to OS 9.1 to implement the Classic environment where old apps run. MacOS 9.1 is different enough from previous versions that it could break some older, shall we say casually written, apps. If that happens, the user's experience will be that OS X broke his or her app, when, in fact, it was OS 9.1 that revealed the app's brittleness.
Did my apps crash? In a weekend of heavy use and deliberate stressing of Classic, the only app that crashed for me was Mail, the OS X e-mail program. In two days, I would have expected Netscape Communicator to crash once under the old OS, and the fact that it didn't under OS X/Classic is not evidence that OS X somehow made it more reliable. I'm sure it was just dumb luck.
I mentioned stressing Classic. I haven't managed to replace the rat's nest of HyperCard stacks and other apps, some of them pretty old, that I use for collecting news items and updating my web site. So these tasks provided a nice test of Classic robustness.
I had Classic HyperCard stacks sending Classic AppleScript commands to a Classic web browser at same time that I had the OS X Mail program downloading mail (every five minutes) and Classic Communicator downloading the same e-mail (because I didn't think to turn off its automatic e-mail checking). All the Classic parts worked exactly as before I installed OS X. In addition to running OS X apps alongside Classic apps, I did things like changing UI settings and monitoring processes in OS X while my Classic browser was downloading. No problems. The communication between HyperCard and Communicator via AppleScript was a good rough test of performance, since I've never changed the default timeout for AppleScript and any significant delay in sending the message will typically get me an error message. I don't get them often. Under OS X, I didn't get any.
I played around with AppleScript further, just trying out some scripts I had on hand, and they all worked without a hitch. That was all in Classic mode, though, so I ran some Apple-supplied scripts under plain OS X, too. No problem there, of course. I know, because Apple is quite clear about this, that I could have found AppleScript functionality that wasn't implemented yet in OS X. Apple says AppleScript support in OS X is "evolutionary." But I'm impressed that it's there at all.
When you're completely replacing the core of your operating system, it seems to me that the easiest call would be to dump your system-level scripting language. Particularly given that the new core is UNIX, and there are existing UNIX tools that could probably be adapted to the purpose. Okay, I realize that the place in OS X where UNIX lives and the place where AppleScript lives are not the same, but as Apple's user base adapts to OS X, isn't it likely that it will split into those who don't do any scripting and those who are comfortable with Perl? And doesn't that make AppleScript the scripting system for people who don't want one?
Still, it was clear at least as far back as May 1998 that Apple was committed to implementing AppleScript in OS X. And at this point, given that I have an investment in AppleScript code, I'm glad they did it. I guess I'm the refutation of my own argument.
MacOS X will of course be a success in the sense that it will be adopted by the Macintosh user base. Apple can and will mandate that adoption by installing OS X on future Macs and phasing out support for OS 9. But just how successful MacOS X will be depends on the efforts of people outside Apple: third-party developers who will first Carbonize their existing apps to run native under OS X, and then develop new apps, even new categories of apps, taking advantage of the Cocoa APIs. The next few months are critical for the first of these, the Carbonization of third-party Mac software products.
With that in mind, Apple included a third CD in the package, in addition to the OS X and OS 9.1 disks. This one is called "Developer Tools" and it includes the apps and tools and examples and frippery that you need to develop apps for MacOS 9 or X. I didn't develop any Mac applications over the weekend, but I did play around with Interface Builder and some of the other tools. Apple is hoping that a lot of you will do more than play around with them, and it is safe to say that encouraging developers to build OS X apps will be Apple's obsession at this spring's Developer's Conference. And just for the record, I note that Apple explicitly uses the term "Open Source" in its OS X license, in a paragraph that imposes restrictions that I really don't think are in the spirit of Open Source software. Tsk, tsk. Bottom line: I'm using OS X full-time now and am happy with it. But as they say here in rural Oregon, it's a tad spendy.
In a recent column, I wrote about Wolfram Research and its genius founder Steven Wolfram and its flagship product Mathematica. It wasn't the first time that I've written about Mathematica, and also not the first time that I got interesting feedback from mathematically inclined readers. I also got questions with a common theme.
Why lavish so much attention on a product that is priced out of the range of most DDJ readers? Even if Mathematica is the best mathematical software in the world, unless your job really demands it, who's going to approve the expense? And who would spend that much of their own money? For that matter, why invest so much effort learning a complex product when all you want to do is some basic curve-fitting or graph-plotting that you could probably get done more quickly and cheaply with another product? And on and on.
Actually, I'm extrapolating from a couple of questions, but the issues of price and complexity have been raised, and they're good questions. Even Wolfram Research realizes that they are good questions.
At least that's how I read the news of the release of CalculationCenter, Wolfram's midmarket mathematical product, priced at a mainstream $295, designed to be significantly easier to use and to get started with than Mathematica. Conrad Wolfram, one of CalculationCenter's developers, says that getting new users calculating in 10 minutes was one of the design goals for the tool. (Specifically, users on the supported MacOS and Windows 95/98/Me/NT/2000 platforms.)
I'm convinced that they're on the right track. There are surely many users like me who are not mathematicians but who do have an occasional need to do some nontrivial math that a spreadsheet just can't handle, or who want to get a really quick visualization of some data without having to tweak parameters to produce something useful. Whenever I've used Mathematica, I've been impressed with its power and depth, but I've also been frustrated by having to relearn the product every (infrequent) time that I use it. The starting ramp on the Mathematica learning curve is relatively steep, and if you don't use it all the time, you keep having to climb that ramp. So, as much as I appreciate Mathematica, if I had to pay for it with my own money — well, I wouldn't. CalculationCenter promises to remove both these barriers — price and the getting-started problem. Does it deliver on the promise?
If it doesn't, it certainly comes close.
Take the InstantCalculator feature. This is a step beyond templates and wizards as a tool for guiding users through a complicated procedure. They are templates, one for every function that CalculationCenter can perform. But unlike wizards, these templates paste into the user's document and remain active and available for further calculations. You can plug the output of one InstantCalculator into the slots in the template of another, you can repeat the use of an InstantCalculator with different parameters, you can even build up a series of calculations using several InstantCalculators and run iterations on all of them with different input parameters.
And there are something like 500 of these InstantCalculators, for such functions as fitting a straight line to a set of data and computing a definite integral over a range of values.
Also very handy for the beginning or occasional user are the controllers: panels that appear on the left side of the screen and provide access to a group of functions. There are controllers for basic calculations and for standard formulas and for working with units and constants and for formatting output. The controller approach lets CalculationCenter provide a more complex set of functionalities than would be convenient to display in menus. Some of these controllers are Function Controllers, which let you evaluate, for example, indefinite integrals without having to worry about syntax.
The plotting capabilities of CalculationCenter are extensive and are designed to give you an interesting plot of your data with as little input from you as possible. CalculationCenter has heuristics for deciding what might be interesting in a plot, for choosing what sort of plot would be appropriate for the data set, and for ignoring outliers that might unduly influence the plot. You can override all of CalculationCenter's guesses, but it does seem to get the right plot, at least for the simple data sets I tried.
Finally, the Help system is rich and error messages are especially informative. A lot of work has gone into making CalculationCenter easy to use. At the same time, you can type commands directly from the keyboard, so you're not constrained to the training wheels of Controllers and InstantCalculators.
If there is one thing that might still slow down users of CalculationCenter, it's probably the .nb notebook format that is central to both CalculationCenter and Mathematica. It's not that there's anything difficult about it; it's just that it is a world unto itself, and you need to think in notebook mode when using these products. That's also an advantage, though. Wolfram Research is planning a line of products for technical computation and technical publishing based on the mathematical processing power, display technology, and notebook format that Mathematica and CalculationCenter use. The .nb notebook document format is really the glue that ties the products together. Mathematica will be able to open notebook documents created by CalculationCenter and vice versa. If the other products, including a free notebook reader, do their job, the .nb notebook format could become a lot more common and a lot more familiar. But CalculationCenter may do that itself.
DDJ