[btilly]

Your argument is the same as the arguments that higher level arguments cannot be faster than assembly.

In theory, any optimization available to a compiler is also available to an assembly programmer. In practice humans do not match automation. This has been demonstrated both in theory and practice for decades.

There is no limit to the level of language that this argument could theoretically apply to. In practice the run-time guarantees and programmatic indirection that we demand in high level languages make the task insurmountable for current programs. But never underestimate what can happen with a good compiler and the right program.

[kevinnk]

> "In practice humans do not match automation." Actually in practice human's almost always surpass automation mostly because they can start with automated output and improve upon it.

[btilly]

Humans can do that. But in practice we don't seem to.

Instead the trend mostly seems to be that we do it by hand until automation becomes good enough to do it better than we were doing it, and then we move on to harder kinds of problems and let automation do its thing.

I say "mostly seems to be" because there are plenty of counter-examples. But that's the general trend. As is seen by the explosion of programmers working in what used to be considered unbearably slow scripting languages, and the relative lack of people doing traditional assembly programming.

[kevinnk]

"In practice humans do not match automation." Maybe this is a nitpicky argument, but to me this means one thing: when put head to head, humans do not do better than automated output. This is wrong for exactly the reason I said. In 99% of cases you start out with an unoptimized version, find the areas that need optimizing, and improve the automated output by hand. Thus in practice and in theory humans almost always beat automated output. The general trend of people working on higher level problems isn't because automation can do low level stuff better, it's because automation can do it well enough for most cases that we don't need a human to step in. Automation isn't doing better than what a human would do, but it is doing well enough that there's no need to go back and optimize it.

[btilly]

In 99% of cases you start out with an unoptimized version, find the areas that need optimizing, and improve the automated output by hand.

This strongly depends on the scenario.

If people are identifying and optimizing a hot spot, it tends to happen this way, yes.

But what I am thinking about is the common situation where a company produces a product in a low level language, and then later on a competitor produces a competing product in a high level language. The second entrant is optimized by an automated process, the first was done by hand, and can't easily be rewritten.

In these situations - and I have encountered several - the second implementation frequently winds up doing more and doing it faster than the first implementation.