The death of the application.
I heard the phrase again the other day. I think the first time I came across the death-of-the-application phrase was in a talk by Ted Nelson a few years back. Ted's contention was that applications are evil: They put the user in a conceptual straightjacket, and the user needs to think in terms of the actual task, not in terms of software-market categories. Applications are in the way and must go, or at least fade into the background. What does Ted think will be the death of application software? Thus far that answer has been wrapped up in a vaporous project called Xanadu, a lifetime in the realization and still unrealized. Xanadu, the app-less paradigm, is no present danger to application software. But the app killer may be lurking out there right now.
The second time I heard the phrase was at this year's MacWorld Expo in San Francisco. I ran into Steve Michel, who writes about scripting for MacWEEK. Steve had to tell me something that Leonard Buck had said, a phrase that kept running around in his head: "The death of the application."
I heard it again the next day, but the ultimate source for that third use was the same person: Leonard Buck. Buck is the author of WindowScript, a nifty product that I've mentioned here before. WindowScript is a HyperCard add-on that gives anyone who can master HyperTalk scripting an impressive degree of control over user-interface design. The first incarnation of WindowScript was the award-winning tool Dialoger Pro. The second incarnation was enough of an advance that it merited a new name. The latest version is probably as big a step forward in capability, because it supports AppleScript.
There are so many thisScripts and thatScripts floating around these days that unless you develop for the Mac, you are justified in not knowing offhand what AppleScript is. Briefly, it's Apple's scripting language for controlling applications and the Finder. Its native syntax is similar to HyperTalk, but developers can substitute other dialects. It's built on top of Apple's AppleEvents protocol. Some applications from beta-seeded vendors are now supporting AppleScript, although an application can give various possible levels of support to AppleScript. The most interesting--and difficult--is scriptability, which can require rethinking and rewriting the entire application in terms of conceptual objects (such as windows and buttons and other visible components of the user interface, as opposed to OOPS objects) and common commands that take such objects as parameters. In other words, full support in an application for AppleScript is costly. What does the application get from full support? That's an interesting question I don't have an answer for, but it's clearer what other products (and users) get from applications supporting AppleScript.
Other tools that are not exactly applications are taking advantage of AppleScript. Scripter from Main Event is a script editor that attempts to simplify object specification, probably the toughest part of AppleScript scripting. And AppleScript's support for dialects will allow products like HyperCard and UserLand Frontier to provide their own dialects. Tools like these will let sophisticated users write or edit scripts independently of any particular applications. But WindowScript--well, WindowScript is something else.
It wasn't what anyone said that impressed me about Buck's WindowScript; it was the demo I saw. I had spent the day looking at demos of AppleScript and attending lectures on AppleScript, and the demo of WindowScript showed me more than anything else I had seen or heard about the usefulness of AppleScript.
A straightforward description of the demo won't get the idea across. The straightforward description is that a HyperCard add-on was used to drive several applications, shunting data among them and performing one coherent task. But the feeling of the demo was altogether different from, say, piping UNIX commands or writing JCL files, or, for that matter, building QuicKeys macros or writing HyperTalk or Frontier scripts. The WindowScript user can design and create new windows that don't seem to belong to any application, windows that implement tasks not apparently restricted to any one application. In fact, these windows belong to HyperCard, with all its overhead, but that limitation is in the process of disappearing, with some other HyperCard-related products that have come out. Besides, in the demo one didn't notice the HyperCard angle.
It's not so much what WindowScript can do that impressed me as the vision of user development that it gave. Picture a layer of user-created windows, not associated with any application, floating in front of all application windows and driving the apps. If you get the picture, you get an extremely visual impression of a new level of software, a level above the application.
The death of the application? Probably not. But perhaps the birth of something genuinely new.
Copyright © 1993, Dr. Dobb's Journal