Ada is in every aspect a much bigger and more powerful (e.g. concerning the ability of the compiler to assist you in writing safe low-level code) language than any of the Wirth languages. Wirth famously criticized Ada as being "uneconomical"; he believed that because Ada’s requirements were so "baroque" and contradictory, the resulting language was inevitably overloaded with features whose marginal benefits did not justify their complexity (https://archive.org/details/Computer_Language_Issue_09_1985-...). But when you e.g. study the Oberon system, you see that it depended on "tricks" (e.g. SYSTEM.PUT/GET, VAR ARRAY of SYSTEM.BYTE) which were not properly integrated in the language concepts and had to be used without any typechecking support by the compiler.

I have now read more of the book on oberon, and confess that I lost traction. It seems very clear that he is using objects, and my bias against them is very strong. I have heard it said that both oberon and plan9 are beautiful, but completely different.

I'd be interested in your take on the two of them, when, if, each of them should be used, and why. I am currently attempting to install plan9/9front/9legacy et. al. I understand that oberon, being much smaller, could be very useful for learning purposes, but if you don't actually approve of OO, then.. is it really the kind of thing you want to be teaching people. Obviously, you want people to see a bit of everything, just so they are aware of alternate ways of doing things. At the same time, most people will assume that the first thing you show them is the way you actually want them to do it, and will tread the alternatives as what you present them as, curiosities, potentially useful. So, if the objective is plan9, then what would actually be needed would be a .. well.. a tutorial for plan9. A tutorial that gradually built the operating system, explaining the logic step-by-step. There -is- actually at least one tutorial that does such a thing, that I am aware of, but what it takes as it's inspiration, I haven't checked out yet. This is the one: https://os.phil-opp.com/

I'm not familiar enough with Smalltalk-72 or what Ingalls did that makes it so different from the Smalltalk-80 that Cox read about in Byte.

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

If you are doing whole-system development and have control over the entire thing (a "closed world" system), then it is that simple. But whether it's an open world or a closed world changes things.

Cox is fond of a simple example that he repeats in his book (fairly early on—it's on something like page 9) to demonstrate that dynamic dispatch is fundamentally necessary because it means you don't have to have panoptic control/involvement over the objects in a system (with all types known at compile time). If you're programming every operation with switch statements that select code paths based on objects' type tags, not only do you have to go visit all N routines where each of those N operations are implemented to update them when introducing a single type, but it also requires a priori knowledge of all types to be baked into the system that you release at the time of release, whereas OO on a live system means that you can introduce new types even after the initial system has shipped to the user.