Contemporary PL designers who have inspired my programming language design journey the most are people like Chris Granger (Eve), Jamie Brandon (Eve/Imp/others), Bret Victor (Dynamicland), Chris Lattner (Swift / Mojo), Simon Peyton Jones (GHC/Verse), Rich Hickey (Clojure), and Jonathan Edwards (Subtext). My favorite researcher is Amy J. Ko for her unique perspective on the nature of languages. Check out her language "Wordplay" which is very interesting.

very hot and edgy take: theoretical CS is vastly overrated and useless. as someone who actively studied the field, worked on contemporary CPU archs and still doing some casual PL research - asides from VERY FEW instances from theoretical CS about graphs/algos there is little to zero impact on our practical developments in the overall field since 80s. all modern day Dijkstras produce slop research about waving dynamic context into java program by converting funds into garbage papers. more deep CS research is totally lost in some type gibberish or nonsense formalisms. IMO research and science overall is in a deep crisis and I can clearly see it from CS perspective

> and the worst have died away (things like goto and classical inheritance)

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)?

They are just gotos, but does that mean that they are bad (along with their friend try/catch, who is also a goto?), or does that mean that gotos can be useful when used with restraint?

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.

I seem to remember (but I can't find the source) that Wirth initially had three aims in designing Pascal:

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.

Nowadays you can enjoy it on GCC, as it is now an officially supported frontend, after GNU Modula-2 got merged into it.

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).

> most easily compilable

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.

That's an argument against references isn't it? Rather than shadowing.