Actor column for JOOP Column 4 (Jan. / Feb. 1990) Zack Urlocker Breaking Technical Barriers in the 1990s "Never make predictions, especially about the future." --Samual Goldwyn Despite Samual Goldwyn's words of wisdom, the role object- oriented programming will play in the 1990s is interesting to ponder. Significant trends in the areas of hardware evolution, graphical environments and the adoption of OOP can give us insight into what object-oriented programming will be like in the future. In this column, I'll examine these trends and provide an overview of some of The Whitewater Group's plans for OOP in 1990 and beyond. In future columns, I'll provide a more detailed look at the technologies that will bring object-oriented programming to a new level of maturity. Setting the Stage As we enter the 1990s, it's worth examining some of the general trends in computing as related to object-oriented programming. Ever-improving hardware Hardware continues to increase in performance and memory capacity every year. The newly shipping 80486-based microcomputers are outperforming last year's 80386 machines. As the clock speed of the 80486 increases, we're likely to see performance rise to 20 million instructions per second (MIPS). To put that in perspective, the IBM AT performs at about 1 MIPS. RISC-based chips such as Motorola's 88000 and Sun's SPARC chip are also pushing the envelope in terms of both performance and price/performance. Since these processors have built-in support for floating point operations and memory cache control, they are likely to be more cost effective than similarly configured 80386 or 68030 machines. These developments have significant ramifications for software developers. Much like the way work can expand to take up all free time, there seems to be a law of software entropy that says software expands to use all available hardware. It is the improvements in hardware that permit us to create better, more sophisticated software. As an example, many believe that Microsoft's OS/2 operating system will achieve widespread acceptance only when there is a version that takes full advantage of the thirty-two bit capabilities of the 80386 and 80486. The increase in hardware and operating system capacities means we're likely to see a comparable increase in the complexity and scope of the software applications we create. If debugging in C seems difficult now, imagine what it will be like if the program is not 640K in size, but 6.4 megabytes. Since object-oriented languages are more effective in reducing complexity than procedural languages, we're likely to see greater usage as hardware capacity expands. Increasing acceptance of GUIs Although graphical user interfaces (GUIs) have been around for quite some time, there has been a tremendous growth in the past year. For example, Microsoft reports retail sales of its Windows product to be around 70,000 units a month. Some of the growth in GUIs is certainly due to improved performance on faster hardware. As the number of applications for a particular environment increases, so does interest among end-users. As the installed base grows, so does the attractiveness of the environment for applications developers. Although there is a certain circular logic to the growth of a graphical environment, both Microsoft Windows and the Macintosh have been successful because of it. Other environments, such as Digital Research's GEM and the Amiga's Intuition, which may have been arguably better, have been unable to break through this "chicken and egg" situation. And of course, the verdict is still out on OS/2 Presentation Manager, the NeXT machine and the Unix environments, Open Look and Motif. The significance for application developers is that non-standard user-interfaces, no matter how good they might be, will not obtain market acceptance. And certainly the days of treating the user-interface as a last-minute detail are gone forever. Since programming for a graphical environment with a procedural language is so complex, its not surprising that we've seen the adoption of object-oriented languages for these environments. There's Actor for Windows, Object-Pascal for the Macintosh, and more recently Objective-C for the NeXT machine and Smalltalk/V for Presentation Manager. Object-oriented programming may be the only feasible way for most programmers to develop for graphical environments. OOP is entering the mainstream With all of the conferences, magazine cover stories and publicity surrounding object-oriented programming in the past year, it is apparant that OOP is entering the mainstream. Object-oriented programming has emerged from the labs and is now being used for real-world applications. As a result, some of the criteria used to evaluate object- oriented programming is changing. Production users are less interested in the theoretical purity of object-oriented concepts and more interested in their practical application. The need for object-oriented programming to fit in with existing, as well as new, standards will also increase in importance. Applications developers using object-oriented languages need access to existing code libraries, compatibility with standard operating systems and environments, and fast performance. They won't sacrifice any of these capabilities no matter how they might compromise the object-oriented model. Actor 2.0 The Whitewater Group has taken these trends into account in our plans for Actor 2.0 and beyond. Use of memory, compatibility with C, language features and class libraries have been improved in Actor 2.0 without sacrificing compatibility with previous versions. Although it took some pretty amazing heroics on the part of Chuck Duff to shoehorn Actor into a 640K IBM XT running Windows 1.0 back in 1986, we've been bumping into MS-DOS's 640K barrier ever since. Actor and Windows have improved their memory efficiency with every release. Actor 2.0 represents our most significant memory improvement by using an automatic memory swapping kernel. The kernel is able to swap unused portions of code and static objects out to disk effectively breaking the 640K barrier of MS- DOS. The swapping kernel uses a deterministic least recently used (LRU) algorithm to provide swapping on an object-by-object basis. This results in better performance than a page-swapping system because object-oriented languages don't exhibit the same locality of reference typical of procedural languages. Large Actor applications can typically run in one-fourth of the static memory as previous versions of Actor with little effect on performance. By freeing up static memory, Actor applications are better able to make use of the increased memory of high-end machines. Actor has always provided support for dynamic linking to programs written in C and other procedural languages. We've taken this even further in Actor 2.0 by providing additional support for C structures, callback functions and user-defined primitives. The CStruct class enables a program to pass C-like data structures directly when calling external routines. The CStruct class supports nested structures as well as user-defined C types, making it easier use existing libraries. CStruct objects contain binary data and a dictionary of fields and field information. A dictionary class, CTypes, is used to keep track of user defined types as well as input and output conversion routines. This makes it easy to define the C types and have conversion take place automatically whenever the CStruct object is referenced. Many of our users have requested ways of extending Actor's primitive methods. Users can now write their own primitives, in C or assembler, to access special hardware features or to optimize critical portions of their code. CStructs and user-defined primitives may cause object-oriented purists to shudder, but we recognize that it was necessary to provide professional programmers with an escape mechanism they could use for compatibility or performance reasons. Although I chose Actor to demonstrate how industry trends have affected software development, the same holds true for other object-oriented languages as OOP heads into the 1990s. Portability Across Environments We purposefully designed Actor to hide many of the details of programming for Windows. This has become an important part of our strategy to support other graphical environments also. Our goal is to provide an Actor development environment that provides complete portability of Actor applications across all standard GUIs. Work is underway to support future versions of Windows as well as OS/2 Presentation Manager. Future versions of Actor will be based on a common kernel that will allow more objects through the use of thirty-two bit pointers. Since the kernel itself will be portable, we will be able to port Actor to other popular windowing environments also. Of course, the kernel is only part of the job in providing portability across environments. Windows, Presentation Manager and other graphical environments all have different models of the graphical environment, not to mention completely different application programming interfaces. To overcome these differences, we've created a library of portable graphics extensions. You can think of these extensions as a MacDraw-like toolkit for programmers. In effect, you have graphical objects for dealing with coordinate systems, fonts, text, shapes, pens, brushes, bitmaps and so on. This allows you to create applications that take advantage of the richness of the environment without having to write direct calls to the graphics engine. There are three types of graphical objects that we've defined: rendering tools, platform encapsulators, and drawables. Rendering tools are objects such as brushes, pens, textpens and graph spaces which control the appearance of graphical objects. Platform encapsulators are used to factor out all of the environment-specific details. These include objects for dealing with colors and physical ports. Drawables consist of graphical objects that can be rendered onto ports such as labels, icons, shapes, bitmaps, regions, curves, polylines and so on. Since the platform encapsulators are the only classes that are environment specific, they area all that is need be rewritten to port the graphics extensions to a new platform. The platform encapsulators make extensive use of the underlying graphics engine for speed, and, where necessary, include additional code to make up for deficiencies in the environment. Through the judicious use of early-binding and assembly language primitives, we've been able to achieve high-level portable graphics without any significant performance degradation. One of the applications that we've developed to test the graphics extensions is a drawing program similar to MacDraw. The application took only 500 lines of Actor code, or about 1/10th of what it would have been in C. Running on Microsoft Windows, performance is comparable to commercial drawing programs. Although the graphics extensions have been initially implemented for use in Actor, they could also be applicable to other object- oriented languages. Beyond 1990 A portable thirty-two bit kernel and graphics extensions are important strategic developments for Actor in the early 1990s. There will also be additional language improvements and class libraries aimed at reducing application development time and fitting in with emerging standards. We're actively engaged in research in language areas including abstract protocols, typing of late-bound messages, privacy, as well other areas. Many of these projects will result in direct improvements in future versions of Actor. The Whitewater Group has joined AT&T, Borland, Hewlett-Packard, Data General and other members of the Object Management Group to help create object management standards. We expect that richer graphical environments and operating system support for objects will broaden the scope of object-oriented software development. Hewlett-Packard's NewWave environment gives us a glimpse of what operating environments will be like in the future. Once object management becomes an operating system service, languages will no longer have to duplicate these facilities. This will make inter-language sharing of objects feasible. When programmers are able to make use of objects from Actor, C++ and Smalltalk, as appropriate, we will see a rapid surge in the number and quality of class libraries available. At that point the economics of software development will change dramatically. Software development costs will be considered as capital expenditures subject to classic "make or buy" decision criteria. I'm certainly not predicting that programming will disappear. However, we're likely to see two distinct types of programmers: builders and reusers. The first group will concentrate on creating generic reusable components; the second group will customize those components and create applications. Because of the greater cost of creating generic reusable components, I suspect that much of this development will be done outside of today's MIS departments by new entrepreneurial companies. Beginning in the early 1990s desktop multimedia machines that incorporate high resolution graphics, interactive video and sound will become available. Initially, applications for these environments may be written in C, but again, the economics of object-oriented programming will result in the ability to create richer applications in a shorter period of time. More importantly, however, object-oriented programmers will be building up toolkits of objects that casual programmers will be able to piece together. As object-oriented environments take off for end-users, they will also be used by software developers. Admittedly, we're often like cobblers whose children go barefoot, so there will probably be a time lag here. I think we'll see an order of magnitude change so that programming environments of the mid-1990s will resemble end-user applications more than they will even today's most sophisticated development environments. Programming languages will become a less significant portion of the overall software development lifecycle. CASE tools and visual representations of programs are likely to become more important in the future, particularly as we deal with richer class libraries. I doubt that visual programming will bear much resemblance to today's programming languages, but for at least a decade or more, the two technologies will coexist. When predicting the future, it's always easiest to speak in generalities as I've done here. In future columns I will expand on some of the technologies I've mentioned and examine their importance in taking object-oriented programming forward into the 1990s. About the author Zack Urlocker is manager of developer relations at The Whitewater Group, the creators of Actor, an object-oriented language for Microsoft Windows. Mr. Urlocker has taught object-oriented programming to hundreds of professionals and has written articles for several computer magazines and journals. Breaking Technical Barriers in the 1990s page 6