The application model is not dead yet. But it is in intensive care, and the heirs are getting impatient. One man who has made a career of impatience, Steven P. Jobs, resurfaced this summer in a venue that one might think an odd place to discuss the death of the app: Rolling Stone. Steve had come down from the mountain to preach the word to the masses, and the word was OOP.
In the 1970s, Steve explained, only the elite could use computers. The personal- computer revolution changed that. In the 1990s, only the elite can create software solutions, and object-oriented software development will change that. Object-oriented software development will bring about a radical change in the way software is written, used, and distributed; traditional applications will go away; and blah, blah, blah.
Sorry, but I mean, Steve Jobs is not the first person to make such predictions, is he? Even as I was writing this month's column, an obscure newsletter crossed my desk announcing "The Application Is Dead: Long Live the Business Object." An article in another publication begins, "Everyone knows that object technology is the future_." (Of course, there are contrarian voices: BYTE magazine recently announced that OOP has failed, and that we'll have to rely on Visual Basic. Hmm.)
The point of the BYTE piece, however, was that object-oriented programming hasn't lived up to the revolutionary predictions. Anybody who has ever programmed in C++ knows that merely using object-oriented tools doesn't suddenly change the world. What Steve is talking about is the universal availability of good reusable software components, a development that object-oriented tools ought to make not only possible, but real, and that would indeed change the way software is written, used, and distributed. But, as the BYTE piece points out, it hasn't happened.
Nevertheless, I think Steve's right. At least, if you factor in the spin that he puts on his arguments in order to make the answer come out NextStep.
Several forces do seem to be leading us toward revolutionary change: The compelling need among users to focus on the solutions to their problems rather than learning a new application. The compelling need among developers to escape from the tyranny of the monster app that does it all. The clear economic imperative of good reusable software, if we can just figure out how to make software reusable, and how to know that a piece of reusable software is any good. The clear economic advantages of rapid development and responsiveness to user needs that would come with a shift from a market of a few huge applications to many small components.
Applications are not just monstrous in terms of size; they are beginning to look a little grotesque with all the gadgets and wires of the life-support systems they get hooked up to in order to keep them alive one more year. The monarch is ill. Revolution is in the air.
Steve thinks the winner will be NextStep. IBM and Microsoft have their long- and short-term plans. Mac fans are optimistic about OpenDoc or vaguely hopeful about Taligent. But there are people who aren't waiting; like impatient revolutionary Lee Buck.
I first became aware of Lee's work when I was writing HyperTalk code and trying to keep a low profile about it so as to maintain some shred of credibility among real programmers. It turns out that I was not alone: At this year's Apple Worldwide Developer's Conference, one developer assured Apple that there were more HyperTalk programmers than even Apple knew about. Godzillions of closet coders were prototyping apps and even delivering completed apps to clients using HyperCard, playing every game they knew to disguise their works as real applications.
Lee Buck was one of them. He founded a consulting company, SDU, in 1988, and soon he was creating multimedia titles for the likes of National Geographic and Apple Computer. Lee used HyperCard and found himself developing tools to make a stack look more like the real thing. One tool, WindowScript, was an interface builder for HyperCard that lets your stacks do anything--visually--that apps could. It was the ideal prototyper and the perfect masquerade. (Close to perfect: It didn't do anything for performance.)
The next evolution was away from HyperCard and on to AppleScript. Apple's system-scripting technology has no interface; Lee's FaceSpan lets you give it one. More than that, you can use it to create small apps quickly with full user-interface features. And because it is built on top of Apple's AppleEvents system, you can build solutions that use system capabilities, or span applications, or use single applications as functionality toolkits. Because Apple is bundling FaceSpan with its AppleScript developer package, FaceSpan is getting a lot of attention.
I talked with Lee in May about FaceSpan, application development, and where current trends may be leading.
DDJ: FaceSpan is more than just a front end for AppleScript. Since Apple is bundling it with the development package for AppleScript, it's more like the official front end for AppleScript. What does it mean to be blessed by Apple?
Buck: For us, it's exciting; it's an opportunity to get a set of tools out to a larger audience. There's a real opportunity on the Macintosh side to do a better job of taking the robust functionality and capability that is available embedded somewhere in all of the wonderful application software out there and delivering it in a much more focused way to users.
DDJ: For example?
Buck: There are a lot of people out there who use two menu items and three dialogs of Excel, and that's all they do. I think Apple was right in its vision of making applications that are smaller, [more] focused to users' needs.
DDJ: You mean OpenDoc.
Buck: OpenDoc is a really neat technology. I look forward to supporting it more. At the same time, in the here and now, we can bring some of those benefits to users today.
DDJ: Benefits like what? OpenDoc is a whole new model of computing.
Buck: Better focused solutions. Ones that meet specific users' needs. The problem OpenDoc is solving is, in part, that I had to bring along the other 80 percent of Excel in order to let you [use your two menu items and three dialogs]. If we can help address some of those things now, we don't eliminate the imperative for OpenDoc, but in the short term we address some of the real, pressing needs that users have for more-focused solutions.
DDJ: Tell me more about FaceSpan.
Buck: FaceSpan is an interface builder. It is focused on the task of building applications and the user-interface elements of those applications. It does so at the expense of some of the other services that you might see in a [product like] HyperCard. It doesn't have a data-storage model, per se. It doesn't have strong text-retrieval and searching mechanisms. It doesn't have paint tools. But it aspires to be a very flexible set of user-interface tools that allows you to manifest and to create, probably in the next version, 80 to 90 percent of the functionality of most commercial products.
We always believed that everyone spends far too much time telling a computer how to do something. We wanted to deliver tools that let people make real things, things that are indistinguishable from what you might get from using C and so on, but using much more highly leveraged tools.
DDJ: How is it different from something like HyperCard?
Buck: We are focused on the user experience, and we have AppleScript as the glue that binds. There is a class of applications that we're good at, there's a class that we're not. If there's anything that's computationally intensive, you're going to have to go somewhere else to get that done. One of the dynamics you find in other environments is that you have to be very mindful of their limitations when devising a user interface. Part of our desire is to give you a canvas, the ability to create the right user interface, and then worry about technical limitations and actually getting it done later. Our worldview is that you ought to start at the user experience, and then the rest is just engineering.
DDJ: Where is FaceSpan going?
Buck: There are some possibilities, one of which is that we have the notion of a component. It's a little run manager that knows how to do things like open a window, set a window property, close a window. And those are all accessible from C and Pascal. So one model is that you would write programs in C and Pascal and just shove off the UI tasks to this API.
DDJ: I understand that you are doing that already.
Buck: We are using our component in that way for some projects. One of the nice things about that is that we prototype in FaceSpan, get client buyoff on the screens, and then those are the screens. We don't go make the screens; those are the screens that get used in the actual product.
DDJ: Is this going to be a product? Or a technology direction?
Buck: I don't know the answer yet, but it sort of makes you go "Hmm."
DDJ: You didn't mention AppleScript at first when you started talking about FaceSpan. And you characterize it as the glue. How ungluable is it?
Buck: We're OSA compatible, which means that we can plug in any kind of scripting language. Again, this is not necessarily a product direction, but with the code-fragment manager, you could imagine making C++ an OSA language, and it would just sort of work, and it would bind to other segments that you've got elsewhere in your program. So you could imagine being in FaceSpan and saying, "I need to write this in C++, please." That would be sort of cool.
DDJ: Of course, one of the things that C and C++ and Pascal programmers have against HyperCard is its performance, and AppleScript isn't a speed demon. Are you concerned about performance issues?
Buck: With the advent of PowerPC, when you bring the AppleEvent manager native, AppleScript native, put a [Power Mac] 620 on everybody's desk--that's three years out--call it a 5x, 10x improvement over 040. The fact that [an application] was developed in AppleScript really doesn't matter as much any more. If the window comes up in one tick or two ticks really doesn't matter to the user.
DDJ: Most of the first apps to come out on PowerPC aren't getting much more out of it than speed.
Buck: It reminds me of the old days. Cool, I've got a faster machine, I can run Lotus quicker. Well, the Macintosh said, No, let's do something with that horsepower. Let's deliver a better user interface.
Well, we've got more horsepower. Let's do something with that horsepower instead of just running C faster. There's a whole class of people who have not sinned sufficiently in life to have to program in C. They shouldn't have to. They're just trying to get a class of problems done that doesn't have to perform like a bat out of hell. These are the same people [about whom] we thought the performance of a Mac 128 was just what they needed ten years ago.
DDJ: I gather that you think there's room for improvement in programming environments.
Buck: Every time I'm in a language and I hit compile and it comes up and says, "This variable is not defined," I feel like it's reached out and slapped me instead of saying, "Shall I define it?" or, "Do you mean this one that is spelled really close to the one you just typed in?" That's really stupid.
In all of these wonderful studies about productivity and lines of code, I know there's at least 10 to 40 percent of productivity that we can pick up, crumbs that are lying around. Instead of reengineering languages, we can start collecting some of the crumbs.
DDJ: Such as?
Buck: Formatting C. Call me silly; I shouldn't have to spend a lot of time hitting tab. I just think that's stupid. Different people have different formatting styles; that's nice. I don't care. The format of your C code isn't what your engineers should be spending lots and lots of time on.
We just need to treat programmers like users. We need to think about the user experience [of programming].
DDJ: How about application frameworks?
Buck: I think frameworks are cool, frameworks have a real place, but you're living in somebody else's house. I think there is at least space for people to consider another model, which is, "We're a set of really cool services that can make a whole class of your headaches go away if you want us, but it's completely under your control."
DDJ: Can you give me an example of a good feature in a programming environment?
Buck: One of the great innovations of HyperCard that has gone unheralded was that the programmers spent all of their time in the user's space. They were looking at a stack. They would go into a script, they would add a little [code], and they would go back and spend their time in the stack. When you think about traditional development environments, you spend all your time in C++ looking at object browsers and tools dedicated to your task--and then five minutes looking at the program.
And this is bad because you don't inhabit the space that your users are going to inhabit. [We need to] get tools to a state where I can spend less time in those environments and more time in the user's space. You don't see it much in traditional languages--for very good reasons. But there's that underlying dynamic that I think we need to pay attention to.
Another thing that HyperCard did right was, if you do nothing, you get something. We tried to do that in FaceSpan. If you open up FaceSpan and create a new document and do Save as Application, you get a double-clickable application, it brings up a splash screen, the font menu works, style menu works, edit menu works, undo works--and then you can incrementally add behaviors.
In any kind of framework, if you want to deliver that same functionality, it's, "Let's talk about the class-inheritance structure, and next week you'll be ready to make a quick something."
DDJ: Let's get back to the software-components revolution, or whatever you want to call it. Where do you see things heading, in the long run?
Buck: There's an interesting trend. If you look back at the good old days, there was a monolithic, linear program. And then we had these things called "subroutines," and we could split the program from one monolithic huge thing to smaller chunks and have some connections or relationships between them. And then we moved to object-oriented programming, where we said, "Let's make those subroutines even smaller still, let's have more sophisticated kinds of linkages between bits of code." And one way of looking at this is that we're beginning to put less and less information into the code and more and more information into the network.
So there are two points: I'm not sure we've really thought enough about a class of tools that help us understand what information is being encoded in the network. Object browsers are just access to source code. Those aren't the answer.
The other interesting thing is, what's the [limit] of this trend? The [limit] is little bits of code that know almost nothing and where the connection is everything. Like, for example, oh, a neuron. It knows nothing, but the connection is everything.
So, in some ways we're finding the path of computing evolving in a way very close to the biological analog.
DDJ: For which we have no documentation or user interface.
Buck: Yeah. No clues at all. And even in neural nets, I think that they just sort of go, "Cool, look, it works."
Copyright © 1994, Dr. Dobb's JournalCome the Revelation
Bucking the Trend