I don't think what people are saying here is that the languages are too abstract, it's that compilers are implementing those abstractions with too much overhead

I don't think what people are saying here is that the languages are too abstract, it's that compilers are implementing those abstractions with too much overhead. Most compilers (i assume) optimize by applying specific optimizations to patterns they find in the source. most of the time this is pretty good compared to non-optimized code. but the other day on HN i learned about polyhedral compilation, which is pretty crazy of an optimization. it got me thinking: what about all the optimizations we don't know about? is it possible to find the absolute best optimization for a program given some specifications of what we want from it? I think an ideal compiler would brute-force optimize like this so we don't miss out on optimizations we didn't think of: 1: compile the code normally without optimizations 2: generate a binary [see note1], and test if it produces the same output as the binary from (1)[see note2] 3: sort through the binaries and choose the best ones (perhaps some binaries are more optimized for speed, size, etc so there may be tradeoffs) note1: here are a couple ways i think you could do this, in order of practicality: A: modify the binary from (1) a bit at a time B: modify the binary from (1) X bits at a time, or any of the other binaries from (2) that passed the test, more likely to modify binaries that perform better in the tests. C: iterate through every possible binary up to around the size of the binary from (1) note2: the easiest way to implement this would be to test it with a ton of sample input, but it would be better if the binary could be analyzed somehow to see if it satisfied the parameters of the source code. I wouldn't use a such a brute-force optimizer to actually produce code which would then be undefined, but you could use it to reverse-engineer optimizations and implement them in source code. edit: formatting