SYNOPSIS: Apple scored a coup in acquiring the OpenStep development environment with the Next purchase. "Objective-C", a programming language, is not proprietary. Anyone can develop in it. Our spin: In OpenStep, Apple purchased a fully mature development framework which gives its programmers an inherent edge in getting superior product to market on time. We predict it could pay off quickly, if other marketing considerations don't get in its way.

Objective-C For Dummies

This isn't another article about the "look and feel" of Rhapsody. We'll examine some significant aspects of the underlying programming language itself. We'll look at considerations which have, so far, escaped the scrutiny of analysts, the Mac community at large, and the general public.

We expect Rhapsody to look and feel good. We expect it to be fast, powerful and exciting. But it could be almost all that if it had been programmed in Visual Basic, and that might not have been enough to turn Apple around.

The point which has been largely missed, perhaps because it seemed "too technical" to explain to the general public, is how Apple expects to recoup its $400 million investment at a time like this. Word on hacker alley is that Apple already had a respectable next-generation MacOS port to Unix, which runs on its proprietary Mach unix core. This OS supports multitasking, protected memory and more --right now. Why didn't Apple use it?

A $400 million investment in a competitor, just to bail out the floundering Copeland effort, would have been inexplicable. Apple is, first and foremost, the most innovative mainstream software OS developer. What do you suppose really happened here?

We'll attempt to explain some key programming considerations which might have led a programming company to take such a drastic step. We'll try to explain it in a way that should make sense to you, clear up some frequent-flyer buzzwords, and make you feel better about what Apple is doing to preserve its stake in personal computing's future.

Along the way, we'll try to show you how this might spin off into benefits for you as a Mac (or Windows) user.

This was a programming decision, but it was thoroughly Mac.

If you own, or are even thinking of owning Apple stock, you have an even more compelling reason to try to follow the underlying programming considerations of the Apple/Next acquisition.

One of the most powerful ways our lives as Mac users could be affected depends on how the OpenStep developer framework is received in the programming community.

You probably know that many developers, particularly small developers, are disaffected with Apple right now, because of the announced discontinuance of many programs into which developers (particularly small developers) have poured a lot of time and money.

"Small developers" include the folks who brought you most of the utilities and small programs which have helped the Mac become "insanely great": Conflict Catcher, originally written by Jeffrey Robbin, Tex-Edit by Tom Bender, and hundreds more. No one in the press is mentioning names, but we all know a great OS needs great applications.

If it's economically more profitable for you, as a small developer, to develop for Windows, and "port" your code to Mac when, as and if you feel like it, that means more time lags between Windows and Mac versions of a product. We should already know that means more defections by power and corporate users who can't afford to wait the extra year for their software upgrades.

Rhapsody is not about being "just another pretty face". It is not even about being a "modern" OS, though that's required. After half a decade of putting up with an agonizing plethora of small revisions to System 7, it's time we look at how such revisions are put together in the first place.

Evaluating your future with the MacOS is pretty much like researching a stock purchase. At this juncture, the key question is:

What's in the new MacOS for the programmers?

	elegance
	simplicity
	a new syntax
	"corporate" support
	dynamic linking
	portability

There is no way to explain how "this is better for Mac" without either assuming or explaining some of the programming concepts as we go along, but there is no reason to assume we can't all benefit from being exposed to an overview, either.

I want to caution that I am not a professional programmer, nor writer of programming texts, and the explanations and understandings presented here are my own, written from the viewpoint of the end-user and occasional programming hobbyist that I am. This is not a programming primer.

Without going into details a programmer would expect, here's the skinny (as I see it, and in no particular order) on how the language underpinnings that Apple has adopted could affect developers.

The "NewOS", OpenStep, Rhapsody (or whatever you want to call it) could be the biggest break developers, including Apple programmers, have had for years.

Cost-Effective

Programming departments, both large and small, consume huge budgets. A "simple" menu utility could take a man-year-and-a-half to develop, test and rewrite just to get it to shareware beta status. There are other considerations, such as optimizing the code so it runs fastest on a certain type of machine, to add overhead also. Revisions and "upgrades" add development time, an extra version to support, and must be coded and tested as seriously as the original release -- if "buggy" code is not to be released to the public.

Once the programmers are finally done, the marketing and distribution folks have to take over. A mid-stream shift in tactics, development effort or languages can be incredibly disruptive, expensive and annoying. Too much of this can cripple or kill even a large company, as we've all seen.

Simplicity and Elegance: Re-usable Code

Programmers who have worked with the Next language, "Objective-C", say that they like it. They say once you master some differences in syntax from other variants of C and C++, it's much easier to write clean, re-usable code. Designing chunks or "modules" of code so that they can be called by many other related modules reduces application and off-the-shelf library size, but it takes a great deal of forethought to make "re-usable" code save time and money. Programmers say Objective-C helps them save development time, and they like working with it.

I'm sure you realize that, like other employees, programmers will code in pretty much any language they're told to use, if they know it. Doing it in a language you like helps immeasurably. The "synergy" is speed, accuracy and understanding. Putting hundreds of modules so coded into an "application" is easier when more people in the project know how each part works. A ten percent improvement in efficiency in the "assembly" stage might save fifty percent in debugging time down the pike.

Many C Languages

How does Objective-C relate to other "brands" of programming languages you may have read about?

Of the many languages "out there", C and C++ are by far the dominant language in programming for commercial desktop computers and workstations. C languages look more obtuse to the beginner, because they "read" more closely to the machine code into which they are eventually compiled, than, say, COBOL or Basic.

Perhaps partly for that reason, it is usually easier to write C code which "executes" rapidly once it is compiled into object code which the CPU can process directly.

C++ is a superset of the parent C language, organized into a real-world Object Oriented Programming environment. C++ "objects" can be buttons, fields, windows or other things you can see on your screen, but they can also be any other "data type" or family of types. Once written, they can be redefined or "re-used" almost indefinitely. C++ represents an extra learning curve for the C programmer, but it is much better suited for large or huge programming projects.

As a beginning C++ student I was (and still am) somewhat intimidated by the labyrinth of "inherited" code "class" properties. Rather than re-write a paragraph of code for a slightly different implementation or "instance", you define "classes" of code and redefine its "subclasses". A "Chevrolet" becomes an subclass of the class "BodyByFisher", which in turn could be a member of the "PassengerCar" superclass. Chevvy "inherits" the properties of BodyByFisher, which in turn "inherited" its properties from PassengerCar. Neat.

But what if some yo-yo originally defined "PassengerCar" as a subclass of a pre-existing "FordTruck"? Could it be easier to just write your own version of "Chevrolet", so you don't get sideswiped by a Chevvy that's lugging around an invisible tailgate?

Java is a subset of C++ which retains the "inheritance" concepts of reusable code. Java is very much the darling of the Internet nowadays because it will run on any machine (which is not exactly true, as we shall see), and whatever syntax and structure limitations it may have are compensated for with a rapidly growing cross-platform library of off-the-shelf classes and functions or "methods".

Objective-C seems to fall somewhere between C and C++ in complexity, and it has been popular for years in client in-house programming departments because it is easy to work with, the re-usable modules are easy to warehouse and redefine, and, like C++, it is "powerful" enough to easily support any size project.

Anyone who has worked with very large libraries of code knows how frustrating it is to discover several almost identical versions of the same module. Is one "broken"? Which ones can I use? Which should I use? Can we delete one or two as redundant? That's why programming departments have moved to "class inheritance" and stricter "migration control" : but how does the programmer keep track of which modules end up with which properties?

The downside of class "inheritance" is the obligation to be intimately familiar with the properties of the data types you are borrowing, even if you have never worked on the code itself. For this and many other reasons, all "large projects" develop a tremendous cost overhead to support library maintenance.

Anything which reduces this overhead improves profits and product lead time.

Objective-C is more like Java in its "dynamic linking". It is precisely obscure little details like this which cause some programming efforts to founder and sink, while others complete early and make enormous profits for their corporate sponsors, investors, and end-users. This is the kind of detail you don't want to miss.

"Linking" is the binding of code modules together so that they can talk to each other. The "link" permits the program function "call", for example.

Remember, the "source code" is what the programmers work with, like Objective-C, but is not code that computers can directly understand or execute. Some source code can be "interpreted" by precompiled interpreters on the fly (like the HyperCard application itself). The cost is speed, often by a factor of hundreds or thousands of times, but the advantage is that you as programmer or hobbyist can make a change and execute it instantly.

Most source code is "compiled" before it is run, so the "executable" or "object" module is machine code the CPU can process directly. It much is faster to execute, but even a small change means all the modules affected by the change have to be recompiled and "linked" before you can see or test the change.

"Static Linking" is the pre-defining or "hard-wiring" of the connections, at or before compile time.

"Dynamic Linking" is the deferred or generic definition of connections until during execution of compiled modules. It means that changes can be made to a program while it is running. This could be critical in program development and testing, where hundreds or thousands of large or tiny changes must be made before launching a salable product.

I work in QA in a rapidly growing COBOL mainframe environment. One of my responsibilities is to assist in recompiling and relinking the tens of thousands of little changes we make in a single month to millions of lines of code. We do static linking, and a big compile-and-link job can run into the wee hours of the morning. We can't test a change until it's recompiled and re-linked, which often means: the next day.

We're under considerable pressure to shift gears to dynamic linking. The man-hours we could have saved with dynamic linking could easily have bought the time for the next phase of development testing, due, as always, yesterday.

You should be able to see that dynamic linking can make the difference between a day early and a day late in the development cycle. Anyone in Sales can tell you a day late is usually a dollar short.

No wonder developers who have tried NextStep and Objective-C like it. It makes Programming effortlessly more responsive to Sales and Marketing efforts to transform vaporware into bankable deliverables.

When you consider how much market-driven change occurs in a product design from conception to the retailers' shelves, you'll appreciate how much of a competitive edge dynamic linking could be.

The more you understand the world of corporate programming, the more "NewOS" looks insanely great.

Dynamic linking is not a cure-all, but it is an edge. Objective-C is not a cure-all, but it is an edge. Like Java, it is also a popular edge. But languages do not themselves get a product to marketplace.

Design of the code can limit which marketplaces we can access at all.

The last two pieces of programming lore we need to look at in order to evaluate Rhapsody, the new Mac OpenStep programming environment, are API's and porting. Neither concept is exclusive to Objective-C, but both are important to understanding how Rhapsody will run MacOS, NextStep, or Java apps on top of the same Unix kernel. Fortunately, API's and porting are two different approaches to the same problem.

API's for a polyglot of operating systems

OpenStep is the name of the development framework surrounding the NextStep operating system. Rhapsody will be the Apple implementation, which contains both the Mac and Next environments, as well as Java. OpenStep actually supports almost any mainstream programming language, including C, C++, Java, Objective-C and Pascal. But, as a development environment or framework, OpenStep is designed to take advantage of dynamic linking when run with Objective-C coding. No wonder many writers are calling the coming OS "NewOS"!

Java is not an "operating system", by the way. It is just a language, like the others, but the confusion is understandable. Java was the first to talk to many different platforms, like Windows95, NT, Unix, Sun and MacOS, through dedicated machine-code level interpreters called API's.

API's, for example, are what make Netscape work with the same Java code on both a Mac or PC. API's are the "glue" of the Internet. This, and its logical C++ inheritance and module "class" structure, are what make Java way cool. That's also what makes NextStep, for which Objective-C is the development language, way cool. Objective-C is by far the more historically developed language.

"Methods" to extend the reach and power of the new Be OS, and the Java programming language, are just now being invented (both are separate and unrelated developments in the personal computing world). They are robust but undeveloped tools. Only Java boasts ready acceptance across all the major platforms.

API's: "Application Program Interfaces" are black boxes of code which permits your code to talk to any machine, if you have the right API to talk to that machine.

The API's are written to industry interface protocols, so (in theory) you might only need one API to run any Macintosh application on a Pentium. SoftWindows, an emulator which runs Windows on a Mac, is not an API, because it has little more access to the Mac ROM than any other application. A properly engineered API might have hooks into the whole machine, just as does the host OS.

Portability

So, if you write source code for one machine, you write an API for that machine (or interface into somebody else's) -- any machine; your program doesn't care. To port to Windows, your program source code has already been written, and you don't have to rewrite it.

This does no good if you have to write a new API for every program you port to another OS. It only works when many programs can talk to the same API. If the API concept continues to grow in engineering acceptance, Mac Zone and PC Zone can just start calling themselves "Zone". You might be able to buy and run any program you wanted, and not have to care how it was originally written.

The new Mac OS will use API's big-time to host and "unify" its polyglot of program environments. Mac developers could continue to develop for older Macs almost indefinitely, if they wished; they could migrate to OpenStep at a timetable of their own choosing, for once. It will be most interesting to see how Microsoft eventually chooses to develop for this NeXT-generation Mac.

Under API development, your source code remains the same for Mac, Windows, Sun, Unix. If you update or maintenance it, the one set of changes applies to all version releases.

Back in the days of the 512K Mac and the IBM AT, RAM was precious and CPU technology was comparatively limited. Each piece of code had to be hand-crafted to the CPU and fine-tuned to squeeze every ounce of efficiency out of each byte of storage. "Porting" code from one platform to another meant a complete re-write, except perhaps for the core algorithms and their associated logic. It was actually easier to design the code for the chosen platform in the first place.

We've thoroughly discussed "porting" and never even had to define it. You already knew what it meant, even if you didn't know you did!

Of Mousetraps and Men

The developer who really has built a better mousetrap for the Mac no longer has to wait for additional investors to fund a port to Windows. If it's a simple program which doesn't rely on Mac toolbox calls for windows and buttons, we can recompile it right now for Windows with "smart compilers" like Metrowerks. API's will permit intelligent ports of much larger projects to Windows or elsewhere which will take advantage of the existing object resources (like windows and dialog boxes) built into the host environment, so all ports can have the "look and feel" of the host machine.

Early versions of Microsoft Word 6.0 for Macintosh were simply awful until large portions were re-written (at great expense) for the Mac machine. This was a famous example of a "bad port". Microsoft has since invested in a large separate Macintosh programming team. We're very pleased to see such a vote of confidence in Apple's future on Microsoft's part, yet you can see how API's might have helped Microsoft avoid an embarrassing and costly mistake.

The "old" Mac Toolbox gave the world programming concepts which will be with us in the next century. It will "be there" in the Rhapsody release, but it's no longer the only way to do it. API's or not, it's less efficient to make proprietary programming calls if you're aiming to a non-proprietary operating environment. Every Mac programmer comes to respect the Mac Toolbox, but it's still the most dreaded barrier to those Windows programmers who want to come over to the Mac side. It's tough to learn, and one programmer could spend a lifetime programming for it and still not know it all. A shift in dependence is desirable.

Personal computing and workstation software is driven more than ever by the bottom line. It has to be. It's less necessary and less sensible to design code for a single platform, when all your development expenditure may end up being recouped from sales to the second platform.

We didn't discuss hardware considerations, like CRHP, the Common Reference Hardware Platform, which may or may not also emerge next year. If we get it, it may make running of the OS of our choice on the platform of our choice even faster, cheaper and easier, because it addresses commonality of parts and software calls to those parts. But API's, while adding another link in the command chain, reduce our dependency on common parts. As fast as machines have advanced, programming concepts and standardization have again temporarily taken the lead. Whichever way we go, the next few years look really exciting for all of us.

That's the future. Here, as early as next summer. Apple Computer has an edge that could start working in its favor as early as next year. And it may take Microsoft years to gear up for this. Do you feel any different about "NewOS" now?

Given that NewOS is seemingly going to support any C-family language, the only remaining "edge" for Objective-C appears to be that the programmers like it, and it has an inherent advantage over the others in development turnover and lead time.

That's a pretty big edge in a competitive environment where the time span between product announcement and release may only be six months or less.

The bottom line: the fact that Apple bought an OS, development tools and know-how which support Objective-C has to be a programming decision; you can't tell what language an application was written in by running it, and a CPU doesn't care about the origins of the machine code it executes. Programming is perhaps the last great frontier for cheap fast new machines.

You can't build great systems and applications simply by cutting programming payroll costs and hiring temps to hack code (oh, don't they wish?).

Corporations can save payroll while accelerating development by using a language with properties like Objective-C or (sooner than you think), Java.

More importantly for us purists and end users, you can divert talent from the mechanical drudgery of producing millions of lines of code to the more lucrative (and satisfying) business of engineering and crafting high-quality code.

That means better software for us, higher profits at Cupertino, and a new and higher level of programming standards which spin off to tangible benefits for all of us.

If you were thinking of learning C, or investing in a company which can stay on top of programming, it would be hard to think of a more exciting time to do so since the rollout of the first Mac in 1984.

References

I'm indebted to writer Dave Mark for his article "A First Look At Objective-C" (©1997 in the April MacTech magazine, http://www.mactech.com/). It was the first in-depth look that I saw of this special variant of the C language. As with the Dave Mark C textbooks, a number of pieces suddenly fell into place. To conclude with a quote from his introduction, "Things are about to get very interesting".

	MacTech magazine
	Dave Mark Web Site
	MacUser Magazine
	MacWorld magazine

This document was originally written in Tex-Edit by Tom Bender, edited and formatted in Microsoft Word 6.01a for Macintosh, and exported to HTML using Word InterNet Assistant 2.0z. Final HTML-setting was done in BBEdit 4.0. PageMill 3.0 on Win95 is now used for editing, page construction and site management.

©1997 by Alex Forbes and Talking Crow Productions.