It looks like you're new here. If you want to get involved, click one of these buttons!
Oberon emerged from ETH Zurich in 1987, the work of Niklaus Wirth and Jürg Gutknecht, as part of a larger project to design both a programming language and an operating system for the custom Ceres workstation. This was an exercise in total system design—language, compiler, OS, and hardware conceived together as mutually shaping parts of a single technical culture. Wirth, already renowned for Pascal and Modula-2, positioned Oberon as a deliberate reduction: fewer features, stricter discipline, radical simplicity.
The code snippet under consideration is not production code but pedagogical code—an exercise from the 1992 textbook Programming in Oberon: Steps Beyond Pascal and Modula. Its purpose is to test students' understanding of type checking and parameter passing. This makes it doubly interesting for critical code studies: we are reading not just a language but a teaching philosophy encoded in syntax. The exercise format reveals what its authors believed novice programmers needed to internalize about correctness, safety, and the boundaries between value and reference.
The snippet is worth reading rather than running because it was never meant to execute. It is a diagnostic instrument—a litmus test for comprehension. To study it is to study the transmission of programming values from master to student within a particular European academic tradition that privileged mathematical rigor over commercial expedience. The wider Project Oberon framing—designing a coherent system "from scratch," with a scope that a single person might plausibly comprehend—invites reading exercises like the one below as small, teachable demonstrations of a broader ideology of simplicity, tractability, and whole-system legibility.
The following questions are intended as openings for collective discussion, not as problems to be solved:
From page 84 of Programming in Oberon: Steps Beyond Pascal and Modula (Reiser & Wirth, 1992):
6.2 Assume
CONST x1 = 1; x2 = 2; x3 = 3; x4 = 4; x = 3.14159; VAR a, b, c, aR, bR, aI, bI: REAL; i: INTEGER; xR, yR, xI, yI: LONGREAL; PROCEDURE Root(a, b, c: REAL; VAR x1, x2, y1, y2: REAL); PROCEDURE Sin(x: REAL): REAL; PROCEDURE Min(x, y: INTEGER): INTEGER;Which of the following statements containing procedure calls are correct?
Root(a, b, c, aR, bR, aI, bI); Root(1, 3, 4, x1, x2, x3, x4); Sin(3.14159); a := Sin(x1); i := Min(x, x1); i := Min(x1, x2); Root(a, b, c, 3, 4, 5, 6); Root(a, 3*b, c + 1, xR, yR, xI, yI);
Early technical report on Oberon (1987)
https://www.research-collection.ethz.ch/entities/publication/9f821e43-9ed4-4c4d-a54a-36468e7bdaca
Relevant as the founding document; may reveal initial design rationales before the language stabilized.
Early technical report on Oberon (1988)
https://www.research-collection.ethz.ch/entities/publication/32fa890f-93f2-407e-ab66-badc5ca36638
Documents early revisions; useful for tracking what the designers considered changeable vs. essential.
The Oberon System (Technical Report, 1988)
https://www.research-collection.ethz.ch/handle/20.500.11850/68897
Connects language features to environment design, supporting discussion of how "coherence" is operationalized as a systems project.
Project Oberon Book (Wirth & Gutknecht)
https://people.inf.ethz.ch/wirth/ProjectOberon1992.pdf
A long-form account of design rationales that can be read alongside small pedagogical prompts like "Assume," to relate micro-semantics to macro-architecture.
Project Oberon Portal
https://www.projectoberon.net/
Comprehensive portal; matters because Oberon was a total system project, not just a language. A curated entry into the "whole system" framing, including how coherence is presented to contemporary readers and practitioners.
Programming in Oberon: Steps Beyond Pascal and Modula (1992)
https://free.oberon.org/files/Programming_in_Oberon_1992.pdf
The textbook from which this exercise is drawn; the full context for pedagogical intent.
Photographs of the Ceres Workstation
https://wil.e-pics.ethz.ch/#main-search-text=Oberon
Visual/material culture of the hardware Oberon was designed for; reminds us that languages are embodied in machines. A route to material culture discussions of how language ideals (simplicity, efficiency, legibility) are situated in physical form factors, interfaces, and constraints.
Wikipedia: Niklaus Wirth
https://en.wikipedia.org/wiki/Niklaus_Wirth
Context for Wirth's broader design philosophy (Pascal, Modula-2, the "Wirth school" of language minimalism). A waypoint into institutional biographies and the broader "Wirthian" lineage that shapes how Oberon is positioned historically.
Wikipedia: Jürg Gutknecht
https://en.wikipedia.org/wiki/J%C3%BCrg_Gutknecht
Co-designer of Oberon; his contributions to the operating system side may illuminate design choices in the language. A route to the collaborative and infrastructural labor often backgrounded when languages are narrated through singular authorship.
Comments
To address the questions, I would like to put another code snippet up for discussion:
tl;dr My impression is that Oberon and Scheme (or SICP) are examples of languages that have a certain idea of computer science and programming in mind: mathematical, principle-driven, simple, which they attempt to incorporate into teaching. The goal of teaching is understood as something that benefits from these principles. In contrast, Vakil (2018) and Schulte and Budde (2018) have each argued that the goals of computer science education should be far less technical. Both see CS as a tool for self-empowerment that creates a just society and responsible citizens in a digital society. This naturally raises the question: if Oberon and Scheme are not the right tools for this, what is?
Thanks Gregor for citing the great SICP. That book can't be cited enough!
Sussman and Abelson set out the idea that computer science is about "procedural knowledge," as opposed to mathematics, which is "declarative." By this they meant that computer science is the study of procedures to do things. It follows (more or less) that the ideal programming language is a language for specifying procedures, or if you prefer the ALGOL way of putting it, for describing algorithms.
Oberon is obviously an ALGOL-type language, which is hardly surprising given Wirth's involvement in its design and development.
It is quite common to trash the idea of studying algorithms today. I can recall Ben Schmitt writing a piece in I think The Atlantic about falling enrolments in HASS across the US. Lamenting the corresponding rise in Computers Science enrolments, he posed a question like "Do we really need all these undergraduates to know the quicksort algorithm?"
I don't like that rhetorical question at all. The enthymeme is clearly "it would be much better for students to acquire historical knowledge." But the rhetorical question can easily be turned on the Humanities: "Do we really need all these undergraduates to know that Carthage was sacked in 146 BCE?" Quite obviously the date of the sack of Carthage is not a valuable fact on its own. Nor is the quicksort algorithm. The sack of Carthage is interesting when it forms part of a broader history curriculum where students acquire knowledge of source analysis, politics, class, rhetoric etc. Likewise quicksort is interesting when it forms part of a broader curriculum about how to structure computations.
I think Sussman and Abelson were having a mid-life crisis when they let MIT give up on Scheme. Some of their colleagues in Singapore updated the curriculum in I think a much nicer way: by re-writing SICP to use JavaScript instead of Scheme. In one stroke, they preserved the philosophical underpinnings of SICP, while also addressing silly anxieties about "industry relevance."
The Oberon-level is a good level on which to think of computations. CCS works well at the Oberon-level: inspecting individual lines, functions, subroutines, control blocks. If I may quote SICP again, the authors themselves indicate how their level of analysis might form the basis for a more humanistic critique of programming. In their discussion of functional vs. object-oriented styles, they write:
They are essentially saying that functional programming implies a Whiteheadian process metaphysics, while object-oriented programming implies a Kantian metaphysics of discrete objects. I have found this passage inspiring, as a hinge on which a more technical view of code can pivot into a metaphysical and/or ideological view.
You mean, worldview could be buried inside coding: "more technical view of code can pivot into a metaphysical and/or ideological view". Wow! How could you justify this in this snippet "
CONST x1 = 1; x2 = 2; x3 = 3; x4 = 4; x = 3.14159;
VAR a, b, c, aR, bR, aI, bI: REAL; i: INTEGER;
xR, yR, xI, yI: LONGREAL;
PROCEDURE Root(a, b, c: REAL; VAR x1, x2, y1, y2: REAL);
PROCEDURE Sin(x: REAL): REAL;
PROCEDURE Min(x, y: INTEGER): INTEGER;"