Summary: Our experience creating custom application software has taught us that total control over our development tools is a necessity. Project Oberon provided an excellent starting point for us to build our own cross-platform application programming environment. Our adaptation of Wirth's compiler is re-targetable at run-time via a small set of installable up-calls, enabling a single machine-specific code-generation module of typically less than a thousand lines of code. The only significant additions to the original Oberon language are floating-point binary-coded decimals and open-array variables with string concatenation (e.g. s := "Error: " + t). Accompanying run-time libraries, written in Oberon, for operating systems such as Microsoft Windows (32-bit) and MS-DOS have been developed. Several systems created using the new tools have been in use by customers for some time.

1. Introduction

We present an industrial application of Niklaus Wirth's and Jiirg Gutknecht's research project [1], the programming language [2] and operating system Oberon, which aims to retain the original's simplicity, clarity and reliability. First the motivation for developing the software is explained, and the occasionally roundabout route which led to it is described in some detail. The particular design aspects of our version of the Oberon compiler and its target run-time environment are summarised, and finally we outline the steps involved in writing a new code generator for a given machine. In publishing these experiences, we hope that others may be encouraged to take Wirth's blunt attitude to 'bells and whistles', and enjoy reliable software as a natural result.

2. Motivation

Providing working software for real customers is in most cases hard work, yet despite warnings [3] the complexity involved continues to be underestimated by the industry's practitioners. Many large, high-profile software projects fail completely - and 'small' software is often unreliable. Critics often contrast this with civil engineering, where (on the whole) bridges do not tend to collapse during construction. Considering that in software we have far more control over the properties of our tools and materials than in other branches of engineering, the phenomenon is all the more surprising.

We reject the argument that computing is still in its infancy and therefore that such failures are only to be expected - consider aviation, where through great effort and the will to create a safety culture, passenger flights were made acceptably safe by the 1930's and fatality rates were improved again by an order of magnitude by the late 1950's.

In our experience, the biggest obstacle to providing finished software is finding the time to write it. Analysing our past projects, which used the complex development tools available commercially, it dawned on us that a frightening proportion of intellectual effort and time was being wasted on installation, configuration and debugging of these tools - we estimated in one extreme case as much as eighty percent of the entire project time.

We feel that it is partly because software offers the freedom to design ridiculously over-featured compilers and other development tools (most of which are far from bug-free) that the complexity of projects can get out of hand. Wrestling with the unpredictable properties of a fault-ridden programmer's tool may be stimulating, but it is distracting, and leaves less of our mental capacity available to solve the problems in the customers' domain.

Creating simple, single-purpose tools is unfashionable because it restricts scope and flexibility; but this can sometimes actually be beneficial, reducing the sheer number of decisions to be made along the way. An example of this is the software running the tiny computer fitted to the Voyager 2 space probe, whose outstandingly successful mission inspired Wirth to begin the original Oberon project [1].

The concept of providing just enough is expounded repeatedly in Project Oberon. But what makes it unique is the presentation of the entire source code of the operating system and compiler, and extremely lucid descriptions of their design and construction, all in a single compact volume. Many excellent expositions of compiler design and compiler-writing toolkits exist, for example [4], [5]; but the emphasis is often on a general approach. Attention in the literature tends to be focused on writing a 'front-end', where statements formulated in the source language are parsed, whereas actual code-generation (the 'back end') is sometimes even left as an exercise to the reader.

Knowing that we could fall back on the source code and explanations in the book, at the beginning of 1997 we decided to start a project to build some new in-house development tools based around the hand-crafted, single-pass, recursive-descent Oberon compiler designed by Wirth.

3. Objectives

The goal of our project was a simple, portable application programming environment gained in a reasonably short time scale.

Simplicity was essential in order to ensure a complete understanding of the tool on which we were totally reliant. This avoids being in the position, when developing software systems for customers, of blaming tools like bad workmen. There is also usually a need to maintain and adapt software long after it has been created, and our compiler tool would not be exempt from this.

Several different machines and operating systems, including at least Microsoft Windows (32-bit) and Apple Macintosh, would need to be supported. So the compiler would need to be portable, generating code for more than one processor chip (at least Intel 80386 and Motorola 68000 respectively).

The third requirement was that the programming of the tools should not be an undue distraction - either during their construction or afterwards. We had no intention of becoming a development tools company, spending large amounts of time on the maintenance of our compiler for each machine platform - we wished actually to use the tools.

(1997) We have developed a turn-key enterprise solution for the Austrian Fund for Industrial Research (FFF, renamed to FFG meanwhile) in Vienna. The solution covers all aspects of office automation inluding book keeping, reporting and money transfer. It interacts with standard components such as electronic banking software, book keeping software etc. We are still involved in maintaining this solution and adapting it to ever changing requirements. The FFF97-project is based on the BlackBox Component Builder from Oberon microsystems. An article about this project has been published in "The School of Niklaus Wirth" by dpunkt.verlag, Heidelberg.

Abstract

The Oberon programming language and system, subsequently called the Oberon
technology, are well known in the software research community. Few applications,
however, exist outside academic institutions. This paper describes one of them
(FFF97), which constitutes a database front end application that has been in
mission critical use by more than 25 concurrent users since 1998. FFF97 makes
full use of Oberon’s innovations including dynamic loading, commands, garbage
collection, type extension, integrated text and form system, component
technologies, model/view separation, low resource consumption, etc. It is claimed
that choosing the Oberon technology and a particular approach to software
construction, known under the term ‘Prototyping’, was of vital importance for this
project, which, as one of the rare examples of custom software development
projects, was completed within the scheduled time and budget without
compromising quality or functionality.

1. Introduction

The successful application of research results to real world problems can be considered
the ultimate justification for spending money on pure research and as a proof of the
correctness and relevance of the research results. In the field of software engineering, one
controversial research project was the Oberon project [1], carried out by N. Wirth and J.
Gutknecht at ETH Zurich starting in the late 80s. Many computer professionals still doubt
the advantages and relevance of this technology because it started from scratch and
ignored industry standards, and because it appears to be too simple to compare favorably
against industry standard technologies. This paper describes the story of FFF97, a
database front end application based on the Oberon technology, that has been in mission-
critical use by more than 25 persons since 1998. FFF97 embodies a perfect example of
applying the results of the Oberon project to the real world, not because it shows that the
problem could equally well be solved in Oberon, but because it shows that the problem
could better be solved in Oberon. In fact, we are not aware of any other system that would
have been suited better to this particular task.
In the following chapters we will describe the application domain, the chosen approach
to software development, the rationale for choosing the Oberon technology, architectural
and implementational aspects of the developed system. We will also present a summary of
vital points and some general remarks.

15. Summary of Vital Points

Let us now summarize the points which we believe were vital for the success of the
project.

• Prototyping turned out to be possible to circumvent the writing of detailed
specifications, which nobody is able to accomplish for a complex project. It depends,
however, on efficient tools and the close cooperation of all participants. The short
feed-back loop avoids developments in the wrong direction, so we never had to throw
away big pieces of work. Without an Oberon style IDDEE tool, we believe, it would
have been impossible to achieve the required number of development cycles.

• Error avoidance is of vital importance for a prototyping approach, since long
debugging times simply cannot be afforded. Oberon’s approach of using an airtight
type system and automatic garbage collection turned out to be an invaluable asset
even in the world of commercial data processing. The procedure activation stack
dump provided in case of a runtime exception and the possibility of inspecting global
variables were sufficient for debugging logical errors. This is, by the way, more than
one gets in traditional IDEs, since Oberon does not need to make a distinction
between release (without debugging) and debug version.

• Efficiency of the resulting programs in terms of time and memory consumption can
only be achieved with a compiled general purpose programming language and
reasonably designed libraries. Both is the case with BlackBox, which made it possible
to run the application on i486/33Mhz with 16MB main memory. It is still an
advantage after switching to bigger PCs, because it allows the user to start more than
one FFF97 process or other office tools in order to perform certain parallel tasks. It is
also an advantage when working offline on a Laptop, which must host a database
server locally. A small disk footprint is also an advantage when starting a program via
a network from a central file server.

• Oberon’s dynamic loading strategy turned out to be of three-fold benefit to us: (1) it
avoids the extra linking step during development, (2) it allows the application to be
installed on a central file server and to be loaded incrementally with almost
unnoticeable loading delays even on a 10Mbit network with about 30 active users, FFF97 13
and (3) it allows us to maintain and update the system incrementally via remote
access over a single 64 Kbit ISDN line.

• Text integration pioneered by the original Oberon project and continued by BlackBox
turned out to be at the very heart of our application. A simple SCP report generator
needed just a few weeks of coding and allowed us to create text templates for a broad
range of applications including reports and letters with little effort and great
flexibility.

• Meta-programming support in BlackBox introduces many features of 4GL
programming systems and allows a tight integration of the program with databases
and user interface components. There is no extra coding required and there is also no
code generator involved.

16. Concluding Remarks

The following contains some thoughts about lessons learned during the course of the
FFF97 project. Some of the points are actually statements made by Prof. N.Wirth that
proved to be more than true in practice.

• “Keep it as simple as possible, but not simpler” (Einstein, often quoted by
Wirth) is especially important in a prototyping approach in order to be flexible
enough to incorporate additional or deviating needs. Whenever it is unclear
what the user really needs, do not invest a big effort in a preliminary solution.

• A user interface should be created using visual design tools, not by means of
lengthy statement sequences. There is no need for a code generator within such
a form editor, which simplifies development and the development system
significantly. It also provides a clear separation of concerns, GUI design on the
one hand and functionality behind the buttons on the other. Programmed user
interfaces are only justified in exceptional cases, where dynamic layouts are
needed.

• The lack of static typing in the database world constitutes a major problem for
client applications whenever the data model needs to be changed. It is
impossible to test all dependent programs systematically. With the common
approach of using dynamic SQL inside a general purpose programming
language, this situation cannot be expected to change in the near future.

• Modern database systems and programming interfaces exhibit a degree of
complexity that is hard to digest for someone used to the simplicity of the
Oberon system. Most of the complexity stems from irregularities and
exceptional cases that would better be omitted from the specifications. This
might free some resources for introducing higher level concepts such as types
and type extension into a database management system, which is still a long
way off.

• Wasting resources is never a good idea even if the resources appear to be
unlimited, as is the case with disk space nowadays. With a highly normalized
data model and compact representation of text documents we were able to fit
the database into less than 160 MB, a small fraction of a modern hard disk.
There are advantages, though. Backup is fast and our database fits almost
entirely into the main memory of a modern server computer, where 256 MByte
and more are the norm. The same argument holds for every level of the memory
hierarchy.

• Compiler construction is at the very heart of computer science. Even in a
commercial data processing application, one can make good use of a simple
language and a recursive descent parser as can be seen by the SCP example.
Custom software projects such as FFF97 are always at the technological limit.
With improved hardware and software technology user expectations are raised,
because standard software created with thousands of man-years raises the
standard of comparison to new heights. Keeping up to those expectations is
everything but easy considering the limited development resources for custom
software.

• What a user wants is not always what a user needs. Taken literally, the wishes
formulated by users range from trivial to unsolvable. They often include how to
do it, based on a particular idea, and not only what to do. It is the developer’s
task to find the intersection of realizable and powerful concepts, which in many
cases deviates significantly from what the user originally wanted.

• Sometimes the user is not able to distinguish between “always” and “often” and
between “never” and “seldom”. This can easily lead to oversimplifications that
do not take exceptional cases into account.

• Oberon microsystems Inc. did an excellent job of hiding the complexities of the
Windows API and preserving the spirit of Oberon in a Windows environment.
There are some points left to be improved (e.g. advanced GUI interface
elements), of course, which are mainly due to limited manpower. The
complexities and irregularities of the Windows API make it difficult to integrate
Windows services and components seamlessly with a reasonable effort.

• The FFF97 project would certainly not have been possible in 1996 and would
still not be possible in 2000 with the much hyped Java technology. Although
Java resembles Oberon in some aspects (e.g. garbage collection, strong typing),
its library is far from being useful for this kind of application. It would require
at least five times the memory, execution time, development effort and program
startup time, let alone the unsolved problem of text integration and printing.