Power-Programmierung/CD1.mdf/actor/tutorial/tutr5.txt

Text File | 1990-10-18 | 18KB | 332 lines

       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