> Small functions and higher-order functions are the most natural candidates. (The two categories greatly overlap in most cases.)
But then you're just guessing. Isn't that also inelegant?
Let's play devil's advocate: how do you decide the cutoff on function size for inlining? Well, you would profile a bunch of programs with various cutoffs... now all you have is a heuristic, and MLton will inline some functions that it shouldn't, and it will fail to inline other functions that it should.
It will do worse than a JIT at this, because the JIT has more information.
> That knowledge can be encoded statically in many cases, if only you used the right languages.
Sure, but you won't ever succeed in encoding all of it, which is why runtime techniques can have a place.
> This is only the case when your program wasn't close to optimal to begin with.
That's simply untrue, and you can prove that formally -- given a machine M and a program P that produces outputs on a set of inputs I, it is always possible to come up with a program P' that produces those outputs with fewer steps on some subset of I, in return for taking more steps on the rest of I (except in the trivial case where the running time is completely independent of input).
You can view a JIT as iteratively replacing P with P' after it sees which inputs I are most common, and this is true no matter what M, P, or I are. In particular, there exists a version of P' that is faster than the statically optimized version of P on your program's input.
> Yes, but languages amenable to static analysis will actively get in your way if you try to write such obfuscated code.
I don't see how that isn't equally applicable to writing code to fool your JIT.
> So. basically, you're telling me to ditch Java's entire library and framework ecosystem?
Framework code doesn't generally run inside your inner loops, so I don't see how that should affect either your AOT or JIT compiler much.