I have to be up front with you; I have little experience programming. I took a class on programming in Pascal as a freshman in college and a class on C my sophomore year. But that's as far as it goes. The high point of my programming career came when I managed to program a nice graph for the final project. So I have to admit that when I began reading material on Rhapsody's new programming environment (code-named Yellow Box or Concert), a lot of the terms and concepts went over my head. For two weeks I scoured the internet and magazines for resources that would make sense to a lay person such as myself but searched in vain. That is until our contributing editor met an intrepid programmer at Macworld who had a certain zest for advocating and explaining the power of Rhapsody's programming environment. His name was Andrew Stone.

Andrew has a small development firm in New Mexico and has been coding applications for NextStep and OpenStep for the past few years. His company, Stone Design, is currently porting its applications to Rhapsody. Andrew was good enough to sit down with me for a few hours and give me the low down on programming in Rhapsody in non-technical terms. He was very sympathetic to my plight, saying that a lot of the confusion stemmed from Apple's insistence on laying new terms on well-established OpenStep procedures and terminology. He also agreed that the terms could be rather abstract so he explained very clearly why he found Rhapsody to be a superior programming environment. What follows is a summary of his crash course on Rhapsody's API.

One of the main advantages of developing for Rhapsody is that it uses object-oriented programming. An object encapsulates both functionality and data; the data attached to it can change but the way it communicates remains the same. Objects also allow programmers to break a large problem into smaller, more manageable blocks that can be easily arranged, adjusted and reused. The reuse is often touted as the object's greatest asset, but Andrew insists that while reuse is nice, the way objects allow you to manage complexity is their greatest advantage. Programming in procedural languages such as C and Pascal is mainly a process of constantly tweaking data and dealing with side effects. Object-oriented programming through its very nature forces the engineer to consider the architecture and underpinnings of the application, and cleaner, more effective code will result.

In our haste to praise the inherently tidy nature of objects, let's not downplay the power of their reusability. Apple has made some rather bold claims about the power of reusing objects and I decided to pin Andrew down on this. I read him the excerpts from OpenStep's promotional pamphlet that said AT&T Wireless boasted a 500% increase in production and that Fannie Mae claimed their 60% reuse of objects saved them millions in development costs. I asked him if these were realistic expectations. He said at first no, later yes. You first have to grasp object-oriented programs main imperative before you begin to reap its many benefits. You need to figure out which objects are like other objects and begin to visualize a hierarchy and learn to class and subclass your objects. Let's say you're writing a Fannie Mae bank object. But it turns out that you realize this object would really be a variation on a bank object you've already written. Then you would only have to modify or customize this bank object to fit Fannie Mae's needs. Once you begin to understand the object paradigm, you'll be able to design objects that are reusable even before you begin projects. You'll begin to think in terms of "how should I factor out this code" and "what's that abstraction behind all of this?"

To make it even simpler, let's say you're designing objects that will draw various fruits on demand but you have no drawing or other related objects to begin with. First you'd assess what properties would be common to all of the objects such as drawing. You'd then design a draw object and make that your class. Then each of the individual fruit objects would be subclasses or variations of that object. So once you had designed the draw object, you could modify it to do the drawing unique to that particular fruit (which would be adding a few lines of code), and you would quickly have the remaining objects. Once you grasp this concept, then you'll find your reuse rate climbing dramatically. Andrew's final piece of advice on the subject was don't be afraid to make mistakes. When you first start writing objects, you're going to make some bad ones. But you'll find that objects are so manageable that even if you have a poorly designed object in your program, you can drastically revise or replace it without the side effects you would get in procedural programming.

As far as the 500% increase in production goes, Andrew felt that also was a realistic expectation once you had the basics down. To put it plainly, objects save programmers time. Take the text object for example. Rhapsody's text object already knows how to bring up a ruler, center, justify, superscript, subscript, include graphics, write to a file, read from a file and much more. Using this text object, Andrew claims, you could write a fully functional word processor in about eight minutes using about eight lines of code. All because a programmer can drag and drop objects into an application using the Graphical Interface Builder.

Another benefit of Rhapsody is the tightly integrated tool kits. Rhapsody�s development environment has so many tools, it�s like a coding candy store where you can pull objects out of big bins and put them together to create custom software or, for the commercial developer, create top-notch applications. Rhapsody comes with two powerful kits: the Foundation Kit and the Application Kit. The Foundation Kit deals with non-GUI programming which includes such things as dictionaries, arrays, strings, exceptions and data. These simple objects allow you to do most core programming.

The Application Kit has all the tools necessary for building your application's GUI and allows you to easily connect your menus and buttons with the correct code. You basically draw the interface onto the screen and you can then drop buttons and menu items onto it. Most of these items are represented by icons so it's just a matter of dragging and dropping. So you can add a button to your interface, without having to worry about how it will be drawn, highlighted or how to track it. You can also test your interface without recompiling every time. The fact that you can do most of the interface by drag and drop makes it incredibly simple and intuitive. Another important tool is the Project Builder. Project Builder allows you to quickly view and organize all of your images, help, source and interface files�similar in many ways to Visual Caf�.

Rhapsody's tool kits are nice but they aren't what promise to make it the premiere programming environment of the future. Rhapsody's true innovation is its power to simultaneously develop across the four major platforms. By recompiling the source tree, you can quickly develop for Rhapsody for Intel and PowerPC, MacOS, Windows95 and NT and Unix. But most of the available literature on Rhapsody is fairly ambiguous about what this process entails. So I asked Andrew if he could explain what a developer would have to do to make their product available to all of the major markets.

You need to be on the operating system of choice but not the hardware of choice. On a PPC machine running Rhapsody you can compile for Rhapsody for PowerPC, Intel and Unix all with the push of a button from the same hardware box. But for Windows or the MacOS, you have to have the hardware with the tools installed and do a separate build, but you still use the same source tree. I asked Andrew how long it would take to do a separate build. For his latest project, a program called Create which is a top-of-the-line illustrator and web-design program, it takes about 20-30 minutes. Not bad.

So if WordPerfect were to develop their next Office Suite in Rhapsody, they would only have to write the program once and would be able to market it to three major markets: Macintosh, Microsoft and Rhapsody . . . right? That's exactly right, Andrew replies, because they would be using the same source tree. All they would need to do is have three or four platforms around and constantly test the code to make sure nothing strange comes up. If you do that, recompiling and rebuilding it is a simple process.

Rhapsody is particularly amazing in that it is cross platform yet allows you to tightly integrate each version of your application into the look and feel of its native environment. This varies wildly from Java, which claims to do the same thing but doesn't. Java, according to Andrew, is just not quite there yet. "The graphics are cheesy-looking," he says, "and so are the redraws. With Rhapsody you can deploy everywhere, but you can deploy optimally with the different hardware. That's something you just don't get with Java."

Hearing about these great features is nice but I'm certain many of you would like to see these tools in action and some concrete examples. Earlier, Andrew claimed that he could write a fully functional word processor in eight minutes with eight lines of code using Rhapsody (a claim, I'm certain, that probably raised a few of your eyebrows). So I asked Andrew to walk me through the process.

You start by opening Project Builder and making a new project. This in itself will automatically create several skeletal files�one of which is your main interface. You double click the main interface and open it and drag on a text field. You stretch the field until if fills up your window. Next you click the spring in the inspector to give the document "sproinginess" (the technical term for having the document automatically re-size with the rest of the window). Then you add various menus that enhance the program's power. For example, you have the text menu that has all of the rulers built in and your font panels with bold, italic, subscript etc. By dragging that onto your menu, you've added that power to whatever object you're working on. Thus far, we have yet to write a single line of code.

So you're still in the Interface Builder and you've dragged on your menu items. Next you'll want to create a class, a word-delegate class to be specific. You create this class and add an instance variable called "the text." You then connect the variable to the text object in the window. Now we build the "save" and "open" commands. You tell the Interface Builder to make that class for you (which automatically stubs it out for you and actually creates the code except for the actual function itself). Then you write your eight lines of code such as "open panel gets an open panel: open panel." Then "if you run modally, what's your file name?" This will bring back a file name and you tell the text object to save itself to that file name. Writing the "open" code is the same process. You open it; you get a file name; and if the text can read itself from that file name, you've done it. You have written a respectable, wysiwyg word processor that can do all types of rich text in addition to allowing you to embed graphics, align, indent, hang paragraphs . . . pretty much the whole package with no 32,000 character limit. You might have to spend another hour doing more general programming that would allow it to handle multiple documents and other power features, but this demonstration should amply illustrate the raw power of Rhapsody's programming environment. Watch out WordPerfect; here I come.

So the question remains . . . if Rhapsody has all of this to offer, what would prevent developers from adopting it as their development environment of choice? One concern developers may have concerning Rhapsody's programming environment is the learning curve: will an experienced programmer have difficulty learning object-oriented programming and will he or she have to learn Objective C? Andrew's answer: an experienced programmer should have little problem picking up either skill but it would be worthwhile to read a book or two on writing clean object-oriented programming. But developers don't have to learn Objective C because Rhapsody is language independent. You can program in Objective C, Java or C++. The interface has to be written in Objective C, but the rest can be written in your language of choice. Apple is predicting that Java will become the language of the future for Rhapsody and are channeling their resources in that direction. But they are currently working closely with Metrowerks to ease the transition for those who currently program in C and its variants.

Another reason developers may be hesitant to adopt Rhapsody is because they fear the hazards of programming in an untested environment. But programming in Rhapsody will not be hazardous because it is a tried and true system that is the result of years of testing and development. The history of Rhapsody began back in the 80's with William Parkhurst, an early Mac developer who was working with Mac Paint and Mac Draw and realized that you really couldn't do much with these programs. He found out about a plug-in called QuickArt Effects that you could add to Mac Paint and would allow you to rotate and flip bits. He realized that the Macintosh had no high-level tool kits and that this was a serious problem for developers. Parkhurst brought this vision with him when he came to work for Next and his ideas were integrated into NextStep. The first release had problems, as innovative ideas are wont to have, but subsequent releases addressed many of these problems and it is this refined programming environment that Rhapsody users inherit.

Rhapsody's toolkits and cross-platform nature could very well make it into the developer's OS of the future. Mainly because developers will be able to market their applications to all of the major markets. This ultimately benefits the consumer because the availability of software will allow them to use the operating system that best fits their needs rather than which is the most viable. So those businesses who find Rhapsody's true multi-tasking and protected memory alluring can make the plunge without the worry of being trapped in an obscure, incompatible format. Those businesses who aren't willing to switch just yet can still have access to the powerful programs developed in the Yellow Box. Basically, Rhapsody will allow developers to leave no market stone unturned and will give users the freedom to choose an OS based on preference rather than necessity.

For all the benefit to users that the Rhapsody operating system will provide, perhaps the most important benefit will be one that they never see. Because of Rhapsody�s superior development environment, Rhapsody users should be able to choose from an abundance of software. This groundbreaking strategy should banish spectre which currently haunts the mac platform - abandonment by software developers. And because developers will have access to larger markets and powerful object based tools to make their jobs easier, it could even conceivably drive down the price of software across the board.

For more information on Stone Design and its products, visit http://www.stone.com

Home | News | Features

Copyright © 1997 OS News