You appear to want him to have different goals for these languages than he had. That they don't have mass adoption is fine. It's not their primary value.
That said, "death" is too harsh, all the time there are multiple implementations of both Wirth-derived (the most prominent being Delphi, which is still being developed and sold) and "pure" Wirth languages available and in use. If anything, I find it more remarkable that they've been seen as much adoption as they have outside of teaching. There's even a very expensive commercial ARM implementation of Oberon-07.
It's in any case largely irrelevant to the question of their appeal.
I don't want to work in Oberon (or Pascal) any more than you do (but, to tie it back to this article, I also don't want to work in C++ unless I have to), but in terms of distilling lessons of what is needed from a language, and a learning tool, it is up there with Smalltalk and Lisp (other languages I don't want to work in) as one of a small handful of the language designs that will continue to influence for a long time to come.
And that is a large part of their appeal - not for day to day use, but for the lessons you can learn from them. I don't care if nobody uses them. I care about the research they contributed to and spawned, and what I can still learn from them.
> and removed stuff like enumeration types and variant records.
Oberon replaced variant records with extended types, type tests, and procedure variable (function pointers), sufficient to do OOP. In terms of his goal of focusing on sticking to the bare essentials, it was a good tradeoff, and it sparked novel work.
> I don't want to work in Oberon (or Pascal) any more than you do (but, to tie it back to this article, I also don't want to work in C++ unless I have to), but in terms of distilling lessons of what is needed from a language, and a learning tool, it is up there with Smalltalk and Lisp (other languages I don't want to work in) as one of a small handful of the language designs that will continue to influence for a long time to come.
Other languages did simplicity better without sacrificing expressiveness by allowing natural extensions of the language. Wirth languages, by being Algol-derived, are overly-complex syntactically in ways that make them non-extensible, and possess ill-considered semantics on top of that.
I really don't see Wirth in reality as a huge influence in the history of programming language design. All of Wirth's languages are in essence tweaks on ALGOL from which they all (starting with ALGOL-W) were derived. What's so new about any of Wirth's languages, even Oberon? OOP had already been done 20 years prior in Simula, as well as more recent pre-Oberon languages.
He certainly left his mark on the computer industry in terms of products based on his work, but would, say, a hypothetical "Turbo Algol" have been much different than "Turbo Pascal"? The popularity of Turbo Pascal (& Delphi) really had more to do with the implementation (speed, IDE, language extensions) than the base language itself.
> I really don't see Wirth in reality as a huge influence in the history of programming language design.
C# is influenced by Pascal and Modula-2 because Anders Hejlsberg had a huge hand in creating it.
Go and Lua are also quite heavily influenced by the Wirthian languages.
Ada is also a direct descendant of Pascal and Modula-2. For a while in the 80's, Ada was more popular than C++ because of the DoD standardizing on it but the DoD and NASA still use it today. NASA's Artemis project uses Ada. The Canadian air traffic controls system all run Ada.
Wirthian languages have been focused on safety for 50 years. The industry is just now catching up with safety-focused Rust as a first step. It's long overdue. C and C++ were dangerous enough offline but using them online is just asking to get hacked. Sure, safe code can be written in them but not many C and C++ programmers are capable of doing so. Why wouldn't you want a language that handled the bulk of that for you?
C# is really managed C, and the C lineage is more ALGOL -> BCPL -> B - > C
Sure Ada saw some success, and is even a pretty decent language, but I fail to see that there is much Wirth in there, certainly not his minimalist aesthetic!
Lets not forget that Wirth was on the ALGOL design group, and Pascal was initially designed as it saw ALGOL as being too complex for teaching purposes.
So there is a little bit of Wirth on ALGOL as well.
I don't believe Wirth was involved with any of the official ALGOL versions. He submitted his own proposal for an ALGOL-60 replacement which was rejected and became ALGOL-W (Wirth), which I briefly used in college c.1979. The actual successor to ALGOL-60 was ALGOL-68 which Wirth had no input on.
There's a useful language family tree on the WikiPedia ALGOL page. ALGOL is really the grandfather of all modern structured programming languages. I guess the way it was named "Algol = Algorithmic language" about says it all.
> What's so new about any of Wirth's languages, even Oberon?
You've been given the answer already: Simplicity. You keep ignoring it.
Both of implementation (which can be met by e.g. Smalltalk, Lisp, Scheme, Forth as well), and of usability (which some might argue the former could, but the reality is most people have gravitated towards languages closer to the ALGOL family for usability).
And yes, it's "tweaks" on ALGOL, but those tweaks mattered, in terms of simplifying implementation. ALGOL users expected gc (though it was not technicall required), Pascal users didn't (though it wasn't forbidden). ALGOL's added complexity around type checking of variants mattered. ALGOL's file IO was bizarre (giving me horrible flashbacks to Simula's equally broken IO), and ALGOL 68's definition of formatted IO took up several dozen pages of the spec... ALGOL supported user defined precedence rules for operators, which, while it's not hard to implement is significant added complicity vs. a typical hardcoded recursive descent parser for Pascal, Modula-2 or Oberon.
Having used Simula (it was compulsory for CS classes at my university way back), the OOP in Simula is really quite different and at a far higher complexity level than Oberon.
Another comment listed influence directly on languages. But the influence on languages is far broader in terms of the simplicity of the languages being a facilitator for an explosion in language designs. It was seeing the ENBF for Pascal that got me to start experimenting with parsers and compilers, for example, because the simplicity made it clear that it was possible for a hobbyist to create their own from scratch. The existence of simple Wirth-language compilers made experimentation easy - I spent too much of my teen years looking at compiler source, and the Pascal compilers were easy to understand and modify. I wrote my first expression parser in Pascal, and my first code generator, and soon I ended up bootstrapping my own Pascal-inspired language.
Simplicity matters.
It's easy to forget that now when we have decades of hardware progress and orders of magnitude more RAM and CPU to work with, and decades of additional books and resources on how to build compilers using methods that were computationally infeasible at the time.
The existence of very simple compilers and languages has also been part and parcel of a lot of work at ETHZ that is not part of the Wirth languages themselves, but that was enabled by having access to simple languages as a foundation. Personal favourites of mine is work such as Franz' work on Semantic Dictionary Encoding, which led to his work on JVM JIT's etc.. Franz' student Andreas Gal came up with trace trees [1]. Brandis did fantastic work on showing a wide range of optimisations could be added to Oberon at a fraction of the complexity of the similar optimisations in gcc at the time. Mossenbock and Brandis did excellent work on SSA generation. Franz did simple but excellent work on protocol extension (dynamically propagating method overrides at runtime; I used parts of that in my experimental/unfinished Ruby compiler). There were many more. Some undoubtedly would have happened with more complex compilers to work on as well, but if you read the reports and dissertations from that period at ETHZ you also see plainly the influence that Wirth's approach carried over in the students subsequent approaches and focus on simplicity.
> a hypothetical "Turbo Algol" have been much different than "Turbo Pascal"?
It would have been slower and too big, and so lost a significant part of what made Turbo Pascal important.
In terms of implementation being more important, the speed etc. of Turbo Pascal depended heavily on the simplicity of compilation. Being able to keep the source, the compiler, the editor and the compiled object code in memory at once was a big deal facilitated by the extreme simplicity of the language.
Well, OK, and I certainly can't refute personal experience even if I don't totally understand it.
I played with C parsers (using my own parser generator ... written in Modula-2 as it happens) back in '82 and never found the grammar overly intimidating. Of course you're familiar, but just do a quick scroll up and down to remind yourself of the length (or lack of it):
And it seems 25% of that is the expression syntax which really would be better (more efficiently) handled outside of the grammar via precedence climbing (which would also neatly handle Algol's user-defined precedence), and which would result in a smaller parser as well as faster one.
As far as I/O, not sure that Pascal had too much to crow about there ... you could open files, but not close them, no way to associate a filename with a file, a need to put any non-temporary file as a program parameter, the odd file buffer variable concept, with an equally odd syntax treating file types as if they were pointers to the element type...
A language that fascinated me at the time, but I never got to play with was Occam - designed specifically for the Transputer which was really way ahead of it's time and never caught on.
That said, "death" is too harsh, all the time there are multiple implementations of both Wirth-derived (the most prominent being Delphi, which is still being developed and sold) and "pure" Wirth languages available and in use. If anything, I find it more remarkable that they've been seen as much adoption as they have outside of teaching. There's even a very expensive commercial ARM implementation of Oberon-07.
It's in any case largely irrelevant to the question of their appeal.
I don't want to work in Oberon (or Pascal) any more than you do (but, to tie it back to this article, I also don't want to work in C++ unless I have to), but in terms of distilling lessons of what is needed from a language, and a learning tool, it is up there with Smalltalk and Lisp (other languages I don't want to work in) as one of a small handful of the language designs that will continue to influence for a long time to come.
And that is a large part of their appeal - not for day to day use, but for the lessons you can learn from them. I don't care if nobody uses them. I care about the research they contributed to and spawned, and what I can still learn from them.
> and removed stuff like enumeration types and variant records.
Oberon replaced variant records with extended types, type tests, and procedure variable (function pointers), sufficient to do OOP. In terms of his goal of focusing on sticking to the bare essentials, it was a good tradeoff, and it sparked novel work.