I'll start. Assertion: A lack of feedback (or an "immediate connection", as Bret Victor would say) makes it difficult to reason about how a program will behave as it is being written or changed.

Assertion: Most programming languages give users too much "freedom" over how a program can be architected, and when many poor choices are possible, poor decisions are easily made.

Assertion: Text-based programming tools are an inappropriate foundation for the kinds of GUI apps that people often need to write!

Etc. Feel free to challenge any of these assertions or add your own.

and I do agree with the significance of the problems you've listed

Draft #2 of my argument 1. The way programs are written affects their trajectory as projects. If they're written poorly then they die sooner, or at least they grow senescent sooner, unable to react quickly in response to changes in their environment. (People who disagree with this will assume everything we talk about is just pointless yak-shaving.) 2. If you want to come up with a new way to write programs that gives them better trajectories, it still has to be written in today's context. So it doesn't have access to itself. So it is liable to turn into a mess itself, to not last long enough to change people's minds. (Because changing people's minds will take time. Maybe a generation.) As a consequence of these two assertions, I think before we can run we need to take some baby steps. We need to gradually minimize our dependency on -- and eventually wean ourselves from -- the current stack. We have to keep our new stack easy to rewrite. Keeping it rewrite-friendly requires first that we encode all design choices, so we (or those following us) are never wondering what will break if they change this into that. This seems far more important than whether they get immediate feedback on making the change once they've decided it's worth doing. Once we have a stack that is supple and rewrite-friendly arbitrarily deep into its life, I think it'll be far easier to layer on new interfaces that give us immediate feedback, try to move past text, and so on. It'll still take a lot of code, but we'll have the primitives to do a far better job managing large codebases. (Every month or two I daydream about an immediate-feedback text-mode UI for developing both an OS and an application atop it. So far I've successfully resisted the temptation to get side-tracked into that project.)

I generally disagree with your assertion that to improve programming tools we need to iterate on the status quo. People have been doing that for decades now. Even if the intentions are pure, it seems likely that no revolutionary ideas will end up being realised, in the name of "pragmatism". I feel a better route is to start by inventing something revolutionary, and try to make it compatible with the status quo.

Aside: I think this is another example of where Slack's threading model is insufficient. We're (fairly) derailing the conversation away from the original prompt I've given.

It’s really effective (and a multibillion dollar company) because, I would claim, that is the level at which people think about visualization, and it’s a programming model that matches that level of abstraction. That’s why systems like Spark have won out over traditional HPC systems like OpenMPI as well, since they provide primitives that better match the language of the domain (distributed list processing).