Designers had ignored both the issue of efficiency and that a language serves the human reader, not just the automatic parser. If a language poses difficulties to parsers, it surely also poses difficulties for the human reader. Many languages would be clearer and cleaner had their designers been forced to use a simple parsing method.

> as someone who actively studied the field,

Does not compute.

Your comment is mere empty verbiage with no information.

We've successfully found some strong patterns for structuring programs that transform data in various ways for the kinds of programs Wirth was imagining. The best patterns have proven themselves by being replicated across languages (for example discriminated unions and pattern matching) and the worst have died away (things like goto and classical inheritance).

There's still work to do to find better languages though. A language is good if it fits the shape of the problem and, while we've found some good patterns for some shapes of problems, there are a lot more problems without good patterns.

I had hoped there'd be more languages for everyday end-user problems by now. At the start of the SaaS era it seemed like a lot of services were specific solutions that might fit into a more general modelling language. That hasn't happened yet but maybe a programming language at just the right level of abstraction could make that possible.

What's so wrong about classical inheritance, and how it died away while being well-supported in most popular programming languages of today (Python, C++, Java, C#, TS, Swift)?

In a sense, it’s like global variables. About every complex program [1] has a few of them, so languages have to support them, but you shouldn’t have too many of them, and people tend to say “don’t use globals”.

[1] some languages such as classical Java made it technically impossible to create them, but you can effectively create one with

  class Foo {
    public static int bar;
  }

In some Java circles, programmers will also wrap access to that field in getters and setters, and then use annotations to generate those methods, but that doesn’t make such fields non-global.

This I can agree with, but it is far from being "worst pattern". Everything can be like salt.

  for (i = 1; i <= 100; i++) {
    S;
    if (P) {
      break;
    }
  }

Gotos get a bad rep because they become spaghetti when misused. But there are lots of cases where using gotos (or break/continue/early return/catch) makes your code cleaner and simpler.

Part of a programmer's job is to reason about code. By creating black and white rules like "avoid gotos", we attempt to outsource the thinking required of us out to some religious statement. We shouldn't do that.

Gotos can be useful and can lead to good code. They can also be dangerous and lead to bad code. But no "rule of thumb" or "programming principle" will save you from bad code.

(FWIW, this is essentially the argument that Knuth makes in his defense of goto paper)

https://miasap.se/obnc/oberon-report.html

1. To use it in teaching a structure programming course to new students. As in the late 60's all student programming was batch mode (submit your program to an operator to run, and pick up the printout the following day), this meant the compiler had to be single-pass and give good error messages.

2. To use it in teaching a data structures course involving new data structures worked out by Wirth and Hoare.

3. To use it in teaching a compilers course. This meant the compiler code had to be clean and understandable. Being single-pass helped in this.

https://gcc.gnu.org/onlinedocs/gcc-15.2.0/gm2

Even available on compiler explorer to play with, https://godbolt.org/z/ev9Pbxn9K

Yes, that was a common trend across all programming languages designed by him.

That is also how P-Code came to be, he didn't want to create a VM for Pascal, rather the goal was to make porting easier, by requiring only a basic P-Code interpreter, it was very easy to port Pascal, a design approach he kept for Modula-2 (M-Code) and Oberon (Slim binaries).

I think it was more that it would be easy to write a compiler for, which meant that CS students could write one. Don't have a source for this that I can remember, though.