> One cannot let the user play with the addresses, and use procedures, and play with pointers--which is pointing to the data--and be able to understand how one can transform the program to run more optimally."

Well 50 years on we still haven't seen any of these "sufficiently smart compilers", at best they can outsmart C compilers in a few cases with things like generics, so the idea that higher level languages would be faster has been wrong for at least 5 decades. At least you can forgive them for thinking they would 50 years ago, but now it's just ignoring 50 years of reality.

Unfortunately, this assumes everyone is a master at C and that we are comparing straight line speed. In the real world, higher level languages have a much better comparison since everyone's C program has their own slow, buggy "standard" library instead of the hyper optimized ones of higher level languages. One of the major reasons why that is the case is because C, at a language design level, makes building those kinds of high level, interesting, performant, and safe APIs hard

> In the real world, higher level languages have a much better comparison since everyone's C program has their own slow, buggy "standard" library instead of the hyper optimized ones of higher level languages.

In the real world we've pissed away 30 years of hardware improvements primarily through switching to higher level languages. In the real world higher level languages are still not used we're performance counts (like games). In the real world low level languages like c and C++ are still powering our most important and fundamental projects.

In real world politics also count higher than techinical capabilities.

Source, replacing GUI and distributed applications written in C and C++ with managed languages (AOT and JIT) for the last 20 years.

Funny, I remember when there were books like The Zen of Assembly programming, because C compilers just generated junk code.

I also happen to remember languages like Fortran and Ada do exist.

She's exactly right. I'm really not sure how we came to accept the worse-is-better argument that high performance required exposing machine details into the source language, and letting compiler writers just "do whatever is fastest", regardless of safety. It gave rise to today's situation where none of application writers, library writers, kernel writers, or compiler writers are quite sure what will happen if a new optimization is introduced. Will it break programs? By how much? Well, let's roll the dice! This is a direct result of allowing--no, even expecting--programmers to peer behind the curtains to see machine details that they frankly, shouldn't. It's why porting programs from one machine to another is even a thing, as opposed to just selecting a different output from a compiler, or running a different VM.

Proper abstractions define exactly what happens in every situation, and design unobservable details out. It is the basis for optimizations that fundamentally cannot observed (except side-channels, like timing and other resource usage). Proper abstractions is why we have fast processors. The ISA is a hard boundary.