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.

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.

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