PROGRAMMING PARADIGMS

Cooperation and Competition

Michael Swaine

This month I report on my visit to the April MacWorld Expo; raise some questions about Glasnost programming, ruminate on recent issues in chaos theory, fractals, and neural networks, and just barely justify the title of this month's column.

On the Paradigms Beat at MacWorld '90

The MacWorld show has now reached the same state that Comdex has been in for five years. Practically all the applications and development tools you could reasonably ask for are there, so the only question is, are they any good? That's not a question you can easily answer on the exhibit floor, so you collect the press kits, go to the parties, and schmooze. The show gave every evidence of a healthy market, ample opportunities for schmoozing, but few surprises.

Well, maybe object-oriented Prolog is a surprise. Quintus Computer Systems, of Mountain View, California, announced Version 3.0 of its Prolog compiler for the Mac, along with an object-oriented Prolog package. Prolog++/MacObject has objects, inheritance, methods, attributes, and daemons.

Apple announced Developer Tools Express, a mail-order service that allows developers to purchase release versions of Apple development tools without paying the APDA membership. To find out more about it, call or write Apple Developer Channels, Apple Computer Inc., 20525 Mariani Avenue, MS 33G, Cupertino, CA 95014-6299; 1-800-282-2734 (toll-free US); 1-800-637-0029 (toll-free Canada); 1-408-562-3910 (international).

Apple also announced Version 2.0 of MacApp, the object-oriented application framework. It should be more robust than Version 1.0, which was really Version 2.0 of the product -- the original being the Lisa Toolkit. At the Addison-Wesley booth, David Wilson, Larry Rosenstein, and Dan Shafer were signing copies of their Programming with MacApp, in the Macintosh Inside Out series edited by Scott Knaster. The book is based on Dave Wilson's courses on MacApp and object-oriented programming, and it looks good. You will need MacApp 2.0 to use the tutorial disk included with the book.

Roaming the aisles, I ran into a familiar Mac programmer who quoted new Apple COO Michael Spindler that there will be no more prima donnas at Apple. I said it showed that Spindler knew his limits in the charisma department, vis-a-vis Jean-Louis Gasse, and my programmer friend said no, it showed that Spindler didn't know anything about programmers.

A charisma gap at Apple could be a problem for the company. The Moscow model suggests that if you want your dictatorship to be perceived as benevolent, a little charisma doesn't hurt.

The 2-1/2-th Party Developer

Given that 1. Apple makes it clear to its third-party developers that deviations from the party line in matters such as the user interface are unwise, and 2. it expects the developers to see how this control benefits the developers themselves, it's not unfair to say that Apple wants its dictatorship to be perceived as benevolent. Apple isn't following any Moscow model, but it is pushing for a kind of Glasnost programming, a new openness that is supposed to result in cooperation within a competitive free market.

This new openness is the paradigm of cooperative programming, in which programs written by different companies work together harmoniously and communicate smoothly while the companies that produce them fight to drive each other out of business. There is some irony in such a plan coming along at the same time Apple is apparently fostering competition within the company by creating two distribution channels for developer tools, but no doubt APDA and Developer Tools Express will coexist amicably. Cooperative programming is not, of course, the exclusive province of the Mac's niche. (Apple may object that the Mac is not a niche product. Macht nichts.) But a benevolent dictatorship with control over the hardware platform and the operating system is in a better position than IBM or Microsoft to make it happen.

The basis for this new paradigm for Macintosh software development is Version 7 of the Mac operating system, due out later this year. Version 7 will support several levels of inter-application communication, from the existing copy and paste buffer to-live copy and paste, network support, and store-and-forward communication. Apple argues that the rich set of interapplication communication tools in System 7 will lead to a new kind of software; to smaller, targeted tools that do one thing well, rather than massive integrated applications that try to do everything.

Apple believes that this will happen, is convinced that it had better happen, and is doing a lot to make it happen.

Claris has been talking up the new approach, saying in guest editorials in computer magazines that Macintosh software developers need to learn a new way of operating -- a new cooperative spirit; the word Glasnost may not appear explicitly, but it's there between the lines. All this sounds better, one might argue, coming from a third-party developer rather than just from Apple. That is, if Apple software spinoff Claris can be called a third-party developer. The term "stalking horse" trots to mind.

Is Apple/Claris right? Is cooperative programming going to work? And if so, what will this cooperative programming be like?

Getting the Message

Here's what Apple's interapplication support under System 7 will include:

The low-level interapplication communication facilities may be most useful between applications from a single vendor, but it seems likely that only AppleEvents, with its high level of control from Apple, will have the power to make cooperative programming between vendors work.

AppleEvents may also present a new kind of pressure to adapt. It could be the best tool Apple has for getting third-party developers to add interapplication communication features to their software fast. Here's a (perhaps) fanciful account of how that might work:

If another application sends your's an AppleEvents message for which you haven't written a handler, what happens is up to the system or to the messaging application, but not to you. In effect, part of the (extended) interface to your application has been taken out of your hands. An unanswered message to your spreadsheet application triggered from within a competitor's word processing application could conceivably result in a message to the user such as "Sorry. That spreadsheet program is too dumb to handle this simple request. Maybe you should consider buying our spreadsheet program, which always works smoothly with our word processor. And if you send in your copy of that worthless spreadsheet program, we'll give you a 20 percent discount."

Maybe it won't work that way, but it is true that the mere existence of interapplication communication will create a new window into every existing application. And it is true that the control over this window, this extension to the application's interface, will be in the hands of the developer of the application only if the application supports AppleEvents.

In any case, if your application is going to fail to handle these messages, it's much nicer if it can fail gracefully to handle them. This should be fairly easy. The set of AppleEvents messages will be well defined, and handling an AppleEvents message doesn't mean that you really have to do something with it. You can simple acknowledge it and do nothing, or send back some message of your own. That's code that could be written overnight.

Here comes the real pressure. What was formerly a large task, upgrading your application to take full advantage of a major new release of the operating system, has now become a collection of small features to add. The insidious aspect of this is that, once you've got a (dummy) handler for the message in your code, it nags you to make it real, as other people in your company are going to nag you to do the same.

Then there's user scripting. Apple has pushed back its attack on user scripting to Version 8.0, but others are not waiting for 8.0: Manufacturers of applications that already have user scripting will explore ways to incorporate AppleEvents into their scripting languages. Shortly, users are going to start sending messages to your application.

So yes, it looks like Apple's interapplication communication is going to catch on quickly, and it looks like cooperative programming will become a fact of life. And that is going to raise some new problems, not all of which are technical.

Back to the Future

Here are some follow-up observations on some of the more futuristic subjects I've discussed here recently: chaos theory, neural networks, and fractals.

Recently, I wrote here about chaos theory in human physiology, and suggested that the combination of neural nets and chaos theory could produce a powerful tool for exploring the behavior of certain types of complex systems. At the EURASIP Workshop on Neural Networks in Portugal this year, Steve Renals of Edinburgh University presented some results of work on chaos theory and neural networks. One of his conclusions was that chaos could fulfill an important role in associative memory systems by providing a "don't know" state. The conference papers are collected in "Neural Networks: EURASIP Workshop 1990 Proceedings," Springer-Verlag, 1990.

The April issue of Scientific American contained a piece on the use of neural networks in determining the structure of complex protein molecules. It's apparently no longer particularly difficult to map out the sequence of amino acids that make up a protein molecule, but the three-dimensional twists and turns of the chain-like molecule are very hard to identify. The twisting structure, which determines the properties of the protein, depends on the electrical forces between individual amino acids in the chain. A brute-force approach to determining the structure would simply examine all forces between all pairs of amino acids; and with very short chains, the brute-force approach works.

For most interesting proteins, though, the brute-force approach is useless. Terrence Sejnowski and Ning Qian of Johns Hopkins University have tackled the problem with a neural-network approach first used by Sejnowski and Charles Rosenberg in NETtalk, a neural net that learns to pronounce English words. NETtalk uses context to determine the pronunciation of individual phonemes (units of sound very roughly comparable to letters in written English). NETtalk has had some impressive success, and Sejnowski and Qian thought that the electrical interactions among segments of a protein could be modeled very much like context effects on phonemic units. The results, though limited, look promising, and Sejnowski thinks that neural nets have a real future in molecular biology.

The April issue of Scientific American also asks the question, Who invented the Mandelbrot set? There is a surly controversy brewing over credit in the field of fractals and particularly for this set, which has been called "the most complex object in mathematics." You compute the Mandelbrot set from the formula z{2} + c, where z and c are complex numbers, by assigning a constant value to c, setting z initially to 0, and feeding the output of the formula back into z iteratively. Pictures of the Rorschach-like Mandelbrot set have appeared here and elsewhere, and are distinctive, if only arguably attractive. Whatever its aesthetic merits, the Mandelbrot set's discovery is an important event in the history of mathematics, as the set has many applications, especially in the testing of complex dynamical systems. The study of such systems is the aforementioned chaos theory.

One mathematician quoted in the Scientific American piece lays all the blame for the controversy at IBM mathematician Benoit Mandelbrot's feet. Apparently all of the following people deserve some credit in the discovery and exploration of the Mandelbrot set: Pierre Fatou, who defined the set mathematically; Gaston Julia, Mandelbrot's teacher, who defined the Julia set, of which the Mandelbrot set is a generalization; John H. Hubbard and Adrien Douady, who have done much work on the set, Hubbard having produced Mandelbrot pictures three years before Mandelbrot; Robert Brooks and J. Peter Matelski, who published both an explicit mathematical formulation and a computer printout showing the familiar image of the set before Mandelbrot; and F. Riesz, who did related work about 40 years ago. No one challenges the importance of Mandelbrot's own contribution, but many are put off by Mandelbrot's aggressive self-promotion as the sole discoverer of the set. Former DDJ editor Randy Sutherland and I joined the put-off when we dealt with Mandelbrot while trying to get permission to reproduce a picture of the Mandelbrot set in DDJ a few years ago. As Douady said, "He loves to quote himself and he is very reluctant to quote others who aren't dead."

John Horgan, who wrote the Scientific American piece, suggests that the controversy may in part be evidence of paradigm clash. Mandelbrot is an applied mathematician and many of his critics are pure mathematicians, with different ideas about allocating credit for work. Horgan's suggestion places this coolness among Mandelbrot mathematicians in the context of a larger iceberg, which also includes the near universal confusion in the public mind between the conduct and goals of pure and applied science, and between the ditto of science and engineering; it touches the glacial spread of university involvement in industry, the consequences of which nobody seems to be examining very closely. What it doesn't do is to warm the aforementioned coolness among Mandelbrot mathematicians.

Maybe Michael Spindler could explain to them about prima donnas and cooperation among competitors.