These days, there are two kinds of companies developing third-party programs for NeXTstep: small, energetic companies, and the big guys.
The small companies are usually hungry start-ups. They're totally committed to the platform. They've gone bananas over Interface Builder and Objective-C. They worship the Application Kit and recite NeXT's technical documentation in their sleep. They're the lean-and-mean companies like Adamation, Stone Design, and Lighthouse Design, and they're bringing out new applications five to ten times faster than they would be able to on any other platform.
Then there are the big players. These companies see NeXTstep as one of their many sidelines. When they bring their product to NeXTstep, they port their entire program, user interface and all.
Take SAS, a statistical-applications program, as an example. SAS on the NeXT looks exactly like SAS on the Sun Ð it even has OpenLook-style pull-down windows. Rather than use NeXT's Application Kit, SAS ported its own. The result is that nothing works properly: The program doesn't interface with NeXT's cut-and-paste system; there is no Services menu; menus don't pull off; there are no command-key equivalents; and text doesn't move when you drag the scroller.
FrameMaker isn't much better. Frame running on a NeXT only looks like it was built with Interface Builder. Rather than utilizing Interface Builder, Frame's engineers developed a subroutine package that translates Frame's internal functions into NeXTstep-like widgets on the screen. A similar library on the Sun makes Frame look like an OpenLook application. Other "compatibility libraries" give Frame Motif and even Macintosh "look and feel" emulation.
Although Frame did a better job than SAS, the page-layout program takes a real hit on performance. Reason: It's not designed to take advantage of the Display PostScript window server.
What these companies are selling, according to their respective sales forces, is interplatform compatibility. Because programs like Frame, SAS, WordPerfect, and Wingz on the NeXT look exactly like their cousins on other platforms, they're supposed to take less time for users to learn when moving from one platform to another.
Having a program "look and feel" the same on a Sun and a NeXT is a great help to a company's marketing staff, because it means that they only need to learn one set of features and commands. But it's a dead-wrong way to bring a program to NeXTstep. The world simply isn't filled with people who want to use a Sun on Mondays, a Mac on Tuesdays, and NeXT the rest of the week.
What's out there is NeXT users who need to work with people using Macintoshes, PCs, and Suns. User interface compatibility doesn't matter one iota Ð what's important is data-file compatibility. People using PCs and NeXTs simply have to be able to move files back and forth between applications running on different platforms.
But nobody cares if the screens look the same. NeXT users don't want a version of SAS that looks like SAS on every other platform Ð they want one that has the "look and feel" of every other NeXTstep application. Ditto for Frame and any other application from the big guys you care to mention.
This is an exceptionally important point to drive home now, as more and more companies are thinking of porting their programs to NeXTstep. The few that I've spoken with say that they're thinking of developing compatibility libraries Ð like Frame's Ð to bring their programs over.
That's precisely the wrong thing to do. Here are some guidelines for doing the right thing.
Developer Tip #1: Don't reinvent the wheel. Rather than trying to emulate the AppKit and make your program look like it was written using Interface Builder, take the time to learn Interface Builder and do it right. Send two people from your company to NeXT's Developer Camp. When they come back, let them spend a month just playing around with the machine. In the end, you'll get a faster, easier-to-use, and simply better program.
Developer Tip #2: Follow the interface guidelines. If you're porting an existing program to NeXTstep, keep the program's back end and data-file representation, but throw away the user interface and start over. NeXTstep makes user interfaces so easy that, even if it took you three years to develop your X Window interface, you'll be able to develop a better NeXTstep one from scratch in a few months.
Developer Tip #3: If people can run the same program on their NeXT as they can on their PC or Mac, what's the point in buying a NeXT in the first place?
Developer Tip #4: Dare to be different. Embrace NeXTstep, use it all. A lot of programmers moving to NeXTstep are hesitant to use things like NeXT's streams package, b-tree system, or rich set of functions in the NeXTstep library. After all, a program that uses these functions is harder to port to another platform. NeXTstep works together as a reliable, integrated whole. Use it all and you'll bring your program to market that much faster.
Developer Tip #5: Use Objective-C. Many NeXTstep programmers are afraid to use Objective-C for anything but the user interface. Some want to use C++ for their back ends; others are scared of object-oriented languages in general and want to use ANSI C. Don't be afraid. Objective-C is one of the reasons that NeXTstep's Application Kit is so good. Object-oriented programming is easy, once you get the hang of it, and, as an object-oriented language, Objective-C leaves C++ in the dust.
C++ may be the "industry-standard object-oriented language" these days, but remember: Microsoft Windows is quickly becoming the industry's "standard window system." If you want to use standards, get a PC.
If you still need convincing, just look at Lotus. Rather than bringing out 1-2-3 for the NeXT, they went back to the drawing board and created Improv.
'Nuf said.
Simson L. Garfinkel, has a NeXTstation with 32MB of RAM in his Cambridge, Massachusetts, living room.