I find it unfortunate that ComputingReviews chose to publish the recension by J. Klaczakof The Oberon system: user guide and programmer’smanual in September. Oberon is the outcomeof a research project and as such should and will be scrutinized by thescientific world. But it certainly deserves better than to be pulled topieces in an attempt at first-round knockout.
As clearly stated in its title, my book is themanual of Oberon, a novel workstationoperating system (see Wirth and Gutknecht [1]) conceived and implementedat the Swiss Federal Institute of Technology (ETH). The book actuallycombines several elements in a single volume: a description of the userinterface, a human interface style guide, a reference section of themodules composing Oberon, a system programming tutorial, and a complexexample of a system extension. This concept is made possible by the factthat Oberon is compact and describable, a property that distinguishes itfrom most other operating systems. Klaczak’s review features thecontents of the book but goes into little detail as to the degree towhich the challenges of its concepts are met. Not the book proper butthe Oberon system itself has become the main subject of thereview.
Most troubling is the fact that the review creates the impressionthat “…Oberon has never run.” The first Oberonimplementation has been operational on the Ceres workstation (see Eberle[2]) since at least 1987; 100 Ceres are currently available forstudents’ use at ETH. To date, Oberon has been portedto a variety of platforms including RS/6000 (IBM), Sparcstation (SUN),Macintosh (Apple), and DECstation/3100 (DEC). Since Oberon isdistributed as freeware by ETH, the reviewer could easily havefamiliarized himself with an Oberon system in operation, and thus couldhave avoided many of the misconceptions and errors found in hisreview.
Not only does Klaczak question whether Oberon ever ran, he is alsoquick to doubt its practical usefulness, especially as a teachingvehicle. The languages and systems created by Wirth have always placedstrong emphasis on classroom use, based on the interesting premise thatwhat is good for teaching is good for programming at large. Oberonexcels in this regard by virtue of its compactness and the clarity ofits concepts. The computer science department at ETH uses Oberon toteach programming, both at basic and advanced levels. Of course, thereare many views as to what constitutes a good environment for teachingprogramming. But to claim, as the reviewer does, that “it isimpossible to teach students using such an environment” isunreasonable, to put it mildly. That ETH is not entirely on the wrongtrack is corroborated by the fact that other universities have followedsuit. To counter the reviewer’s remark that “the book is notintended for students,” I can report that ETH students use it intheir classes and, according to their professors, like it a greatdeal.
I do not wish to refu te all the mistakes and inaccuracies containedin the review but focus on only three broader issues. Before I do so,however, let me quote two particularly troubling sentences asrepresentatives of many others. The first one is, “It [Oberon] isa pure actor programming language, without control flow, reduction, orother constructs of object-oriented languages based on the classconcept.” Oberon is not an actor language and the rest isobviously nonsense. Furthermore, the following quote speaks for thegeneral tone of the review: “Oberon is yet another Ada, born in anivory tower as would-be new and elegant UNIX.”
The first of the broader issues I wish to address is the impressioncreated by the review that Oberon is purely a programmer’s workstationand that applications are missing or, worse, that Oberon “neverwill have them.” To mention Pascal among those applications Oberonallegedly will never have is somewhat ludicrous--the languageOberon is an integral part of the system and a second-degree descendantof Pascal.
Of course, the question of whether a new system will acquireapplications that make it commercially attractive is an important oneand often a serious impediment to progress in the operating systemfield. I wish to recall the discussions in the trade press that followedthe announcement of OS/2 or the NeXT system. Knowing that a system musthave basic applications to be attractive, ETH implemented wordprocessors, paint programs, and graphics editors, among others. Theseapplications are part of the freeware available fromETH. An important point is that since Oberon is anextensible system, it is easy for third parties to evolve thoseapplications from the existing base.
The second broader misconception is that “Oberon is errorprone. No clear boundary exists between Oberon and itsapplications….” The major goal of Oberon is extensibilityand therefore the boundary mentioned is purposely avoided. That no suchboundary exists sets the modern, object-oriented operating systems apartfrom their predecessors. The structure of Oberon is that of a hierarchyof modules, each one typically exporting one or several abstract datatypes. Dynamic loading brings modules into memory at the time they areneeded. That the system as a whole does not sacrifice integrity is atriumph of the concept of type safety paired with automatic storagemanagement (that is, garbage collection). The power and generality ofthese concepts seems not to be universal knowledge and is certainly notappreciated in Klaczak’s review.
None of Oberon’s other innovations--such as nonmodal texts andcommand polymorphism--are appreciated either. But let me concludewith one last broader issue, that of competence and attitude of thereferee. I repeat that the merits of Oberon should indeed be debated.But to compare it to DOS and a DOS editor (Brief), as the reviewer does,entirely misses the mark. He goes on to say: “The standard we useto judge Ni klaus Wirth and his co-workers is of course much higher thanthat applied to ordinary writers.” I believe that all writersshould be judged in the same manner--namely competently,constructively, and fairly.
