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.
back
1 comments
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.
> when it is something else, it is thrown around as proof they aren't as good as C for systems programming
That's not my position, and not my argument in this thread. My argument was, that Wirth created his own world and never cared about industry requirements, so industry cared for themselves.
But let me address your concerns. C is an ugly language with a silly syntax (e.g. for arrays, or function types), and the preprocessor is a nightmare, and the weak type checking overlooks a lot of errors (but at least we get warnings, and weak types are very useful when I use C as an IR). But the standard version (ANSI) lets me do all things I need for system development; I don't use inline assembler.
So let's look at Modula-2 (since you seem to see it as Wirth's response to industry needs). First, we have to differ between Wirth's Modula-2, and ISO Modula-2, which is a completely different language (more industry friendly, containing things Wirth was strictly against, and he even refused to participate). So let's stick with Wirth's Modula-2. The first thing that annoys me is the requirement of the original 1982 specification to capitalize all keywords. The second thing is the removal of any type checking for all operations essential for low-level system programming (a pattern Wirth continued in Oberon). ADDRESS is declared as POINTER TO WORD, and the specification doesn't define whether pointer arithmetics has byte or WORD resolution. Type casting is very limited (i.e. restricted to SYSTEM.TRANSFER or variant records without tag, but not in expressions). There is no conditional compilation and only limited compile-time evaluation. There is no explicit "extern" declaration; the use of definition without implementation modules is inofficial and compiler dependent. Some of these issues were "fixed" in ISO Modula. But if I compare Modula-2 e.g. with Ada, which is indeed a true system language explicitly designed for critical industry needs, even ISO Modula is still very limited.