When it's time to build steamships, everybody builds steamships -- or so the chestnut goes. It must be steamship time, then, because lately I've been dodging them left and right.
The steamships in question are Object-Oriented Programming systems (OOPs). That acronym may be the most unfortunate or perhaps the most deliciously ironic one ever used in our industry. Laugh if you must (I do, regularly) but OOPs are coming of age, and you owe it to yourself to spend a little time in understanding them.
In a handful of words, object oriented programming is the next generation of structured methods -- code has married data, and the offspring are Something Else Entirely. In keeping with the mission of "Structured Programming," my next several columns will be devoted to object-oriented languages, with an emphasis on how you can get involved.
I first heard the steamship whistles last year at Software Development '88, a show devoted utterly to (hallelujah!) programmers and their craft. There wasn't much in the line of products on the show floor, but the OOPs sessions were SRO. I knew what OOPs were, having worked at Xerox through most of the time that PARC's seminal OOPs research was going on. I programmed in Smalltalk on an Alto workstation in 1979, an experience that led me to write OOPs off as costing more in machine performance than it was worth. I was dead wrong there, having shot the marathon runner for riding his little brother's tricycle.
At Software Development '89, I saw real OOPs code steaming along at flank speed. The code was written in a variant of (arrgh) C, but the point was not lost on me: Taken together, object-oriented methods are a way of thinking about programming that are tied to no particular language. With minimal syntactic extension, any language at all can be object-oriented ...
... as we're beginning to find out.
Object orientation is extremely difficult to define. Most people don't try to define it; they simply start by saying, "Object-oriented programming allows you to create easily reusable software components ..." or "Object-oriented programming allows you to extend existing modules without requiring source code ...," or something else. This isn't explaining what object-oriented programming is, this only tells you what it does -- and only part of what it does, at that.
Let me be glib and hand you my own definition, which (like most very high-level definitions) needs some expounding: Object-oriented programming is structured structured programming. It's the second derivative of software development, the Grand Unifying Theory of program structure. Choose your metaphor, I got a million of 'em. What you must understand is that object orientation is no single technique, no single language, and no single approach. It is many techniques bound together in synergistic fashion to produce numerous benefits, under the guidance of a very high-level mindset that Mike Swaine would call a paradigm shift.
For this reason, it's a little scary, and as with all scary things like sex, death, or steam locomotives there's a tendency to make it all mystical and legendary. Resist -- and relax. Rather than a fount of mystical wisdom, object-oriented techniques are more like modern sanitation: A way of living that combines numerous small elements -- indoor plumbing, running water, regular bathing, washing of food, refrigeration, childhood inoculation, and so forth -- into an easy regimen that has nearly doubled the human lifespan in the last hundred years. That's not immortality, but it's a helluva step in the right direction.
Which is how one should feel about OOP: Not instantaneous bug-free programming, but still a helluva step in the right direction. Over the next several columns I'll be gradually defining object-oriented programming, and showing the tools you can use to learn it and benefit from it. I'll have to beg your patience -- the subject is such that you won't catch the essence in 200 words or less. There is no single good place to begin, so let's catch the first steamship that happens by.
I throw regular parties down here, and I exhort the invitees to bring wives, husbands, or Significant Others. Bruce Webster took me at my word about a month ago. He has a perfectly wonderful wife, but instead he brought his current Significant Other: A NeXT workstation.
So significant was NeXT that the party goers forgot all about the pool, the hot tub, and even my copy of Tetris. What might have been an academic curiosity or (my own view) a dazzling way to waste several hundred million dollars has been turned into a killer product by the simple decision to market the unit to ordinary people, through the Businessland retail chain. $10,000 may seem like a lot of money, but most new cars cost more than that, and if you're a front-line knowledge worker, your machine may mean far more to your bottom line than your car.
But I'll leave that decision to you. NeXT interests me because its operating environment is object-oriented, from top to bottom. Some say jobs was fishing for publicity and hooking into a fad when he made NeXT an object-oriented machine. No way -- Jobs used OOP techniques because he simply had no choice. It was that or drown in complexity.
Which brings me to the #1 raison d'etre for OOPs: The management of complexity. Some of you may well have tried developing for the Mac. Fewer of you (I suspect) have taken a stab at Windows development, and almost no one in the civilized galaxy has bothered to crack the OS/2 Presentation Manager documentation.
The problem in all cases is the complexity of the API. DOS presents us with a few dozen function calls, most of them independent and taking at best three or four parameters. Full-blown operating environments like the Mac, Windows, or PM contain hundreds of function calls, many of them needing a dozen or more parameters that interlock with other function calls and other parameters in ways that make your head spin. It is the nature of the human mind to focus on one or two things at once. (Close your eyes and try to clearly imagine a field of more than four abstract items and see how easy it is.) Developing for one of the operating environments requires that you float that whole interlocking mess in front of your mind from the word go.
A couple of years ago, Apple produced an object-oriented wrapper for the Mac API called MacApp. It imposed a structure on the Mac API by identifying the elements of the interactive environment as quasi-independent components. Windows, menus, scroll bars, buttons, all of these were set out in a hierarchy looking a lot like a taxonomy chart. Each type of element was called a class, and to create and use a window, you simply created an instance of the window class. This window instance was an object, and it contained an interface to only that code and data needed to create and use a window. You might think of objects as halfway between code and data, or as a larger concept that embraces both code and data. But never forget that code and data must be considered together in OOPs, and nevermore put asunder.
I've drawn up a simple object hierarchy chart in Figure 1. It's not intended to represent MacApp specifically, but could apply to nearly any windowing environment. Each of the boxes represents an object type or class. Each class has a specific role in life, which I've written near each box. The Screen type is a full screen, and models the relationship between an abstract display and the real physical display controller board. If you send a character to a Screen object, it will pass those characters along to the display controller. That's about all Screen can do.
Window adds a little pizzazz to Screen by being a rectangular chunk of the screen, perhaps with a border. A Window has a size and a position within a Screen, and may be dragged around the screen with the mouse or cursor pad, and enlarged or reduced in size. That's about all that a Window object can do.
Note, however, that if you send characters to Window, it will pass them onto the display controller. It does this using the same mechanisms built into type Screen. Window inherits everything that Screen is, by virtue of being beneath Screen in the object hierarchy.
Beneath Window are two different classes: Field and Menu. A Field has the power to display and edit a value of some kind. A Menu displays several items and chooses one from the group. Field and Menu are distinct from one another, but they inherit everything that both Screen and Window have within them: Both menus and fields have a size and a position and can be dragged around the screen, and both send characters to the display controller.
At each level in the chart, the objects get a little more powerful, a little more specific -- and a little more useful. Beneath Menu are two real varieties of menu, PopUp and Matrix. Both inherit the essence of a menu -- to display several items, then accept input from the user to choose one of those items -- but each does the actual work in its own way.
The huge mass of detail of a windowing environment API is distributed across the hierarchy in a rational, graspable manner. Direct control of the display hardware is gathered behind class Screen. Sizing and dragging of windows is gathered behind class Window and so on.
In short, to use a pop-up menu object in this scheme, you narrow your attention to one item, a software model of a real menu that draws together all the disparate function calls and data items that you would otherwise have to hunt up and pull together on your own from that mess of an API. I should point out that there are other ways to simplify an API, but object-orientation provides additional benefits related to the inheritance concept that I will touch on in future columns.
There's a lot more to both MacApp and object-oriented programming than just this, of course. Managing complexity is a major benefit of OOPs, but not the only one, and inheritance is one mechanism within OOPs, but again, there are more. If you want to know more from a Macintosh perspective, get the superb Object-Oriented Programming for the Macintosh, by Kurt J. Schmucker (Hayden Books, 1986.) The point I'm making is that objects are one way of managing complexity by hiding details behind a software model that relates to the problem at hand and no more. The hierarchy of MacApp allows a programmer to see only what he needs to see at any given time in the development process without tripping over unrelated details. It was Mr. Structure himself, Niklaus Wirth, who defined structured programming as the artful hiding of details. Object-oriented programming is a world-class method of hiding unnecessary details, and it's about as artful as they come.
Which is fortunate, because the Presentation Manager API makes the Macintosh look elegant and obvious by comparison. We may never really know how difficult the NeXT machine would be to program in the absence of an OOPs, because the operating system is the OOPs, and what structure MacApp imposes on the underlying Mac API, Next Step imposes on itself. All the components of the operating system and the elegantly-designed (and monochrome, hurrah!) user interface are objects.
NextStep incorporates a new language called Objective C. Objective C represents an opinion watershed for me -- allowing me to believe that, by gully, this object stuff may civilize C yet. Still, this is the un-C column, and I'll leave it to my cohorts here to fill you in on the details of both Objective C and NextStep. To get a flavor for Objective C and OOPs at the same time, read Object-Oriented Programming: An Evolutionary Approach by Brad Cox. Cox defined Objective C, and he has an intriguing metaphor for objects: Software IC's, plugable modules that may be considered "black boxes" and used without alteration in many diverse applications. This is an important facet of any OOPs, but by no means the only or even the most important one.
The point to carry away from the NeXT steamship is this: By the artful hiding of details, NextStep makes the NeXT API much easier to grasp and manipulate than Mac, Windows, or PM. The component-modelling nature of OOP makes such detail hiding easy. If the OOPs paradigm shift does nothing else, it will have earned its keep for that alone.
Neither Windows nor PM have anything resembling MacApp yet ... or do they? I have fielded some tantalizing rumors indicating that Microsoft is about to go head-to-head with Borland with an environment-based Pascal compiler.
If it's true, it will be an intriguing mix: An object-oriented Turbo Pascal compatible Pascal compiler that (gasp) generates Windows applications.
Back in my PC Tech Journal days I told Microsoft that Windows would not hit the big time until there were a development environment for it that intelligently managed the complexity of the API. That advice sank like a stone, as did my editorship at PC Tech Journal, as eventually did PC Tech Journal itself. In the intervening years we've seen a handful of solid applications appear for Windows -- and handfuls are emphatically not the big time. The Windows API is daunting, and the Windows Software Development Toolkit (SDK) is chaotic. Something needs to bring order to the Windows and PM APIs, and it would be just too deliciously ironic if Microsoft, the C-Is-The-Only-Way-To-Go (except maybe for Basic) company decided to use a Pascal compiler to do the job.
By the time you read this, we should know the truth.
By the time I heard the Microsoft rumor, the steamships were already getting pretty thick around here. Then another mast heaved over the horizon, with Philippe Kahn tooting the whistle. This one is for real: In May Borland released Turbo Pascal 5.5, with new technology making Turbo Pascal fully object-oriented in some interesting and innovative ways.
Contrary to conventional wisdom, it doesn't take a whole new and exotic language specification to support object-oriented programming. Borland did it by adding only four new reserved words to Turbo Pascal: OBJECT, VIRTUAL, CONSTRUCTOR, and DESTRUCTOR. If your existing source code does not use those four reserved words, all object-oriented extensions will be completely transparent to you. You can use objects or ignore them; it's your choice. (If you ignore them, however, you're nuts.)
There is no genuine standard for object-oriented Pascal, so Borland drew on numerous existing languages: C++, Macintosh Object Pascal, and Oberon, the latest language concocted by Niklaus Wirth. Unlike C++, the object extensions are not a separate module or some sort of preprocessor. And unlike the older OOPs like Smalltalk and Actor, you can choose the degree to which a program will be object-oriented. In Turbo fashion there are mainstream objects and optimized objects, and you the programmer get to decide which sort of object is the best for a given application.
Welding code to data presents some novel problems in debugging, so Turbo Debugger was upgraded simultaneously, with new inspectors built in specifically to poke around inside objects. One nice touch is a hierarchy inspector, which shows a little taxonomy chart of all object types present in the module being debugged.
I haven't had enough time yet to write any significant code in object-style Turbo Pascal, but what I've seen so far is clean to the point of being elegant. I'll be spending a lot more time on Turbo Pascal objects in future columns. Right now, I'd say, Upgrade. Without hesitation.
With all the steamships steaming into shore, it's easy enough to ignore the ones that have been at the dock for some time. Apart from Zortech C++ (which I'll let the C folks discuss) there are two longstanding reasonably priced OOPs for DOS: Smalltalk/V and Actor. Both have been around since '85 or '86, and I have been using both off and on since that time. Both are solid products, well-documented, and a lot of fun.
Smalltalk/V, at $100, is the cheapest OOPs you can buy right now, and if you have a disposable $100 it's one of the best ways to get comfortable with the concepts of object-oriented programming. The reasons are two: Smalltalk is totally object-oriented, in a way that permeates every corner of the language. If you understand Smalltalk, you have OOPs in your hip pocket. Also, Smalltalk is certainly the best documented OOPs in history, due to a superb line of books from Addison-Wesley that came out of Xerox in the early 1980s. Digitalk's own documentation is excellent, and with the Addison-Wesley books you have everything you need.
Space is short, so I'll leave Smalltalk for the time being. My next column will focus on Smalltalk, and I'll provide the whole list of Smalltalk titles, along with information on the various versions of Smalltalk on the market right now.
Actor is a bit of a nonesuch. I've often felt that the old saw "Pioneers get arrows" applies with considerable force to The Whitewater Group. They had the vision to provide an easy-to-use development environment for Microsoft Windows back in 1986, while Microsoft still forces developers to slog through the swamp of their intolerable SDK. Yet for all that, Actor hasn't taken over the Windows world as I was sure it would two years ago.
Unlike Smalltalk (with which it is often unfairly compared) Actor creates stand-alone programs that do not require the presence of the Actor product to execute. (All generated programs, however, are WinApps and require Microsoft Windows.) The code is fast, the manual is very good, and aftermarket books are beginning to appear. I've seen the manuscript for Object-Oriented Programming With Actor by Marty Franz, and it will be well worth its cover price both as a tutorial for Actor users and as a preview for those who want to see what the language is like before they buy the product. Expect the book to appear in October.
Apart from being the only rational development environment Windows has ever had, much of Actor's value lies in the object hierarchy they give you, out of the box, for managing Windows complexity. The leverage of the package has to be experienced to be believed. You really can write a text editor window in two Actor statements, just as their ads say, because Whitewater has already created the text editor class. All you need to do is create an instance variable of that class, and you have a text editor window. Like so:
If you need to gussy up the text editor window a little, you don't have to start from scratch. You just hang a new class beneath the editor window class on the hierarchy, and add what needs adding. Inheritance allows your new editor class to be everything Whitewater's canned editor class is, with your own custom extensions melted seamlessly in.
Actor V1.2 The Whitewater Group 906 University Place Evanston, IL 60201 $495.00
Object-Oriented Programming For The Macintosh by Kurt J. Schmucker Hayden Books, 1986 ISBN 0-8104-6565-5 607pp. $34.95
Object-Oriented Programming With Actor by Marty Franz Scott, Foresman & Co., 1989 ISBN 0-673-38641-4 $24.95
Smalltalk/V Digitalk, Inc. 9841 Airport Blvd. Los Angeles, CA 90045 213-645-1082 $99.95
Turbo Pascal V5.5 Borland International 1800 Green Hills Road Scotts Valley, CA 95066 408-438-8400 Standard package: $149.95 Professional package: $250 Upgrade: $34.95 from TP 5.0 $59.95 from Pro Pack 5.0 $75 from TP 4.0
Any user interface component that you might want to put in a Windows application is represented on the Actor object hierarchy. They're like templates: You grab a template off the hierarchy and whack out a new copy of an object for your use. The tangled web of the Windows API is way back there somewhere, so far back you can forget about it and get the real work of writing your application done.
This is amazing stuff. Why then hasn't Actor gotten the recognition it deserves? As much as I like Actor (and in many ways I like it better than Smalltalk, with which I have been acquainted for almost ten years) I see two serious problems: First of all, Actor is a whole new language spec. It's something like Pascal, a little like C, a very little like Forth, and quite a bit like Smalltalk. These are strange bedfellows indeed, and while it's a perfectly reasonable language spec, I have found no compelling reason why it had to be as different as it is from Pascal or C. Life is too short to get really, really good at more than one or two languages, and I think the learning curve has driven away many potential users.
Second, and related to the first problem, is that Actor costs $500. This is cheap if you want to develop for Windows, but if you want to see if a new language spec is worth learning, there's no inexpensive way to try it out short of stealing a copy somewhere. Baskin-Robbins makes those teeny spoons for giving away samples of Garlic Avocado ice cream because most people are not going to spend a buck-fifty on a cone full of stuff that they might or might not want to swallow. If Actor were a WinApp-generating implementation of Pascal or C this would not be the case. Alas, Actor needs a cheap version of itself for the language tire-kickers.
I'll have more to say about Actor in a future column, particularly if rumors of a Windows version of Quick Pascal turn out to be true. If you have any need to develop for Windows, trust me: The $500 price tag is cheap compared to the time and torn hair that you will save over using the SDK. Learning it takes a week or so, but what's learned is learned -- and you will pick up plenty of OOPs savvy along the way for free.
Last night I heard that a friend of mine had kicked off a cold fusion reaction in a pickle jar full of laboratory-purity heavy water. Chemical reaction? Kind of hard when there's only one chemical in the jar. (He washed the dill residue out before using it, trust me.) OK, but is it fusion?
Who knows? But hey, who cares? If more energy is coming out of the jar than is going in, it could be angels on treadmills and it wouldn't matter. If the process is perfectible and scalable, this could be Year One of the Millennium. My swimming pool contains about three gallons of heavy water (all water on Earth, in fact, contains one part in 7000 of heavy water) which would heat my house and run my car for about ten thousand years. Separating ordinary and heavy water can be done with solar energy and requires no exotic materials or equipment and does not involve radioactivity.
The point is this: You don't need Lawrence Livermore Labs to change the world. No sir. You don't need a supercomputer to change the world. Uh-uh. The age of Desktop Physics has returned, after a 70-year hiatus.
No, all you need is a pickle jar, a PC clone, and Turbo Pascal.
Copyright © 1989, Dr. Dobb's JournalThe Steam Whistle Bloweth
Structure of Structures
Catching the NeXT Steamship
Each Object in its Place
Steamship Seen Through Windows, Darkly
Board the SS Turbo!
Already at the Dock
The Pioneers and the Arrows
MyEditor := New(EditWindow, ThePort,"editmenu" "Editor",nil);
Show(MyEditor, 1);
PRODUCTS MENTIONED
Steaming for Home