home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Shareware Overload
/
ShartewareOverload.cdr
/
windows
/
actortut.zip
/
TUTR5.TXT
< prev
Wrap
Text File
|
1990-10-19
|
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