Tribune: C. Pfister, Bridging the Gap between Power and Simplicity 
Author Message
 Tribune: C. Pfister, Bridging the Gap between Power and Simplicity

The following article did appear in the first issue of the Oberon Tribune.
The Oberon Tribune is the Oberon/F technical newsletter and appears twice a
year. For a subscription of the Oberon Tribune you can join the Oberon
Developer Forum. Please look at the order form for further information.

Bridging the Gap between Power and Simplicity
Dr. Cuno Pfister, Oberon microsystems, Inc., Switzerland

Object-oriented programming to the rescue!

Graphical user interfaces (GUIs) have been introduced over a decade ago. We
increasingly take them for granted, not only for standard software like word
processors or page layout software, but more and more also for low-volume
custom software. Applications range from engineering to banking, from
telecommunications to medical software. There is strong pressure to develop
new software from the outset with GUIs, or to re-engineer existing software
to work with GUIs.

As soon as the tremendous complexity associated with the development of GUI
applications became apparent, people started looking into ways to master this
new level of complexity. As a result, it is now commonly agreed upon that
object-oriented programming (OOP) is a suitable way to structure complex
software, in order to keep it maintainable.

Alas, object-orientation is only a first step

Experience with large object-oriented software systems is still scarce, yet
we can already see that while OOP may be necessary, it certainly is not
sufficient. On the contrary, mastering OOP is a challenging task in itself.
This not only applies to learning a very complex programming language such as
C++, but also to the design process: how should a problem be decomposed into
subproblems, and how are these problems translated into suitable object
abstractions. The latter issue has been addressed by various object-oriented
design methods. To support such design methods, computer-aided software
engineering (CASE) tools were developed. The scope of such tools range from
mere docuDmentation aids to source code generators. A source code generator
basically is a preprocessor for a (possibly graphical) higher-level OOP

Today we can observe a growing disappointment in such tools. It seems like
the choice is either between powerful but complex low-level programming
languages, or simple but limited high-level languages and tools.

Frameworks to harness object-orientation

All is not yet lost, however. On the one hand, there are simpler
general-purpose OOP languages such as Oberon. On the other hand, design
decisions made by experienced designers can be reused in the form of
frameworks. Frameworks are extensible class libraries which define a generic
way to address problems in a given problem domain. Such a problem domain may
be e.g. "graphical user interfaces", "file systems", or "order processing". A
framework defines a prebuilt structure, ready for use in a particular
instance of the problem. Ideally, a framework extension only deals with the
aspects of a problem which are unique, while the framework handles the
aspects which are generic. A framework not only provides code reuse, but more
importantly also design reuse.

Thus frameworks combine the flexibility of general-purpose OOP languages with
the expertise of top-notch domain specialists and framework designers. We
could even regard a framework as a special-purpose OOP design method with
software support.

Did we solve the problem, or just create a bigger one?

Application frameworks have been around for several years now. Not
surprisingly, the first problem domain that they addressed has been the
handling of standard user interface elements in GUIs, like windows, menus,
and dialogs. However, these frameworks have only added to the underlying
operating systems, not shielded from them. Thus a developer now is faced with
the formidable task of learning a huge operating system API, a complex
programming language, and a comprehensive framework in addition. We now may
have a way to structure complex software, in a way which allows to reuse
design and code; but can we afford it? Can you justify to send your best
programmers (don't even consider the other ones) a year or so into training?

Has object-orientation failed?

The relatively minor training costs have been a major reason for the
phenomenal success of Microsoft's Visual Basic. This simple product showed
that a language which isn't object-oriented at all and not nearly has the
power of, say, Pascal, can run rings around much more powerful true
object-oriented approaches.

Besides simplicity and the marketing muscle of Microsoft, there was another
major reason for the success of Visual Basic, namely dynamic extensibility:
new controls can be developed by third parties, and they can be combined
arbitrarily to form advanced user interfaces. Dynamic extensibility is
something that has largely been neglected in traditional OOP circles. In most
OOP systems, "extensions" still need to be linked together statically, into
one monolithic application (thus the term "application framework").

While object-orientation has steadily garnered more support over the years,
componentware such as Visual Basic has delivered much of the productivity
gains that were originally expected from genuine OOP, and at much lower cost.

Object-orientation in disguise

If we look at it closely, we can see that componentware uses object-oriented
principles as well, even if no OOP language is involved: Visual Basic defines
a control's interface (abstract class), a control implementation is only
known to its developer (information hiding), the Visual Basic core invokes
the control's code (late binding), and arbitrary controls may be combined in
a form (polymorphism). But these aspects are hidden in the Visual Basic
"black-box". Thus, componentware can be regarded as OOP in disguise. It is
ironic that instead of traditional OOP, which is only concerned with OOP as a
structuring technique, it is componentware which realizes the true benefit of
OOP, namely dynamically interoperable components. When needed (and only
then), components are linked, loaded, and integrated at run-time into a
working software system. What's the Achilles heel of a product like Visual
Basic? While its language is simple, it is also very limited: you can't even
implement a new control class in it. So here we are again: either we have a
simple but limited language for using controls, i.e. to write scripts/macros,
or a powerful but complex language for implementing controls, such as C++.

Component frameworks to combine the best of both worlds

The question arises whether true OOP (e.g. frameworks) can be combined with
componentware. In fact, this is the case. It requires a new breed of
frameworks though: instead of traditional application frameworks (to be
linked statically) we need component frameworks (to be linked dynamically
upon loading) designed from the ground up with components in mind. Oberon/F
is the first of its kind, others will follow (e.g. Apple's C++-based OpenDoc
Development Framework ODF is expected as a product sometime next year).

Reconciling power and simplicity

However, the most important design goal for Oberon/F was to strike a balance
between power and simplicity. It is not acceptable to start a non-trivial
programming task with a simple scripting language, because its power and
performance limits will soon be reached. When this happens, there is no easy
and inexpensive upgrade path to a more powerful tool. Scripting languages
don't scale up to large problems. C++ on the other hand doesn't scale down to
smaller problems.

As a consequence, many developers have resigned to living in two worlds at
the same time: one reserved for "real programmers" with years of experience
and training, and another one limited to small-scale projects.

However, the language Oberon has shown that a very small and simple language
can be used to implement anything from small scripts (called "commands" in
Oberon) to entire operating systems. Moreover, Oberon also combines safety
(strong typing, garbage collection) with efficiency (compiled code), both of
which are important for large or mission-critical projects.

Oberon/F as a component framework was designed in the same spirit as the
language, and fully exploits its capabilities (dynamic linking of modules,
garbage collection, commands, run-time type information, etc) while trying to
minimize the number and complexity of its programming interfaces. It was
designed to make component programming easy, and to allow a painless
migration to OLE and OpenDoc later. And of course, traditional linked
("double-clickable") applications can be produced as well, as long as this is
still desired.

(C) 1995, Oberon microsystems, Inc., Switzerland, all rights reserved.

Sat, 28 Feb 1998 03:00:00 GMT  
 [ 1 post ] 

 Relevant Pages 

1. Technology can't bridge Seattle's educational gaps

2. School tries to bridge techno-gender gap

3. School tries to bridge techno-gender gap

4. to CS: or not to CS: in F-PC assembler

5. Re : Mycrofts question about Oberon Tribune

6. Tribune #2

7. Tribune: N. Wirth, Effective Technology Transfer

8. Tribune: B. Fitie, Component Software and Oberon

9. Power Basic CC vs Power Basic for DOS

10. OOPSLA'99 VM Workshop: Simplicity, Performance and Portability in Virtual Machine Design

11. Simplicity


Powered by phpBB® Forum Software