There's a lot of Apple-related stuff in the column this month, but not as much as you might conclude from a cursory look. The bulk of it is about a book on software design. Overall Macishness rating: 6. I thought you'd like to know.
In How to Drive Your Competition Crazy: Creating Disruption for Fun and Profit (Hyperion, 1995), Guy Kawasaki itemized the steps Apple took to meet the challenge of IBM's entry into the PC market in the early '80s: "First, we created an advantage called the 'Macintosh user interface....' Second, we fostered innovative applications like the desktop publishing program called 'Pagemaker....' Third, we incited customers to evangelize Macintosh and turn it into a cause...."
Apple frittered away the first two advantages and is in the process of losing the third. Although Apple's financial health is much better than reports would suggest, corporations, unlike Mark Twain, can be killed by bad PR. And although Apple has always been the kind of company that would consider it good PR to make the cover of Rolling Stone, the recent cover story titled "The Fall of Apple" just can't be what they had in mind.
Everybody has a theory about the source of Apple's troubles, but at least you can't blame those members of the Mac team who went off to start General Magic.
When I recently wrote about Alan Cooper's About Face: The Essentials of User Interface Design (IDG Books, 1995), I quoted from Alan's critique of General Magic's Magic Cap interface. The folks at General Magic had a different perspective, and expressed it in our April 1996 "Letters" page. This is as it should be. The truth is, the Magic Cap interface wasn't designed for me, or for Alan, or for anyone who has a problem with cute bunnies. (Darn, I wasn't going to do that.) It's a very interesting and innovative interface for an interesting and innovative new platform (and I should probably get some help for my bunny problem). If you want to make up your own mind about this original and deep interface, you should read the book.
The book to which I refer is Barry Boone's Magic Cap Programming Cookbook (Addison-Wesley, 1995). The book is a fine tutorial on Magic Cap development. You write Magic Cap programs on a Mac using a special C development environment, a version of which is supplied on the included CD. Also in the environment is a Magic Cap simulator, which seems to work very nicely. When you want to test your code on a real Magic Cap device, the book explains how to do that, and the CD has all the software you need. Programming for communications is way easier for the Magic Cap environment than for the Newton, because most of the work is already done. Although this is an introductory book, it actually provides some useful communications program examples. What puzzles me is why the book's cover artist decided to illustrate the Magic Cap Programming Cookbook with a pot boiling on a stove, above which, in the rising steam, floats the ghost of the Magic Cap bunny.
If I have underpraised the Magic Cap interface, I may have overpraised The Power Mac Book. No sooner did this book by Ron Pronk come out, decorated by flowery praise from me, than two people who know a lot about microprocessors in general and programming for the PowerPC in particular called to tell me there were a few mistakes in the book. There's now a new edition (The Power Mac Book, Second Edition, Coriolis Group Books, 1996) that, Ron acknowledges, fixes a number of flaws and adds a lot of new material.
This book tries to do a lot: Present the history and corporate politics behind the PowerPC chip, second-guess Apple corporate strategy, and present the basic facts on Apple's product lines in a way that a general reader can understand. It's more successful in some of these attempts than in others. The discussion of RISC versus CISC, in particular, will probably still strike my more technical friends as oversimplified. Pronk analyzes Apple's strategic blunders and blinders at length. Whether or not you see 'em as he calls 'em, it's nice to see someone play the popular game under the constraint of having to be consistent for a whole chapter. Those of us who play the game in monthly magazine editorials and columns have it easier: We can lambaste Apple for laying off employees one month, for not licensing clones early enough the next month, and for giving away its interface to Microsoft the next--without having to worry about what relationship, if any, there may be among these strategic decisions (or nondecisions). I do like Pronk's analogy between Michael Spindler and Mikhail Gorbachev, although it's more than a little generous to one of those Mikes.
Although the book is directed at a non-technical or not-very-technical audience, it does serve as a handy collection of facts about Power Macintoshes that could be useful to anyone who supports or writes software intended to serve the entire line, from the first Nubus Power Macs to the clones to the new 604 machines.
Okay, I just have to get this off my chest. Although the reason for the World Wide Web's creation was, more or less, so that the wheel did not have to be reinvented daily, but could instead be invented once and linked to, one consequence of the Web is that everyone who writes a book feels compelled to include a chapter on the origin of the Internet or the World Wide Web, and this book is no exception. For the benefit of future book authors, here's the URL at which you can find all the documents pertaining to the origin of the Web: http://www.cern.ch. Unless you know the story better than Tim Berners-Lee, just give the link, okay? I feel better now.
The General Magic founders are not the only Mac magicians who have taken their magic elsewhere. Bruce Tognazzini actually is an amateur magician, a hobby that he claims has helped him a lot in his true calling as a software designer/critic. Apple kept him up its Macintosh sleeve for years. Then, in 1992, perhaps after seeing his shadow, Tog sloughed off that winter's garment and went out to play in the Sun. He is currently a Distinguished Engineer in the Office of Strategic Technology at Sun Microsystems. Tog on Software Design (Addison-Wesley, 1996) is, sort of, his Sun book, as Tog on Interface (Addison-Wesley, 1992) was his Apple book. The centerpiece of the book is a video script produced at Sun to prototype a vision of computing in the near future. The goal, one assumes, was to help the Office of Strategic Technology determine which technologies would be strategic. Tog presents the script, complete with outtakes, early in the book, and then discusses software design in the context of the technologies demonstrated in the video, which is called "Starfire." (Well, not demonstrated. Faked, actually. This video is in the Apple tradition of whizzy demos. The big difference is that all the technologies in the Starfire video are supposed to be at least close to real.)
There are, then, two reasons to read Tog on Software Design: as a book on software design principles and advice, and as a white paper on Starfire, Sun's next-generation computing project.
Tog's 1992 Tog on Interface was not as designed as Tog on Software Design. The older book was a collection of usually useful, generally well-researched, and often very funny essays offering advice on user interface issues, mostly specific to the Macintosh user interface. Tog on Software Design has its chapters of useful advice on specific software design issues, like transparency (it's not a helpful concept), consistency (don't confuse it with uniformity), and ease of use (it fixes the upper limit of users' productivity).
But Tog on Software Design puts its advice in a larger context, a perspective on where computers are going in the next decade. Anybody can spin out trends and make predictions, and Tog spends a significant chunk of this book in futurist mode. What makes this of more than casual interest is that the value you'll attach to at least some of his advice hangs on how seriously you take his extrapolations. But then, Sun is taking these extrapolations seriously enough to fund Tog and the Starfire video team.
Another difference between this book and the earlier one is that the advice is less platform specific. It's not that Tog doesn't deal with specifics of software design. He does. He does it in terms of specific products for specific platforms, as when he praises details of the design of several Mac-based products from HSC Software, where innovative software designer Kai Krause routinely breaks the rules to create great software. (In fact, most of his concrete examples are Mac programs.) He does make comparisons across platforms, although they are often broad generalizations:
The original Macintosh was so sensitive to the needs of the new users that anyone using it for more than around a month ended up hopelessly frustrated. UNIX, on the other hand, threw every single possible option in the new user's face simultaneously, then demanded that the new user understand each option well enough to decide whether it is needed.
A lot of us might agree with his assessment of the Mac, but I think we could present a good argument that, in certain contexts, UNIX does just the opposite of what he says. He does follow these generalizations with sound advice:
Never present an expert-user option in such a way that normal users must learn all about it in order to know they don't need to use it.
And he follows this with a concrete example--the advanced paste capability in Microsoft Word--that shows clearly how to do it right. Compared to About Face, Tog on Software Design has fewer concrete examples, less practical advice on specific problems of software design, and less software design advice overall.
But Tog on Software Design has its unique virtues. Tog's advice is more grounded in research. Does this actually matter? Isn't it better to get the advice of someone who's down in the trenches, like Alan Cooper? Actually, both perspectives have their merit. Toward the end of the book, Tog presents the results of some solid research that shows conclusively that research is absolutely crucial to software design. If that doesn't convince you, I don't know what will.
The other thing that distinguishes Tog on Software Design from About Face (and from most books on software design and user interface design) is its heavy emphasis on trying to predict the near future. Tog predicts at the level of markets: "Keep your eyes peeled for successful enclaves. They will lead you to the future." And he charts the future of hardware and software and the Internet.
But the real reason Tog and the OST engineers at Sun want to make these predictions has nothing to do with writing books on software design. Starfire is Sun's exploration of where the computer industry and Sun should be heading if the next generation is to be something better than the current generation.
Tog and the Starfire team apparently take these predictions pretty seriously, and have formulated a vision based on them. That's the video. In case you're interested, Sun will sell you Starfire: The Director's Cut for something like fourteen bucks.
Long before the first "... for Dummies" book explained computers to the Great Unwashed, there was Russ Walter's The Secret Guide to Computers (you can order the self-published book by calling Russ at 617-666-2666). Russ may not be so unsung to programmers in the Boston area, where his profile is higher, but he deserves much more fame than he currently has. Ironically, more fame is probably just what he doesn't need, for reasons that I will explain momentarily. So maybe you could just make obeisance to the east and then keep this under your hat.
One reviewer called The Secret Guide to Computers "the greatest single self-teaching book on the subject of computers that I've ever read." Here's Russ on the origin of C, which at least hints at his style:
In 1963 at England's Cambridge University and the University of London, researchers developed a "practical" version of ALGOL and called it the Combined Programming Language (CPL). In 1967 at Cambridge University, Martin Richards invented a simpler, stripped-down version of CPL and called it Basic CPL (BCPL). In 1970 at Bell Labs, Ken Thompson developed a version that was even more stripped-down and simpler; since it included just the most critical part of BCPL, he called it B. Ken had stripped down the language too much. It no longer contained enough commands to do practical programming. In 1972, his colleague Dennis Ritchie added a few commands to B, to form a more extensive language. Since that language came after B, it was called C. So C is a souped-up version of B, which is a stripped-down version of BCPL, which is a stripped-down version of CPL, which is a "practical" version of ALGOL.
From his perspective, Russ sees his coverage of C programming as somewhat outdated and plans to revise it in future editions. The 21st edition will be out about the time you read this column; I have in my Quaint Old Computer Books library the 10th edition, which was published in 1980. It has an excellent comparison of the IBM Selectric golf ball print mechanism versus the Teletype model 33 cylinder, daisy wheels, and thimble print mechanisms. Russ is famous for publishing his phone number in the book and inviting readers to call him with their questions. He gets about 60 calls a day, the last I heard, at all hours. That's why I'm not so sure he needs more fame. In addition to calling Russ directly, you can find out more about the $15.00 The Secret Guide to Computers (discounts available when you buy multiple copies) at ordway@ionet.net.
Okay, I'm still using HyperCard and HyperTalk after all these years. I do find myself integrating other scripting languages with HyperTalk--dropping an AppleScript script into a HyperCard button here, hooking into some Frontier tool there. And I'm finding that my HyperTalk scripting is having a rebirth as I develop tools for my own use in browsing the Net and exploring Web server technology.
The latest tool I've been playing with is Marionet, from Allegiant (http://www.allegiant.com), the company that now owns SuperCard. It's an inspiring story: Big company buys product, lets it languish, then finally sets it free. Loyal users have been getting support from loyal creators of product all this time. Loyal creators scrape together nickels and dimes, acquire rights to product again, start a new company to enhance and support it. In a few months, they're putting out new versions and working hard on Windows port. And now they're doing new products, too.
Marionet is not an add-on to SuperCard or HyperCard, but a separate product. It's basically a faceless background application that knows about all sorts of Internet protocols and is callable via a HyperCard or SuperCard external command, AppleScript, Frontier, or raw AppleEvents from C or other languages. It does most of the grunt work of the interfacing, letting you put things together very quickly. What you give up, obviously, is detailed control, but sometimes that's an acceptable price. I'm playing around with it as a way to hook up databases to my Web site without much programming. Marionet thinks in terms of sessions, so you script it with session commands as in Example 1.
The point? I'm finding that I am able to put together solutions to common problems in very short order. Marionet may not be your magic lantern for Web work, especially if you're working in Windows or UNIX, but something like it may well be. The Web is such a fast-moving target, scripting tools have got to be a big part of your arsenal.
Magic Recap
Mikhail Spindler
Tog Story
Tog in Review
The Starfire Project
Unsung Heroes of the Computer Revolution
Scripting the Internet
Example 1: Scripting Marionet sessions.
Marionet "BeginSession"
Marionet "SendMail", sessionID, serverName, from, toList, messageText
{,errorVar}
Marionet "EndSession"