Item — HN Reader

> One could argue that Modula-2 was an attempt to fix Pascal for the industry

There is no evidence that Wirth e.g. ever directly or specifically rebutted Kernighan's famous paper, nor that Modula-2 was a response to it. Modula-2 was a child of the ivory tower (PARC), not industry. Wirth was rather an "escapist" who built his own worlds rather than fixing the real one. He saw Parnas' concepts "in action" during his sabbatical at Xerox. He didn't create Modula-2 to help industry; he created it because he wanted to replicate the Alto workstation experience (which became the Lilith) for his own use and for his students at ETH. Wirth was a brilliant "synthesizer" of academic ideas (Parnas, Hoare, Mesa) who built beautiful, self-contained gardens for himself and his students. He was never the "industrial repairman" that later apologists tried to paint him as.

1 comments

Why should he?

That paper was only relevant among UNIX people, and largely ignored by anyone doing 8 and 16 bit home computing with Pascal and Modula-2.

It is no accident that to this day, it is the UNIX accolades that keep bringing it back every couple of months, most of whom never used a single Pascal compiler in their lifes, or aware that Modula-2 was already around.

Modula-2 relevance as systems language is quite easy to find out in some of his essays, and the companies selling compilers for Acorn, Amiga and PC.

You said that "One could argue that Modula-2 was an attempt to fix Pascal for the industry". By 1981, the C/Unix team was no longer a "rogue research group" in a closet; they were the architects of the dominant industrial paradigm shift (with Apollo Computer, Sun Microsystems, Silicon Graphics, and even Microsoft all using Unix and C). That's why I mentioned it. Wirth didn't care because his concern wasn't industry. Pascal users helped themselves: e.g. Lisa Pascal essentially included all features from C, which according to Kernighan (who referred to Wirth's original Pascal, not the derivatives) were missing, and even a module and separate compilation concept (four years before Turbo Pascal); they could have used Modula-2, which was around at the time. While Modula-2 was hypothetically a "systems language", it lacked the pragmatic "dirty" features that C, Lisa Pascal, and Turbo Pascal embraced to actually build operating systems and drivers on commodity hardware (unless, again, they were added as an extension by the compiler vendors). E.g. Topspeed Modula supported inline assembly, Acorn Modula included extensions to call software interrupts directly with register mapping; almost all commercial vendors added extensions to bypass strict typing, or direct pointer increment/decrement to support C-style array traversal.

It is irritating that apparently C is fine having endless compiler extensions without which ISO C is equally unusable to implement an operating system[0], a sign of greatness, while the same argument is used to point out as design flaws when it isn't C we are talking about.

[0] - Unless helped by an external assembler, just like on the UNIX rewrite, when K&R C was initially created.

I'm not advocating for C (I wouldn't implement an Oberon/Pascal/Modula inspired C replacement otherwise). C was mostly adopted by industry because it came with Unix and had to be used by the many Unix-based workstation vendors to adapt and extend the OS for their specific need/brand. That a significant OS can be written in C without extensions is demonstrated by the many Unix versions themselves. There is always a remainder which has to be implemented in assembler (e.g. to achieve the system state required to run C functions at all). I can also confirm from my own long-time experience implementing embedded (microcontroller) systems in C that it is possible with standard C. But that's not the point. We were discussing about Wirt's minimalism and his focus on his own and the need of his students (vs. the need of industry). I think Wirth's role and influence are generally romanticized. He was innovative, but he did his own thing. The impact of his work on the industry is almost exclusively in a significantly modified/extended form. These extensions/modifications never came from Wirth himself, and only in exceptional cases did they have “his blessing” (e.g., Object Pascal or Modula-3). It was precisely his aforementioned minimalism that led him to focus on the things that were important to him, rather than on the needs of the industry, whether justified or not.

Sure, if we ignore the Assembly buddy code used alongside C.

IBM's OS/400 made use of Modula-2 for some parts, for example.

Back to Niklaus Wirth, as mentioned initially, I think his ideas were great, until he went into minimalism, the first Oberon edition was the turning point, that other researchers luckily improved upon.

Ironically to his point of view, some of them, like Hanspeter Mössenböck, changed his focus into Java and .NET, and has contributions to MaximeVM and GraalVM, via his students thesis.

I'm not sure what you're getting at with this recurring assembler argument. The Oberon system and also AOS/Bluebottle are full of inline assembler and SYSTEM tricks with pointer arithmetic, etc.; the Lisa OS is also full of assembler. Even Wirth himself wrote parts of the Ceres system in assembler.

Indeed they are, however when it is C, it is an advantage, gladly ignored that ISO C on its own requires an external Assembly tool to do its job, when it is something else, it is thrown around as proof they aren't as good as C for systems programming, the irony of two weighs, two measures.

"You need Assembly to do XYZ that C can do", yeah right.