Oberon (programming language)
Oberon is a programming language created in the late 1980s by Professor Niklaus Wirth (creator of the Pascal, Modula and Modula-2 programming languages) and his associates at ETHZ in Switzerland. The name is from the moon of Uranus, Oberon.
Oberon is also, somewhat confusingly, the name of the Oberon operating system, written in Oberon, for the Ceres workstation (built around the National Semiconductor 32032 CPU) and for the Chameleon workstation. Oberon, the language, has now been ported to many other operating systems, and is even available for the Java platform, where Oberon source code compiles either to source code in Java or to bytecode for a Java virtual machine. The operating system Oberon is also available for several other hardware platforms than the original workstation.
The design continued the Wirth tradition/strategy of attempting to simplify without loss of power. Oberon may be thought of as a Modula-2 with full object oriented class/object capabilities, though not exactly in C++ or Smalltalk style. On the other hand, Oberon removes many features that can be implemented using objects, include enumerations, records, and many other features found in older Wirthian languages and elsewhere.
Oberon is very much Modula-2 like in its syntax, but offers several interesting features. Perhaps the foremost is 'type extension' by which most of the reuseability of object classes is made available. Furthermore, 'binding to a type' is included, which ties what would in Smalltalk be called 'methods' to a type (ie, class), with the result being object orientation. As with other modern programming languages, garbage collection is an inherent part of the language. Procedures are also cleanly exportable.
Oberon's feature simplicity leads to considerable space and coding efficiency for its compilers, as little provision is needed for features not included. The full language can be specified in something like a page of EBNF, the Oberon report is, at 16 pages, about 1/3 the size of the Modula-2 report, and one of the early full compilers was about 4000 lines long. In addition, compiler output is also smaller and faster, probably also due to reduced feature complexity. Entire Web browsers written in Oberon have fit on a single floppy disk.
Design goals
Oberon is designed to be a 'safe' language; it employs bounds checking, garbage collection and stronger typing than, say, C. These features can significantly reduce the number of bugs in a program. However, as many features were removed which in other langauges are included in an attempt to reduce bugs (eg, enumerations and programmer-defined ranges on integers), the objects which serve in their place in Oberon must be carefully designed.
Oberon was intended to make mistakes harder in part by making code less opaque, and in part because features not included cannot be misused. This approach can be taken even further, as in APL, which is both exceptionally terse and renowned for being less than easy to understand, but Oberon was deliberately constructed to not over simplify.
As this is an intent whose success cannot be easily quantified, there remains some disagreement that Oberon has achieved its intended goals in this respect. One objection to its strategy of language design simplification was expressed by Jean Ichbiah, the architect of Ada when Wirth criticized Ada for being too big; he responded "There are times when Wirth believes in small solutions for big problems. I don't believe in that sort of miracle. Big problems need big solutions!" Oberon developers have even felt that Oberon (version 1) went too far in this respect -- Oberon 2 returned the 'WITH' statement to that version of the language.
It can be argued that failure to include a feature may force the programmer to reimplement the feature in his code, leading to multiple 'wheel reinvention' and consequent problems. Libraries can mitigate this -- more or less -- effectively depending on the feature and a language's graceful use of such libraries. Java is an example of a relatively simple language (though far less so than Oberon) embedded in large standard libraries. (Oberon has a much smaller standard library than Java.) As much of the effort of learning any language is learning the standard libraries, Ichibah's objection above can be extended to a strategy of simplification by moving features from the core language into standard libraries. Wirth, and Oberon fans, argue that Oberon has essentially, and effectively, avoided this problem.
Available implementations & further language variants
No-cost implementations of Oberon (the language) and Oberon (the operating system) can be found on the Internet (several are from ETHZ itself). A few changes were made to the first released specification ('WITH' was put back in, for instance); the result was Oberon 2, currently the most common implementation. There is also a .NET version in development for those interested in Microsoft's vision. There is a release called Native Oberon. As it includes an operating system, it can directly boot on PC class hardware.
Development has continued on languges in this family. A further extension of Oberon 2 produced Component Pascal, currently supported by a commercial company spun off from ETHZ. In addition, the Lagoona and Obliq languages carry the Oberon spirit into specialized areas. ETHZ has released Active Oberon which supports active objects, and the Bluebottle operating system and environment (JDK, HTTP, FTP, etc) for the language. As with many prior designs from ETHZ, versions of both are available for download on the Internet. As this is written, both single and dual x86 CPUs and the StrongARM family are supported.
Hello World
MODULE Hello;
IMPORT Oberon, Texts;
VAR W: Texts.Writer;
PROCEDURE World*;
BEGIN
Texts.WriteString(W, "Hello World!");
Texts.WriteLn(W);
Texts.Append(Oberon.Log, W.buf);
END World;
BEGIN
Texts.OpenWriter(W);
END Hello.