But if those types are not final, you don't know the dynamic subtype of concrete values (and the concrete methods to call) in advance, and you're forced to do the same kinds of optimizations that Javascript does. Seriously, look at current VM tech again. Type feedback and speculative inlining are of legal drinking age in the US by now.

By using all the usual methods, which are identical to those that Java VMs use? It's the identical problem.

And lack of constipation causes global warming. We're screwed either way, it seems.

"The west" started Chinese air pollution? So the smog around Chinese cities is our fault? They must be really desperate for excuses...

Well, it's a Completely Open Computer Kernel.

Of course, how else would you suggest to build a high-performing implementation of JS? These days, just about everyone is using either the Self-93 implementation model or something suspiciously similar. (BTW, technically, *all* Javascript functions are anonymous functions, it's just that some of them happen to be bound to global variable names, very much like in Scheme. Optimizing the calls of anonymous JS functions is no different from optimizing calls to any other JS functions.)

Unless they get inlined, type-specialized, yada yada yada...

Very respectfully.

Clang has some builtins that allow you to get the carry bit, so you can cheaply write code that branches on carry. We (mostly CERT, I helped a bit) had a proposal for inclusion in C11 that would have added qualifiers on integers explicitly defining their overflow behaviour as trapping or wrapping, along with a model that let this be implemented cheaply (e.g. allowing a set of side-effect-free code to propagate temporary results and only trap if one of them along the way overflowed). Sadly, it didn't make it into the standard.

Both get executed wherever you run them. Most web sites today don't have the bargaining power to convince users to run client-site java, though, even though many of them run it server-side.

As I mentioned below, you might be interested in this (at least cherry-pick-some-ideas-wise).

Not necessarily. C++ has a fixed semantics for its method dispatch, one that is fairly bizarre in any case.

They were not laughable. There just wasn't enough of economical and environmental incentives back then to push for their mass production. Now there is.

So you're saying that the bulletproof way of making something complicated work is to employ people who did something simple that worked? I'm really not sure what your sentence is supposed to mean. I would have thought that future technological results depend mostly on inherent problems with the goals that we're not aware of yet.

I find it hilarious that the supposed downside of having a future-proof source of energy is that on the unlikely occasion that a terrorist group gets their hand on plutonium, the resulting threat is going to be in the 50kt class instead of 20kt. Any larger entity most likely wouldn't have a problem with generating it for themselves anyway.