|
A Brief History of OberonAlgolThe language Oberon is the culmination of several decades of research. It is the youngest member in the Algol family of languages. Algol, defined in 1960, was the first high-level language with a readable, structured, and systematically defined syntax. While successful as a notation for mathematical algorithms, it lacked important data types, such as pointers or characters. PascalIn the late sixties, several proposals for an evolutionary successor to Algol were developed. The most successful one was Pascal, defined in 1970 by Prof. Niklaus Wirth at ETH Zürich, the Swiss Federal Institute of Technology. Besides cleaning up or leaving out some of Algol's more obscure features, Pascal added the capability to define new data types out of simpler existing ones. Pascal also supported dynamic data structures, i.e. data structures which can grow and shrink while a program is running. Pascal received a big boost when ETH released a Pascal compiler that produced a simple intermediate code (P-code), instead of true native code for a particular machine. This simplified the port of Pascal to other processor architectures considerably, because only a new P-code interpreter had to be written for this purpose; not a whole new compiler. One of these projects had been undertaken at the University of California, San Diego. Remarkably, this implementation (UCSD Pascal) didn't require a large and expensive mainframe computer, it ran on the then new Apple II personal computers. This gave Pascal a second important boost. The third one came when Borland released TurboPascal, a fast and inexpensive compiler, and integrated development environment for the IBM PC. Modula-2Meanwhile, inspired by a sabbatical at the Xerox Palo Alto Research Center PARC, Wirth started a project to develop a new workstation computer. This workstation should be completely programmable in a high-level language, thus the language had to provide direct access to the underlying hardware. Furthermore, it had to support team programming and modern software engineering principles, such as information hiding. These requirements led to the programming language Modula-2 (1979). Modula-2 retained the successful features of Pascal, and added a module system as well as a controlled way to circumvent the language's type system when doing low-level programming, e.g. when implementing device drivers. Modules could be added to the operating system at run-time. In fact, the whole operating system consisted of a collection of modules, without a distinguished kernel or similar artefact. Modules could be compiled and loaded separately, with complete type and version checking of their interfaces. Modula-2 has made inroads in particular into safety-critical areas, e.g. traffic control systems. Simula, Smalltalk, and CedarWirth's interest remained with desktop computers, however, and again an important impulse came from Xerox PARC. PARC was the place where the workstation, the laser printer, the local area network, the bitmap display, and many other enabling technologies have been invented. Also, PARC adopted and made popular several older and barely known technologies, e.g. the mouse, interactive graphics, and object-oriented programming. The latter concept, if not the term, was first applied to a high-level language in Simula (1966), another member of the Algol language family. As its name suggests, Simula used object-orientation primarily for simulation purposes. Xerox PARC's Smalltalk language (1983), however, used it for about anything. The Smalltalk project broke new ground also in user interface design: the graphical user interface (GUI) as we know it today, originally was developed for the Smalltalk system. At PARC, these ideas influenced other projects, e.g. the Cedar language, a language in the Pascal family. Like Smalltalk and later Oberon, Cedar was not only the name of a language but also of an operating system. The Cedar operating system was an impressive and powerful, but also rather complex and unstable system. The Oberon SystemThe Oberon project was initiated in 1985 at ETH. It was an attempt to distill the essence of Cedar into a comprehensive, but still comprehensible, workstation operating system. The comprehensibility of any design is tied to its simplicity and to its regularity. Both could only be achieved by starting from scratch, i.e. by designing the new operating system from the ground up. Wirth and his colleague Jürg Gutknecht even went so far as to design their own user interface and window system for that purpose. As a result, the new operating system became very small and efficient, working well with only 2 MB of RAM and 10 MB of disk space. Another reason for the small size of the Oberon system was its extensibility: instead of integrating all desirable features into one monolithic software colossus, the less frequently used software components (modules) could be implemented as extensions of the core system. Such components were only loaded when they were actually needed, and they could be shared by all applications. A major goal pursued with the Oberon system project concerned teaching: the new system should be useable as a case study of "programming in the large". Consequently, Wirth and Gutknecht not only designed and built the new system, but also documented it thoroughly. There are now several books on the Oberon system; one of them contains the system's full source code. In order to achieve exemplary clarity in the presentation of the Oberon system, Wirth streamlined Modula-2, and at the same time added type extension to support object-oriented programming. The resulting language obtained the same name as the system: Oberon. The Oberon LanguageThe new language (1987) embodies three decades of research into programming languages and software engineering, and is the result of a non-compromising quest for quality. The well-structured syntax of Oberon is sufficiently similar to Pascal that seasoned Pascal programmers can become comfortable with it in a short time. Oberon is simpler than Modula-2, and allows to better isolate non-portable or unsafe program parts. The streamlined module system of Oberon provides information hiding for whole collections of types, not only for individual classes as other languages do. Oberon modules are units of compilation and units of loading: a new module can be loaded dynamically at run-time (late linking). Oberon implements the essence of object-orientation in the form of record type extension: a record type can be declared as an extension of another record type. An extended type can be used wherever one of its base types can be used. This compatibility rule makes it possible to create dynamically polymorphic data structures, i.e. data structures that may contain specialized elements, which need not even be known at compile time of the client code. Late binding is provided by procedure variables, i.e. the same procedure call may cause different code to be invoked, depending on the object to which the procedure is bound. In an extensible system, a module may share its data structures with arbitrary other modules, about which it doesn't know anything. These modules usually don't know about each other either. Such mutual ignorance makes the management of dynamic data structures, in particular the correct deallocation of unused memory, a fundamentally more difficult problem than in closed software systems. Consequently, Oberon leaves it to the language implementation to find out when memory is not used anymore, in order to safely reclaim it for later use. A system service which performs such an automatic storage reclamation is called a garbage collector. Garbage collection prevents two of the most evasive and downright dangerous programming errors: memory leaks (not giving free unused memory) and dangling pointers (releasing memory too early, which usually has catastrophic results). While Algol-family languages always had a reputation of being safe, the type safety of Oberon is still a quantum leap forward in this respect. It makes possible systems which are both extensible and safe at the same time. Oberon is the first commercially available component-oriented programming language, i.e. a language which supports polymorphism, late linking and late binding, type safety, and information hiding beyond single classes. In 1992, a cooperation with Prof. H. P. Mössenböck led to a few additions to the original Oberon language ("Oberon-2"). Most ETH compilers and all commercial compilers support this de-facto standard of the language. The Oberon MoonOberon is the name both of an operating system and of a programming language. But where did the name originate?  Picture of Oberon It is said that the longevity and robustness of Voyager's on-board computer, which achieved these impressive results with comparatively simple technology, led Wirth to adopt the name Oberon. Putting Oberon Through its PacesIn 1987, the first version of the Oberon system became operational. At ETH's Institut für Computersysteme it soon began to replace other operating systems. It was used for software development, for everyday work such as writing letters and papers, up to the development of computer boards and circuits, and the necessary CAD software as well. For teaching purposes, Oberon superseded Modula-2. Based on the encouraging results, the system was further developed and new experimental variations were tried out. Getting Ready for the "Real World"The positive impression that Oberon made, due to its simplicity, efficiency, integration, and its productivity in general, was nevertheless overshadowed by its limited appeal to a wider audience: a new operating system without support for legacy systems and with a non-standard user interface would never be more than an interesting experiment, relegated to research environments. The only realistic way to make some of the results of the ETH Oberon project available to a larger public, was to design an Oberon system which was neither a complete operating system nor had its own user interface. Instead, it would have to support de-facto industry standards. Still it had to retain most advantages of the original Oberon system, because yet another traditional language / library product would offer too little benefit either. In short: it had to both fit in, and stand out. Oberon/F and The BlackBox Component BuilderCreating such a system cannot be the concern of a research and education institution such as ETH. Thus the ETH spin-off Oberon microsystems, Inc. was founded, with the goal of consolidating the experience gained from various ETH system versions into a commercial-grade product, which should fit into the prevailing desktop computing environments. Oberon microsystems developed the Oberon framework, or Oberon/F in short, starting in 1992. The scope of this product lies between an operating system and an application. It can be extended at run-time like an operating system, but runs on top of industry standard operating systems like normal applications do. It is an integrated development environment, a visual designer, a cross-platform class library, a compound document facility, a word processor, as well as the run-time environment of Oberon components. Rather than providing its own user interface, Oberon/F adapts to the user interface of the host platform on which it runs. The main focus during the Oberon/F design was the support for component software, in particular for compound documents. This led to the following list of design goals:
These ambitious goals would not have been achievable without severe compromises, if strict compatibility to an existing ETH Oberon system was required. Thus, while Oberon/F adopted many concepts and ideas of the various ETH Oberon systems, it is basically a new design, optimized for conformance with industry standard operating systems, standard graphical user interfaces, and standard compound document architectures. In early 1997, Oberon/F has been renamed to avoid confusion with ETH's Oberon System. The Oberon/F development environment is now called BlackBox Component Builder. The framework itself is called BlackBox Component Framework. Copyright © by Oberon microsystems, Inc. All rights reserved. No part of this text may be reproduced in any form or by any means, without prior written permission by Oberon microsystems.
|
