Oberon programming language

Oberon is a Reflection_(computer_science) programming language created in the late 1980s by Professor Niklaus Wirth (creator of the Pascal programming language, Modula, and Modula-2 programming languages) and his associates at ETHZ in Switzerland. The name is from the moon of Uranus (planet), Oberon (moon).

Oberon is also, somewhat confusingly, the name of the Oberon operating system, written in Oberon, for the Ceres workstation (built around the NS320xx CPU) and for the Chameleon (computing) workstation. Oberon, the language, has now been ported to many other operating systems, and is even available for the Java programming language platform, where Oberon source code compiles to source code in Java, or to bytecode for a Java virtual machine. The Oberon operating system 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 plus plus or Smalltalk programming language style. On the other hand, Oberon omits variant records, as these now can be implemented more safely using type extension, and other features such as enumeration types and subrange types, 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 (computer science)), with the result being object orientation. As with other modern programming languages, garbage collection (computer science) 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 array bounds checking, garbage collection and strong type checking. These features, particularly ones which enable logic errors to be detected as early as possible (i.e. at compile-time), can significantly reduce the number of computer bugs occurring in a program at runtime. However, some features included in other languages in an attempt to reduce bugs (e.g. enumerations and programmer-defined ranges on integers), were omitted. Consequently, more care should be taken by the programmer, when working with numeric expressions, to avoid logic errors.

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 programming language, 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 programming language 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 FOR 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 programming language 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 (the FOR loop was reinstated, for instance); the result was Oberon 2, currently the most common implementation. There is also a Microsoft .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 Lagoonalang 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.

Oberon-V (originally called Seneca) is a descendant of Oberon designed for numerical applications on supercomputers, especially vector or pipelined architectures. It includes array constructors and an ALL statement. (See Seneca - A Language for Numerical Applications on Vectorcomputers , Proc CONPAR 90 - VAPP IV Conf. R. Griesemer, Diss Nr. 10277, ETH Zurich.)

=See also=

Hello world program#Oberon

=External links=

*[http://www.oberon.ethz.ch ETH Oberon Home Page] *[http://www.oberon.ethz.ch/native/ Native Oberon Home Page at ETHZ] *[http://www.oberon.ethz.ch/genealogy.html Oberon Language Genealogy]