I agree that Oberon itself became an additional subject of myreview. The rebuttal challenges only that part of it, so I conclude thatthe author agrees fully with the remaining 40 percent of my review,which deals with the book. Therefore, I will not restate my previouspoints, such as “the book is not intended for students”because it has no exercises. I simply envy ETH students the time theyspare by not having to solve exercises in their classes.

I have not described the freeware Oberon (the diskette is notincluded with the book) in operation because the time limit imposed byComputing Reviews did not permit meto port Oberon to my old 386 laptop (perhaps several student-weeks wouldhave been enough). I have written about Oberon asdescribed in this book, including what appear to beprintouts of its actual source code. The flowchart of the modulehierarchy (p. 87 andp. 295) has 10 errors concerning dependencygraphs and omits some modules described and signalled in all three partsof the book. Maybe it is an oversimplified or preliminary version. Evenif it does run, I have identified about 40 minor errors, not to mentionmore than two dozen logical flaws of various severity, most of whichwould cause runtime errors. Oberon is certainly not the first operatingsystem without software bugs. Reiser confirms that Oberon has no realapplications (paint programs and graphics editors are only toys). Evenworse, Oberon lacks compilers (except for itself). Pascal is not asubset of Oberon (the way C is a subset of C++); therefore, all thecommon source libraries (including Plauger’s tools) must be rewritten.I/O procedures are not overloaded. Moreover, “traditional”computation must be explicitly time-sliced by the user. Working inOberon is like programming under Windows--the initial step requiredto write an application is too big. But Windows now has CASEtools--what does Oberon offer?

The old semantics (borrowed from its predecessors) are used inOberon to perform completely different functions. Pascal’s NEW (forcreation of passive data structure) here instantiates an active object.No handler--even a default handler--is installedautomatically. If NEW is not “immediately followed”(p. 84) by such an assignment, a syntacticallycorrect program can create objects without handlers (resulting in asystem crash). The obvious solution is to let the handler be NEW’ssecond parameter. Similarly, using the ordinary procedure-call mechanismto send messages creates the possibility of passing a handler acompletely different kind of frame than it is prepared to work with.Another solution is possible: denote the message and the frame, anddetermine the proper handler automatically (for example, for everyactive object, the pointer to its handler is the first, hidden field ofthe underlying data structure). Too often, “the user must enforce[specific] restriction.” If a field must have a particular value,why does n’t Oberon set it itself (p. 114,p. 129)? ChangedViewer can beSystem.Closed without asking whetherto write a modified file back to the disk.Files.Purge creates dangling handlers(p. 102), which can allow other files to bedestroyed. The protection scheme is based on goodwill assumptions. Thelack of a clear boundary between an operating system and itsapplications definitely sets it apart from its mainframepredecessors--it is not error-prone, it is virus-provoking,especially for students.

A graphical user interface (GUI) is useless if, for example, youhave to delete all files containing “PAYROLL LIST.” In thatcase, from the user’s viewpoint a GUI is a step backward. In Oberon, theviewer’s menu bar can be changed but not saved; it cannot be customizedfor a program. Oberon does have nonmodal text, until you have to read apassword. Also, I first must write down my command line (as usual) inany text frame and additionally pointand click in order to execute it. (The system lacks hot keys and searchpaths.) Then the command must announce viaSystem.Log that it hasfinished.

I have always thought that “actor” means a languagewith message passing as a data mechanism and a pattern-driven controlmechanism (active objects await messages triggering their execution).SmallTalk and other object-oriented programs are examples. Perhaps I amwrong.

Some ambitious projects yield nothing, such as Ada, Modula,ALGOL68, and CMU’s SPICE. In 1986, PierluigiZappacosta, the president of Logitech, said, “Is C apossible candidate for the language of the future? I do not thinkso…” [1]. Pascal has gained popularity due partly to itsfreeware compiler source--will Oberon follow it or take Modula’spath? Will OS/2 on Ceres run under or instead of Oberon, and when? OnlyNiels Jensen mentioned Oberon in a special issue ofBYTE on the future of specificoperating systems [2] (his company, TopSpeed Modula, is producing C++).But in the operating systems forecast in the same issue [3], UNIX,NextStep, PenPoint and portable OS/2, NT and X, and even Sprite, alesser-known project, are discussed--not Ceres or Oberon. Also inthe same issue, Gene Smarte said, “Vociferous supporters of nichesystems …will always be with us” [4]. In summary, Oberon isnow in a much weaker position than Modula-2 was six years ago. If Modulahasn’t succeeded, Oberon will not either.

I am very sorry that Oberon “pulled to pieces” whenbuffeted by me. Reiser states that “Oberon is a sophisticatedsystem and provides equivalent…functionality” to commercialoperating systems (p. 13). To which one? Oberonlacks overlapping windows, true preemptive multitasking (includingdevice interrupts), batch macroscripts, module unloading, truehierarchical filestore, file protection, and even word wrapping: it hasthe complexity of Brief, not of Windows. I am sur ely incompetent, tryingto compare Oberon to widely used operating systems; not all operatingsystems should be judged in the same manner.