Item — HN Reader

Raymond argues in the referenced book that while OOP has value in specific domains, its benefits have been oversold and its typical usage often conflicts with the core Unix philosophy of simplicity and transparency. I think that's a valid position, and hyping and overselling is a continuous fad in the programming industry, which is famously susceptible to what Fred Brooks called the "Silver Bullet" syndrome: the desperate search for a single magical technology that will solve the inherent difficulties of software engineering. The "simplicity and transparency" Raymond champions are indeed virtues, but they are also slogans used to rally a specific community. Just as "Memory Safety" is the rallying cry for Rust today, "Small is Beautiful" was the rallying cry for Unix in the 1970s.

The industry seems to advance not by finding a static "truth," but by lurching between opposing philosophies, each powered by its own wave of activism. I recommend to ignore the "moral" arguments, but to focus on the engineering trade-offs. Most "revolutions" are just rediscoveries of old ideas. Functional Programming is largely Lisp (1958) re-branded. The "Anti-OO" movement is partly a return to procedural modularity (Pascal/C). Our job is not to be "pure"; your job is to build working, maintainable software using the best tools we can find for the specific problem at hand.

2 comments

Greetings again..

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/

> my bias against them is very strong

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.

"Why?"

Because of what Raymond said. He said two things that I remember fairly clearly:

1) If you have to resort to OO to solve your problems, you probably have another unresolved problem at a higher level. This is from near the beginning of the book.

2) OO succeeds mainly by increasing the global complexity of the problem.

All I'm doing is answering your question. It is true I wasn't totally clear about this. It is very clear that you understand his detailed logic better than I do. Reading the rest of your post now.

Ok, I see. Raymond wrote this in 2003, at the peak height of "Java OO madness" where deep inheritance and over-engineered, totally inefficient systems were common. In The Art of Unix Programming, Raymond clarifies that he isn't against "objects" as a conceptual tool but against the "gospel of OO" that dominated the 1990s. His main argument is not that OO is inherently "evil", but that OO designs often become "spaghetti-like tangles" of inheritance hierarchies that hide logic behind "thick layers of glue". He represents the "Unix Philosophy", which is a specific culture, and he was writing to defend this culture against the rising tide of Java and C++, which he saw as a threat to the simplicity and "text-based" interoperability of Unix. Interestingly, Wirth’s Oberon and OO approach actually aligns well with much of Raymond's philosophy. Raymond would certainly agree that OO is just one of many tools in the toolbox of an engineer, and our job is it to chose the right tools for the job.

Well, we basically agree on how I should go about it, which is good :-)

Jehanne is now on my radar..

"Should be cast in bronze" comes to mind.