Well, see my other comments: JVM makes such assumptions about the code being run that anything actually interesting is difficult to implement on top of the JVM. And that includes interesting dynamic languages, namely Common Lisp, Scheme, Self, Smalltalk.

That's mighty nice, but I'd expect people with higher CS degrees to work chiefly as researchers, not as security hole pluggers. Unless of course their CS specialization was principled security bases on formal methods, in which case they could actually replace a large number of the security hole pluggers.

Arstechnica quotes some unnamed Google guy. Haven't looked at ARChon yet. But implementing an Android runtime for Chrome in PNaCl is a no-brainer, now that Android's native ART runtime uses LLVM bitcode somewhere inside (which "coincidentally" is what PNaCl can consume, with some limitations). You just have to provide some API libraries for to link the Android app against.

They're already doing something like this with YouTube videos, aren't they? (I.e., have an army of people adding human judgement to the workflow of processing various requests.) I guess that's just a cost of doing business, like having an accountant.

Uh, wasn't this the whole point of it? I thought that this is exactly how it was supposed to work.

AMD64 is at least sufficiently low-level that implementing multi-word arithmetics on top of it is fairly transparent and doesn't incur any unnecessary run time costs.

If you have "a bootloader as a part of the OS", I think you're sitting in front of a hypervisor/VM system. ;-) Otherwise the things you just said make little sense to me.

Actually, the "non-bright" person who came up with Javascript based it on Self and Scheme. If only we had more such "non-bright" programmers! The problem was that the design had to be fleshed out basically over a weekend or two, thus causing virtually all the mistakes that were basically impossible to fix since then.

Actually, it's based on exactly the Native Client environment that you said hadn't caught on. :-p

Of course, if you write an emulator for it, anything can be run on the JVM. That doesn't mean it will run at a usable speed.

But they can't. They either have to look sufficiently like Java in order to be able to run on it, or they have to resort to complicated translation strategies to pretend that they look sufficiently like Java. For example, one of the hallmarks of Smalltalk is the #become: operator that causes an object to be replaced by another object of any class (including fixing all the references to the object from anywhere if it can't be replaced physically in place). That's no problem in a dynamically typed language (the new object just has to provide adequate behavior, and of course you have to know what you're doing) but JVM simply doesn't have any such operation. (A similar thing goes for the CHANGE-CLASS operator in Lisp, or any other operation tweaking existing objects such as redefining a class to add instance fields to all existing objects of some class.) Thus "implementing Smalltalk on the JVM" basically means "implementing a sufficiently castrated dialect that omits anything that can't be done on the JVM " (at least everything that can't be emulated efficiently).

What invokedynamic gives you is allowing you to tweak the dispatch mechanism in a limited way. While sufficient for Python for example, it's still useless for Lisp. It still also requires the use of some complicated translation strategies because it still doesn't make Java objects look like Python dictionaries (with objects of the same class potentially having different instance fields).

They're sufficiently close to Java to be runnable on the JVM provided that the developers of the runtime engage in reasonable flesh mortification. That's not the case with many languages. And what's the point of using a different language if it's not providing you any differentiating features?

Meaning that it easily supports (without unreasonable overhead) execution of pointer-based languages such as C, or multiple-inheritance languages such as C++, or dynamic languages (with hash-like objects) like Javascript or Python, or multiple-dispatch languages such as Common Lisp/CLOS, or languages with restartable exceptions such as (again) Common Lisp, or languages with lazy evaluation strategies such as Haskell or Scheme, or languages with continuations such as Scheme, right? Oh, wait, it doesn't - it has fundamental assumptions about how the language running on it should work! Well, guess what, going for a lower-level VM and simulating a virtual CPU removes a lot (even if not all) of these assumptions. That's the whole point of why LLVM was created.

There's no way in which a non-browser client-side application is more reliable or secure than a client-side application in the browser. That is, unless you deliver it as some kind of tamper-proofed USB dongle with its own processing resources (and perhaps even then).

Of course you would.

Except that in fmt, you can actually write your own combinators, whereas FORMAT is hardcoded, and - frankly - smells of the "let's make fun stuff A, B, C" syndrome (Yeah, spelling out numbers in English is fun...unless you're Chinese. Or German. Or Russian. Or French. Or pretty much 80% of the world. See where this is heading?) I'm not really sure what you mean by "copied built-in iteration constructs" when fmt doesn't look in any way similar to FORMAT, even though both...wait for it!...format stuff. Yeah, from that POV, they're "sort of similar". Both format stuff. That's about it.