Oberon: procedure interfaces, parameter modes, and strict typing (1992)

Comments

• GregorGB

  January 13 edited January 15

  To address the questions, I would like to put another code snippet up for discussion:

  • Structure and Interpretation of Computer Programs (SICP), Ch. 1.1

  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?
• michael.falk

  January 13

  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:

  In this chapter we will investigate two prominent organizational strategies arising from two rather different “world views” of the structure of systems. The first organizational strategy concentrates on objects, viewing a large system as a collection of distinct objects whose behaviors may change over time. An alternative organizational strategy concentrates on the streams of information that flow in the system, much as an electrical engineer views a signal-processing system.

  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.
• Waliya

  January 17

  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;"
• moritz.maehr

  January 19

  @Waliya This example illustrates this world view. The world view is expressed in reports and textbooks you find attached. Having lot's of abstracted educational examples is performative evidence for this worldview.
• markcmarino

  January 19

  I'm wondering what people think of Oberon as a first language to learn, as opposed to Pascal, python, Java, Javascript, or even BASIC? Wirth seemed to knock it out of the park with Pascal. What does Oberon offer that Pascal did not? What are educators and learners looking for in a first language?
• millstein

  January 19

  I can't comment on Oberon specifically, but when I teach programming I want to focus on problem solving and demonstrate how a few powerful concepts in computing enable this in flexible ways. I don't want to get bogged down in lower-level implementation details and considerations, at least in a first course.

  The choice of language to teach used to be a big debate but that choice has become less important to me over time. Today essentially all languages support programming in the most common styles (e.g., functional and object-oriented), which was not always the case. So one can pretty much use any language for teaching but curate a subset of the language to be used by students, possibly enlarging it over time. For example, I use Python in my intro course but for most of the course we use a Scheme-like subset.
• moritz.maehr

  January 19

  @millstein I agree with your point that, pedagogically, we can often “choose any language” and then curate a subset—especially now that most mainstream languages can host multiple styles. But I also think it’s not an accident that so many intro courses converge on Python (and, in some settings, JavaScript). That convergence is not just a matter of market fashion; it tracks what a language lets beginners successfully do early, and what kinds of errors it makes salient or defers.

  Python (and JS) are optimized for rapid production of working programs with low syntactic overhead: dynamic typing reduces up-front representational commitments; indentation/whitespace (in Python) creates a strong visual cueing system; and the overall “shape” of code tends to privilege legibility and iteration over explicitness about machine-level or type-level constraints. That doesn’t mean these languages lack rigor—but they defer certain disciplines (type discipline, memory discipline, interface discipline) until later, which can be pedagogically valuable if your goal is early confidence in decomposition, iteration, and procedural thinking.

  By contrast, Pascal and Oberon feel like they were designed to make discipline itself part of the first encounter: static typing, explicit interfaces, parameter modes, and a narrower feature set that encodes a particular notion of correctness and “good form.” In that sense they can read as performative pedagogy: they don’t merely teach programming, they teach a normative model of what programming ought to be. The tradeoff is that this model tends to reward students who already have (or quickly acquire) the ability to think in types, representations, and invariants—so the “best practices” can look like gatekeeping when encountered without the surrounding mathematical or CS enculturation. Perhaps that is one reason why Python and JavaScript became dominant languages of our time: they scale socially as teaching media and as generalist glue languages, even if they externalize some forms of consistency into tooling, testing, and conventions rather than the type system.

  If we take the CCS angle seriously, the question is not “which first language is best,” but what kinds of subjects each language helps produce: what sorts of habits, values, and implicit worldviews are cultivated when we treat discipline-first (Oberon/Pascal) versus legibility-and-feedback-first (Python/JS) as the default entry point—and what gets naturalized as “real programming” in each case.
• jeremydouglass

  January 19 edited January 20

  While thinking about Oberon and pedagogical programming, I looked at Programming in Oberon: Steps Beyond Pascal and Modula (1992) and found this excerpt in the Preface (p.vi):

  The Oberon language was purposefully designed to serve as an implementation tool for the Oberon system, an efficient, concise operating system founded on object-oriented programming. The language, however, is not tied to the system - compilers can be provided for any machine under most current operating systems. Programming in Oberon therefore requires no knowledge of the Oberon system, and digresses only minimally into a discussion of Oberon system concepts.

  This a questions for me when thinking about the specific pedagogical example from page 84: defining the procedures Root(), Sin(), and Min() and understanding how to call them correctly. In fact, for the purposes of the textbook exercise we assume PROCEDURE Sin(x: REAL): REAL; (we do not define it), and the calls Sin(3.14159); or a := Sin(x1); are proposed (we do not invent them) -- we instead attempt to align the concepts of procedures and their inputs with syntax. Understanding the exercise is abstractly aligned with prior mathematical knowledge (e.g. 3.14... need not be explained in this context), in the context of this insistence that the language is "not tied to the system." Perhaps, just as math concepts are abstracted from notation systems, such as "Root" or "√", so programming languages are (properly) abstracted from operating systems.

  Yet, as Moritz Maehr points out, Oberon "was an exercise in total system design—language, compiler, OS, and hardware conceived together as mutually shaping parts of a single technical culture." Philosophically and practically, then, how does Oberon (or how do we) reconcile the tension between the "total system design" of the hardware-OS-language-program stack, on the one hand, and the "not tied to the system" ethos of explicitly pedagogical programming languages, on the other. For me, this tension is rooted in how pedagogical programming (in the sense of the Programming in Oberon subtitle "Beyond Pascal and Modula") may value (among other things) simplicity, elegance, and the easy portability of what is learned to other contexts (which is to say, platform-independence, both practical and conceptual) -- i.e. a promise that the learner may reap future benefits through skill transfer.
• markcmarino

  January 19

  This snippet is fantastic for showing how Wirth taught the language he made to be taught. I wonder if other examples from the code base might give us other avenues of interpretation. Since the source code is only 9K lines, I thought I'd do some reading of it with code and together landed on two examples that might offer something for discussion.

  First of all, I was drawn to this quote from Wirth:
  "The belief that complex systems require armies of designers and programmers is wrong. A system that is not understood in its entirety, or at least to significant degree of detail by a single individual, should probably not be built."

  And so I used that to drive my search with Claude. What follow is a mix of my language but mostly Claude's reply. I'd offer that these examples make material rhetorical code arguments for Wirth, thinking of Kevin Brock's work on rhetorical code studies.

  The first example comes from Modules.Mod.
  Modules.Mod is the entire dynamic linker/loader for the Oberon system. It:

  • Searches for already-loaded modules
  • Loads compiled code from files
  • Recursively loads dependencies
  • Allocates memory (with hole-reuse for freed modules!)
  • Copies type descriptors, variables, strings, code, commands
  • Performs three-phase address fixup (procedure calls, data references, type descriptors)
  • Initializes modules by calling their body
  • Handles reference counting for safe unloading

  It's 180 lines of code.
  For comparison:

  • Linux ld.so: ~50,000 lines
  • Windows loader: estimated 100,000+ lines
  • macOS dyld: ~30,000 lines

  the fixup loop:
patching branch instructions to point to imported procedures. The compiler emits placeholders; the loader fills them in. The entire algorithm is 12 lines

  oberon
  (*fixup of BL*)
  adr := mod.code + fixorgP*4;
  WHILE adr # mod.code DO
    SYSTEM.GET(adr, inst);
    mno := inst DIV 100000H MOD 10H;
    pno := inst DIV 1000H MOD 100H;
    disp := inst MOD 1000H;
    SYSTEM.GET(mod.imp + (mno-1)*4, impmod);
    SYSTEM.GET(impmod.ent + pno*4, dest); dest := dest + impmod.code;
    offset := (dest - adr - 4) DIV 4;
    SYSTEM.PUT(adr, (offset MOD 1000000H) + 0F7000000H);
    adr := adr - disp*4
  END ;
  

  Kernel.Mod: Memory Menager
  Garbage collection:

  PROCEDURE Mark*(pref: LONGINT);
    VAR pvadr, offadr, offset, tag, p, q, r: LONGINT;
  BEGIN SYSTEM.GET(pref, pvadr);
    WHILE pvadr # 0 DO
      SYSTEM.GET(pvadr, p); SYSTEM.GET(p-4, offadr);
      IF (p >= heapOrg) & (offadr = 0) THEN q := p;
        REPEAT SYSTEM.GET(p-4, offadr);
          IF offadr = 0 THEN SYSTEM.GET(p-8, tag); offadr := tag + 16 ELSE INC(offadr, 4) END ;
          SYSTEM.PUT(p-4, offadr); SYSTEM.GET(offadr, offset);
          IF offset # -1 THEN (*down*)
            SYSTEM.GET(p+offset, r); SYSTEM.GET(r-4, offadr);
            IF (r >= heapOrg) & (offadr = 0) THEN SYSTEM.PUT(p+offset, q); q := p; p := r END
          ELSE (*up*) SYSTEM.GET(q-4, offadr); SYSTEM.GET(offadr, offset);
            IF p # q THEN SYSTEM.GET(q+offset, r); SYSTEM.PUT(q+offset, p); p := q; q := r END
          END
        UNTIL (p = q) & (offset = -1)
      END ;
      INC(pref, 4); SYSTEM.GET(pref, pvadr)
    END
  END Mark;
  

  “Schorr-Waite pointer reversal marking”
  a non-recursive graph traversal that uses the object graph itself as its stack. It's a notoriously tricky algorithm. Wirth implements it in 25 lines.

  The Scan procedure that reclaims memory is another 25 lines. The entire garbage collector is 50 lines of code.

  For comparison:

  • Java's G1 GC: ~100,000 lines
  • Go's GC: ~15,000 lines
  • V8's GC: ~50,000 lines

  How well do these code snippets make Wirth's point? Is Wirth like Oberon in A Midsummer Night's Dream saying, ""I am invisible." (Act II, Scene 1), watching us appreciate his argument? Do these succinct sections omit any necessary functionality? Do they depend overmuch on particular hardware? Are they sufficiently legible?
• millstein

  January 20

  @moritz.maehr Very well said. I agree with your points. I would say the big dichotomy there is between dynamic and static typing. I've always come down on the side of the latter for education, until my experience starting about a decade ago teaching students with no prior experience. There I saw firsthand the value of being able to write and run code quickly, including partial programs, nonsense programs, etc. We need students to not be afraid to try things and to have languages that support easy exploration. The lightweight syntax of Python also helps but I think that is very secondary (as you said, JS can also work well for many courses).

  At the same time, for my own programming and any "real" project, I would always use a statically typed language for the discipline and guarantees that it provides. So those are things that are very important to introduce later. But they just get in the way in an initial course, add cognitive overhead (to understand compile errors and how to fix them), and they are also not very well motivated until you've experienced firsthand the problems that they are addressing.
• yves_baechtiger

  January 21 edited January 21

  Hi Mark,

  (Disclaimer: This post are my thoughts but polished by Claude, as English is not my native language. Technical details are to the best of my knowledge but only superficially researched due to time constraints.)

  Thanks for your post - it got me thinking. Some thoughts, not to argue against but to dig into what "simplicity" really means here.

  On the Comparisons

  I wonder if the systems being compared serve fundamentally different purposes, which might make simple line-count comparisons a bit misleading.

  Linux's ld.so handles:

  • Multiple executable formats (ELF variants, versioning)
  • Thread-local storage across architectures
  • Security hardening (Relocation Read-Only (RELRO))
  • Dozens of CPU architectures
  • Backward compatibility spanning decades

  Oberon's loader targets a single architecture (the custom RISC-5 32-bit processor, if I'm not mistaken?), a single file format, no threading (originally?), no security model, and a controlled ecosystem where all modules are compiled with the same compiler.

  Similar story with garbage collection. Java's G1 handles concurrent collection across dozens of threads, pause-time guarantees, generational hypotheses, and more. V8's GC deals with JavaScript's dynamic object model, hidden classes, inline caches. Oberon's collector is stop-the-world, single-threaded, with a simple type system.

  Not to diminish Wirth's achievement - but does lines of code, without accounting for scope and requirements, tell the whole story?

  The Appeal (and Limits?) of Simplicity

  The Wirth quote scratches an itch I often have: the idealism of simplicity. I can see its value in an educational context - which was clearly Oberon's purpose.

  But here's what I keep wrestling with: Is simplicity a fundamental property of good design, or mainly a concession to human cognitive limitations? Physical systems tend to become a dumpster fire as soon as you leave linearity. So how seriously can we take simplicity as an objective criterion versus just an aesthetic preference?

  On a tangent: This reminds me of debates in fundamental physics about a "theory of everything" - the hope for one elegant formula describing the universe. Reality or wishful thinking?

  A Logical Tension?

  The statement "A system that is not understood in its entirety... should probably not be built" seems to have a tension. Taken literally, it would rule out for example:

  • The Internet (does anyone understand TCP/IP + BGP + DNS + HTTP + TLS in their entirety?)
  • Operating systems running on diverse hardware
  • Databases serving millions of concurrent users

  Wirth's Oberon was beautiful precisely because it rejected requirements that modern systems must meet. That's a valid design choice - but is it evidence that systems embracing those requirements shouldn't exist? Curious how others see this.

  Since we're talking about simplicity as virtue - this also makes me think of the "Clean Code" crowd (Martin Fowler, Robert Martin, etc.). Some of these principles can get a bit doctrinal: pursue readable, simple code, sometimes sacrificing efficiency. I still have flashbacks to professors during my studies preaching this stuff like gospel

  Casey Muratori's "Clean" Code, Horrible Performance is a good counterpoint. When does chasing simplicity become its own kind of dogma?

  Would be interested to hear what others think:

  • Where's the line between "elegant simplicity" and "not enough for the problem"?
  • Is simplicity objective, or does it mostly reflect human cognitive limits?
  • How do we square Wirth's philosophy with the success of systems no single person fully understands?
• jeremydouglass

  January 22

  Thinking more about Oberon's pedagogical code has me asking: How should we approach pedagogical code examples in general -- whether the examples from Programming in Oberon (1992) or related examples that our 2026 CCS Working Group is currently looking at in the Scribe User Manual (1978) or in "Your Friend, the EXEC" (the Intellivision OS manual).

  Code examples which are pedagogical as they occur in the primary source may be initially challenging entry points for critical code studies analysis. This is something I have observed anecdotally over a number of working group conversations, and I am reflecting on why that often seems the case for pedagogical code specifically. In the discussion last week on "Where is the Critical in Critical Code Studies?" I gestured to the broad traditions of cultural studies as they developed in the 20th century and as they may be applied to computer source code. Part of that cultural studies tradition is to interpret the non-obvious meanings of artifacts, such as implicit, obscured, convert, or subliminal meanings. While this is not the only form of cultural criticism, it is a broadly shared starting point that the object of analysis is taken to be more complex than it appears on its face. We see this in everything from semiotics to psychoanalysis to deconstruction to Foucault-on-power.

  When the tradition of unearthing the non-obvious runs head-on into pedagogical examples it encounters overt (that is, intentionally obvious) secondary meanings which the learner is tasked with discerning. In this sense, pedagogical code is like the literary genre of allegory: the surface meaning of source code and execution has overt secondary meanings, and these are generally expressed within the context an equally overt philosophical worldview. So, while cultural criticism might be used to leading the interpretive dance by suggesting non-obvious secondary meanings, in pedagogical code (as in allegory) criticism may need to follow along for the first few steps to avoid trodden toes.

  What does this particular code pedagogy looks like in Oberon -- on its own terms, or in the context of its historical milieu, or in comparison or contrast with current code pedagogies? In the case of example 6.2, the part of the question about e.g. Sin() is not about computing the sine at all -- and overtly so. The meaning is not in the computation but in appropriate syntactic forms. That material is in the chapter itself, but at the end of Programming in Oberon we find it more concisely: not a list of exercise answers, but "Appendix A: The programming language Oberon," a language reference with extended Backus-Naur Form(alism) syntax descriptions of each element. In section "A.9.2 Procedure calls" we get the EBNF for a procedure call:

  ProcedureCall = designator[ActualParameters]
  

  This, combined with the EBNF for assignment (designator ":=" expression), gives the syntax conventions that determine whether e.g. Sin(3.14159); or a :=Sin(x1); are correct "statements containing procedure calls", and we can apply these in checking each proposed statement.

  Behind the explicit syntactic "meaning" to the code snippet is the more general concept of the procedure. Beyond that, a further latent meaning of the exercise is its role in the learner's ongoing assimilation of a computer language design philosophy. In the case of Oberon part of that philosophy is that being precise and specific is the key to communicating the intention of code, thus making code 'worthwhile'. If some of what preceded this seems not just pedagogical but pedantic, Programming in Oberon gives a spirited defense in Preface p.ix: "Pedantry in programming is not a luxury, but a necessity." It continues:

  Students on most programming courses are given the impression that the essence of programming is to concoct code that causes a computer to operate in a specific fashion. While this may be true for typical commercial endeavors, we maintain that ultimately a program is worthless if it cannot be understood by other human beings. Its formulation must be chosen with the goal of providing the conviction to human beings that it satisfies its purpose. Every program should be a publishable design. This is a far cry from the usual goal that the 'program runs'!

  We can at least assure the reader that a notation which encourages the programmer to be precise and explicit is indispensable for approaching this goal. Oberon is such a notation.

  In what sense is a :=Sin(x1); "precise and explicit", or indeed "as simple as possible, but not simpler"? What might it mean for a procedure call to be "providing the conviction to human beings that it satisfies its purpose"? A next step in addressing such questions might be to consider contrasting programming languages -- perhaps with different design goals, or perhaps with similar ends but dramatically different means. Another next step might be to consider these design goals in broader cultural contexts such as in technical communication, design, science, law, philosophy, art, rhetoric... or pedagogy. If pedagogy, we might consider human conviction in the procedure in terms of Aristotle, Quintilian, Augustine, Comenius, Locke, Rousseau, or Pestalozzi... or in terms of trends in university and computer science education in the 1970s and 1980s.

  That might be a good point for the code allegory to stop leading the dance, and for cultural criticism takes the next step.
• aschwarz

  January 22

  Oberon: procedure interfaces, parameter modes, and strict typing (1992)
  @moritz.maehr
  12 Jan

  "... positioned Oberon as a deliberate reduction: fewer features, stricter discipline, radical simplicity."

  When you say "deliberate reduction" are you refering to both Pascal and Mudula II?
  Why was reduction desired or necessary?
  1. There are differences in needs for the system's programming and application developmed. System's programming requires very fast execution with a small memory footprint. Application programming usually is more generous in both counts, but enjoys more features.

    2. One justification for a reduction of features in systm's programming is that compilers can not produce efficient code and small memory footprints. Was this the justification for a reduction?
  
    3. One goal of a language supporting application development is to reduce the SLOC required to effect some application. A general precept may be that a feature-rich language reduces the code required and maay enhance both space and speed.
  
    The need for reduced Source Lines Of Code (SLOC) in an en environment is that each line of code takes a finite amount of time and mulitplying this amount of time by the total lines of code, or expected code, adds to the total time for delivery and, since time equates to cost in a commercial environment, the cost of delivery.
  
    It would seem that even in an academic environment a needs based design would indicated a language with increased functionality would be desired. Of course, there are limitation to what increased means but considering only the issue at hand, why was the same language desired for both system's and application development given the underlying needs are different?
  
    As a counter to reduced capability in any environment, I would add that Hewlett Packard's HP 3000 had a system's development language, SPL, Unix had C, and the Burroughs B5000 series had Algol. All were feature rich languages, for their time and place. So, what was the ratioale for reduction in language capabilities?
  

  "... correctness, safety ..."

  An attempt to define a language which increased the code quality and reduced defects (correctness) and enhance safety was done in the development of Ada. Except for the mandate (that Ada be used on all DoD projects unless a case was made and approved to use another language) there were few if any non-DoD projects developed in Ada. As a professional programmer it appears to me that "correctness" is best achieved by good design at the architecural and programming level, good tools used at the programming level, and adequate testing. The issues are language invariant. In any language used you achieve your goals by means of other than the language.

  In an academic environment the focus shifts. The emphasis on code safety and correctness is one taught in class but I suspect seldom used by students. Ada is a language which systematically employs linguistic sugar to promote code safety and correctness, and these are just the features which cause difficulty in coding. A language specifically designed to produce 'good' code which programmers have difficulty using. But, if the goal is academic I suspect it would be idea. Why wasn't Ada used? Or Modula II?

  The requirements of a language used as a teaching tool are different from that used in a production environment, and on this basiss I would think that Pascal would have been adequate. So this issue is, what advantages did Oberon have as a teaching tool over not held by Pascal or Modula II though it was more geared to a software production environment. And why was a language developed to support academics used to build an operating system (OS)? It would seem that the linguistic support for OS development are contrary to that needed as an academic tool. I take, for example, C which allows direct access to computer addresses, for example, memory mapped I/O registers, and uncontrolled pointers. Both of these interfere with the notion of teaching code correctness and safety but are essential for building an OS using a high level language.

  "... single person might plausibly comprehend ..."

  Could you expand on this? For example, there are production environments with over a million lines of code. In this context what does the statement mean? In the same way, Oberon was used to develop an OS, which is a complex piece of software. In this context what does the statement mean?

  "o What is the purpose of this language and who is this for?"

  Could you provide some framework for this? Where languages are developed for specific needs, and you have mentioned academic needs below, they have different characteristics. As the requirement to satisfy new needs develop both new languages are created and old languages 'refurbished', with with the additional of new Applicatioin Programming Interfaces (API's), built-in language features, and language syntax changes. So the question becomes in which framework is the question to be answered?

  You have mentioned two conflicting environments in which the language is placed, OS development and a teaching tool. As I attempted to illustrate, a language developed for OS development provides constructs anathema to teaching in that little sense is played on code correctness and safety and more on speed and space and I/O access. The caveat, not mentioned above, is that if the language is not suitable in some category of use, then there is a slide back to development in assembly language. And if assembly language lines of code are too large we would say that the language is not suitable for OS development.

  Let's look at some environments that a language can be asked to support and some languages which are used (given in no particular order and the list is a far cry from being complete):

    1. OS development: Algol, C, C++, Modula II, Oberon, SPL.
    2. Academic: Pascal, Oberon.
    3. Multiplatorm execution: Java, HTML, javascript, Perl, Python, Interpetive languages in general.
    4. Grpahics: C#, C/C++, Java.
    5. String Processing: Snobol/Spitbal.
    6. Stochastic simulation: Simula.
  

  The issue is that different objectives can require different languages. Although, as a truism, most languages can be provided with sufficient API's to accomadate different needs, the question is which language's synatx and semantics directly support the requirement of different models of development. So, in which environments do you want Oberon to be compared in?

  And withal, do you want to consider normal coding (software engineering) practices? For example, the Oberon examples given have few if any comments. In a normal, almost universal, production environment this would be rejected by the Quality Assurance department. It is a poor, poor, poor practice to deliver code without commented the code's goals and/or features and/or algorithms. None of which has been done, leaving the audience the task of divining meaning, algorithm, functional purpose, and evaluating satisfaction in achieving the goals. And there is the issue of naming conventions. 'x' is a remarkably uninstructive name.

  There is no attentiaon to current coding practices in any code fragment (see Mark Marino's code fragments). As such, and until corrected, there seems little probative value in considering Oberon as an instructive tool in an academic environment.

  @michalfalk
  13 Jan

  "It is quite common to trash the idea of studying algorithms today."

  I don't know what you mean by "algorithms", but I would take strong exception to this. The current paradigm is LLM. This is an algorithm requiring (I am guessing here) and understanding of statistics, lingustics and other fields. If you mean a class on algorithms, as for example consisting of a knowledge of lists, string processing, hashing algorithms, perhaps numerical processing, and etc., I believe that is part of the undergraduate required classwork. Perhaps you can elaborate.

  "... falling enrolments in HASS ..."

  This is indeed a tragedy. But I believe it an historical issue. Graduates in HASS have few, if any, opportunity to use their knowledge in getting productive or fulfulling jobs, and like it or not, jobs and money given to workers are required to clothe, house, and feed an individual.

  This is a societal problem not just one seen at a given time or place. Let me give an example from the Vietnam war. If you graduated in a scientific field (engineering, mathematics, physics, etc.) you were given a pass to find a job. If you graduated in a HASS class, you next opportunity was in Vietnam. This was resented by those majoring in HASS who protested, en mass. And that was a societal choice in saying what benefited society, in this case, war, and what did not.

  The Vietnam experience both preceeded Vietnam and followed it. If you get perfect scores (4.0) in your classes in HASS, you might get a job related to your degree. Otherwise you get opportunities at Costco or Starbucks.

  This in no way is meant to minimize or deprecate HASS. Where would we be without poetry and plays, Aristotle or Sartre. We devolve into a state of incomprehesion without HASS.

  "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."

  I would add that, as George Santayana said, "Those who cannot remember the past are condemned to repeat it". In this regard I would opine that people in 146 B.C.E are the same as people now. Motivations and approaches are the same, and form the cultural entaglement. The Socialogical and historical context in comparison to the now and the recent historical past might well be placed in the same study curriculae.

  @MarkMarino
  19 Jan

  "What does Oberon offer that Pascal did not?"

  Pascal was widely accepted and appreciated as a good language, good enough, indeed, that efforts were made to extend the language to make it commerical code friendly. Sutible for removing it from the classroom and putting it into a production code environment. That has not been the case with Oberon.

  Computer languages, like cultures or societies, change in time. Oberon shows a regression to the 70's in that it doesn't appear to offer any significant functional or operational advancement. It seems to be something that says, "the past was not good so I can make the past better", rather than, "the past was not good so I will meld past good things with current good things". The language suffers from a past hangover, not showing advancement in concept but only change of syntax.

  @moritz.maehr
  19 Jan

  I am a professional programmer, and just curious. In looking at the spate of devlopers over the years I have many with knowledge of a languague(s), but few with adequate knowledge of program structure or system architectures. Are these taught?

  Let's take a case, either in the commercial world or academia. You know a language, and are reasonably facile in it. You are faced with a problem of unknown where at the outset you have little knowledge of the programmitic requirements to achieve a good end. What do you do? How do you approach the problem using the knowledge you have, until you reach the point where you need more information? Is this taught or is the student made to struggle?

  My personal feeling is that with a few development guidelines taught in beginning classes, the student will be better able to address 'hard' problems given after. This acts to the benefit of both student and staff. The studend learns, and the professors can extend the amount of subject taught.

  @markmarino
  19 Jan

  "A system that is not understood in its entirety, or at least to significant degree of detail by a single individual, should probably not be built."

  There are systems with over a million lines of code. There are systems with over 100,000 lines of code. I think the quote needs some qualification if it is be assumed to be accurate. These large systems often include many disparate parts, think electronic engineering, mechanical engineering, space propulsion systems, radar, spectrum analysis, etc. all within the same program. Taking the quote to heart implies that the reader at the least knows about these subjects. Attractive as it appears that there is a renaissance man, it probably is not true. Therefor let me amend. Each part of a large system should be graspable, leaving ambiguity as to what a large system, what a part is, and what is being understood. Without qualifications the quote does not stand.

  "It's 180 lines of code."

  The claim being made is that in LInux, the functionality contained in 50,000 SLOC is is written in 180 SLOC of Oberon code. What this implies is that the Linux code solves the same problem with the same functionality as Oberon, but that it is subject to code bloat. The premise is doubtful. The issues not addressed are what functionality is done in Linux and does this same functionality, or the need for it, exist in Oberon.

  For a nonce let's consider one aspect of Linux. Linux is developed around the idea that the raw code will be in a number of different computers, with different capabilities, and different hardware. The Oberon code is specific to one computer, one operating systems, and a single view of object models, link models, load modules, memory, and OS. At primitive level the code solved by the two systems is not the same.

  At the detail level there are other considerations, one of which is that if the input load modules are faulty, then this is detectable, bypaassed, and the operating system (or other systems) will not fail. The code as shown does not check it's input. It assumes correcness, which leaves the question whether such checks are made outside this little nugget of code.

  loader module (12 SLOC)

  There is one comment "(fixup of BL)". What does this mean? What's a "BL"? Why does the comment say "fixup"? Is this the loader?

  Why isn't the code required to produce "fixorgP*4" includled? What is this?

  Basically, there is not enough information in the code to determine what the code objectives are nor with what fidelity these objectives are met.

  "Garbage collection"

  No comments. Everything said herein is guess work.

  "SYSTEM.GET(pvadr, p); SYSTEM.GET(p-4, offadr);"

  I assume, bassed on the name, that pvadr is pointer to a structure. What is structure definition?

  ---

  There are two major types of garbage collection (GC)"
  1: Space is not owned by the runtime kernel. The runtime kernel can coalesce space but is unable to rearrange space. That is, if two pieces of freed space are adjacent, the kernel can combine them into a larger space. This can be done when the application frees space (as in C/C++). This usage implies that the language execuable is directly executed.

  2. Space is owned by the runtime kernel. This allows the kernel to rearrange all space so that all used space is separated by all free space, that the free space is unfragmented. The runtime kernel adjust all references to used space. This is done in languages such as Java and C#, under managed software. This usage implies that the language executable is interpreted.

     Where is the documentation which specifies what algorithm is chosen? The choice indicates the 'efficiency' of the operating system. If interpreted the OS is slow. If directly executed, then up to the compiler, the OS is fast.

  "The Scan procedure that reclaims memory is another 25 lines."

  The syntax is close enough to C/C++/Java that this algorithm can be recoded in one of these languages and take about 25 SLOC. Clearly that is not the issue. The claim is that these 25 lines have the same functionality and use in the Oberlin OS as the 100,000/15,000/50,000 SLOC has in the other systems. This is highly unlikely. Plus, there are calls to procedures which haven't been counted, and there is an OS, with some potential functionality, which hasn't been counted, and so on. The 25 SLOC here and the additional 25 SLOC in the sweep algorithm (memory reorganization and reclamation) represents some small part of a bigger picture and can not be judicially used as a comparison unless it's larger framework is included.

  I will say that the code fragment appears to only encapsulate the marking procedure in a mark and sweep algorithm, see line 20 "END Mark;", not the entire job.

  "How well do these code snippets make Wirth's point?"

  In terms of the syntax, it is pedestrian not showing the elegance of Pascal. As @moritz.maehr said on 19 Jan, he teaches programming using Python. Python is an interpretive language and has weak typing. Also, Ada has strong typing and can be nightmarish to code. So the issue of strong typing being an asset is a question.

  As stand-alone code fragments they are as instructive or non-instructive as similar fragments from other languages in text books. In other words, the fragments illustrate code use and are as exceptional as seen in other books.

  In the current time, the use of captilization (of keywords) is jarring. Using the context of social media, it is as if someone was shouting at me, demanding my attention. It takes one back to the good old days of the card punch machines that did not have lower case. A pedagogical negative.

  The indentation seems erratic and non-representative in GC, se lines 6 and 7 where 7 is indented, indicating a contained code block, where line 6 contains an addendum (q := p;) which should properly be at line 6.5 rather than at line 6. Sloppy coding.

  @millstein
  20 Jan

  Dynamic typing is used in interpretive languages, static typing in non-interpretive languages. I personally like static typed languages but there are instances that using dynamic typing has some advantages. So, I agree, and I would also add that in a pedagogical environment, dynamic typing has some disadvantages. Yes, it makes it easier to teach a language which does not have a fixed type, and yes you can probably make rather severe, hard to find, errors easily.
• anthony_hay

  January 22 edited January 22

  Quoted by Jeremy:

  Students on most programming courses are given the impression that the essence of programming is to concoct code that causes a computer to operate in a specific fashion. While this may be true for typical commercial endeavors, we maintain that ultimately a program is worthless if it cannot be understood by other human beings. Its formulation must be chosen with the goal of providing the conviction to human beings that it satisfies its purpose. Every program should be a publishable design. This is a far cry from the usual goal that the 'program runs'!

  We can at least assure the reader that a notation which encourages the programmer to be precise and explicit is indispensable for approaching this goal. Oberon is such a notation.

  A few thoughts.

  Most people can hold more than one idea in their heads at the same time: it needs to run and it needs to be understandable as well.

  I have found things that worked useful, even though I didn't understand them. Things that don't fulfil their purpose are less useful, whether I understand them or not.

  Of course, it's more likely to be correct if it's understandable.

  There are more ways of killing a cat than choking it with cream.

  I pride myself that I could write obscure, wrong, inefficient and bad code in any language.

  Who are they to judge whether my program is worthless or not? Do they know what was in my head at the time, what constraints I was under?

  @yves_baechtiger

  Anything taken to extremes tends to the ridiculous.

  Saving CPU cycles is saving the planet (i.e. less CO2). But sometimes it just doesn't matter whether something takes 1µs or 100 to produce the wrong answer. One uses one's judgement. (And use tools to tell you where to spend your time optimising.)

  @markcmarino

  My initial reaction to that “Schorr-Waite pointer reversal marking” Oberon code you quoted: I didn't find it easy to understand. If I was immersed in the culture of that project maybe it would be obvious to me. But what is p and q? Why p-4, p-8, tag+16?

  Here is a JAVA implementation of the Schorr-Waite algorithm from some random web page:

  public void mark( HeapObject startNode ) {
    HeapObject current = start;
    HeapObject previous = null;
    HeapObject next = null;
    HeapObject old = null;
    startNode.setMark(true);
    while (current != startNode || startNode .hasNext ()) {
      if (current.hasNext()) {
        final int nextChild = current.getIndex ();
        next = current.getChild (nextChild );
        if (next != null && !next. isMarked ()) {
          // forward scan
          urrent.setChild(nextChild , previous );
          current.incIndex ();
          previous = current;
          current = next;
          current.setMark(true);
        } else {
          // already visited or no child at this slot
          // proceed to next child
          current.incIndex ();
        }
      } else {
        // backward
        final int ref2restore = previous.getIndex () - 1;
        old = previous.getChild (ref2restore );
        previous .setChild(ref2restore , current );
        current = previous;
        previous = old;
      }
    }
  }
  

  Compared to the Oberon example, this has readable names, consistent indentation and more informative comments, amongst other things.

  I'm struggling to get to the other side of yes, and...

  I think that asking "what is the purpose of this thing" and "does this thing fulfil that purpose?" is important. And asking "why was that purpose chosen and not another" may also be important. And that's about as far as I go.