Ask HN: Oberon et al., vs. Rust

It is unlikely that the two would have agreed on this. Kay's view is actually based on messages, as implemented in Erlang, for example, and to some extent in Smalltalk-72. Cox, on the other hand, has implemented the object and dispatch model of Smalltalk 80, that Ingalls invented and published in 1978, almost exactly, even with the same method lookup caching.

> Cox's book uses this example a lot as a poor/insufficient substitute for dynamic dispatch.

The Wirth and Smalltalk approach are both fundamentally "late-bound search" mechanisms, differing mainly in whether the search state is optimizable by a central engine (VM) or fixed in the user's explicit control flow (Handler). This is a classic example of dualism in computer science, specifically the Expression Problem (or the Data/Operation duality). You are simply traversing a 2D matrix of (Types × Operations), just choosing a different axis as primary. It's mathematically isomorphic, both are performing a directed graph traversal to find the code that matches (CurrentType, CurrentMessage). Only the ergonomics and possibility for caching differ. Smalltalk hides the dispatch loop in the VM, which can do caching and the dispatch effort goes from O(N) to O(1) in time. Wirth exposes the dispatch loop in the WITH statements with a dispatch effort continuously O(N).

If you're interested in the difference between Smalltalk versions, I recommend Ingall's most recent paper: https://dl.acm.org/doi/10.1145/3386335. In contrast to Smalltalk >= 76, ST-72 had no bytecode, but sent tokens (synchronously) to object instances for parsing (which was called "message passing" by its authors).

> If you are doing whole-system development and have control over the entire thing, then it is that simple

The dispatch mechanism and the described duality is the same, whether whole-system or not.

> Kay's view of OO is a matter of "open world" versus "closed world"

Smalltalk was always a "closed world" (you are always in the same image, but code can be compiled on the fly at runtime), and all calls were synchronous. Since the Oberon compiler and system treats each module as a dynamic loadable entity and supports loading by name, it actually supports the "open world" approach. Interestingly, Kay's view is likely best represented in Erlang, where there are true messages sent asynchronously.

> If you're programming every operation with switch statements that select code paths based on objects' type tags

As mentioned, Oberon traverses the "2D matrix" from the other side. Each module may or may not handle a message in a WITH (i.e. switch by type) statement, but modules per se ar dynamic. So the "a priori knowledge" only applies to the message type.

Why? OO is just a tool like any other (e.g. functional etc. programming). From an engineering perspective (where engineering is essentially the art of solving problems using technical means), making a fundamental a priori decision for or against a particular tool makes little sense.

Oberon and Plan9 are indeed completely different. Oberon is in addition both a programming language (with OO features) and an Operating system (using those features). I wouldn't "use" either. Both are very valuable for studying and experimenting. Oberon excels in "minimalism" ("write a decently complete operating system with very little effort and means"), while Plan9 is the "spiritual successor" of Unix which refined existing concepts and added innovations (e.g. for multithreading and inter-thread communication). The answer to your questions depends on your specific situation. If you're a student then I would recommend to optimize your time for what you would like to do professionally later. Universities tend to be "ivory towers", feeding students a lot of stuff for historic or "academic" (i.e. random preference and interest of the professors) reasons with little respect for "efficiency" (i.e. usefulness per hours spent). Basics are very important, but the "basics" which you learn at universties in "computer science" are rather overrated and not very useful for most people, in my humble opinion. I would recommmend to read books and experiment with different programming paradignms and languages, if you want to go for a programming career How operating systems work is mostly important if you want to build them yourself professionally or do low-level programming like OS drivers or embedded systems. My answer is therefore somewhat more general than you might have hoped for, but it depends greatly on where you are now and where you want to go.

If you want a 'step-by-step tutorial' like the phil-opp blog, Oberon is actually closer to that experience. The 'Project Oberon' book literally builds the compiler and OS from scratch. Plan 9 is different; it's a production research system, so you learn it by reading the source and man pages, not by building it.

Jehanne is now on my radar..