Facebook's "HipHop" PHP translator

code like:

$x = 1;
$y = 3;
$z = $x + $y;

Then sure, it can use type inference. When you have something like:

function foo($x, $y) {
return $x + $y;
}

Then the compiler has no freaking clue what is going to be passed in.

Generally, I find, people do not create variables to hold static values,
but instead they tend to hold data from various other sources, many of
which by PHP semantics simply cannot have their types inferred. Some code
can be highly optimized by such techniques, some cannot, and the latter
just happens to be more common in at least the apps I've worked with.

Unless the compiler is compiling multiple versions of these functions (like
how a tracing JIT compiler might), then most of the code in a real-life app
(not a micro-benchmark) is going to be inelligable for type lowering, and
the runtime has to fall back on full dynamic type semantics.

This is one reason that, no matter what advances the dynamic language folks
working on JS or Python or whatever might possibly make, the speed of a
statically-typed language can always be greater by just using the same
techniques the dynamic runtimes use but without the type guards (for
tracing implementations) or dynamic fallbacks.