Yorrrick

Compilation method isn't what's going on here. Static type systems are, as explained in the article.

Whatever consciousness is, it's not obviously required for an AI to start manipulating its surroundings to its advantage, which is one if the fears here.

I'd willingly pay that price if it delivers on what they said in the marketing. But it appears we'll have to wait.

Many people live in places where summer and winter are different, and they happen at the period of a year.

The "necessity" of those extensions is debatable, and they meant that code wouldn't be portable to Sun's implementation. There was real cause for concern, and there weren't a lot of other options for fixing it.

Sun probably also realized that they weren't about to compete directly with mighty Microsoft on platform lockin of all things, so they played a different game.

To make a complete platform, you also need APIs, so there's more to it than just picking a language. You also need to figure out how to sandbox it; CINT appears to give programmers access to unrestricted pointers. You also want to get multiple browser vendors to agree, so some kind of specification is desired; CINT targets its own unstandardized subset of C. And you ideally want it to go fast, but CINT appears to be pretty slow:

http://benchmarksgame.alioth.debian.org/u32/compare.php?lang...

So there'd be some work to do. You could also compile the code, but complete C compilers are not fast, in browser terms.

I call it silly too. While also admiring many of its ideals.

The argument suggested in the article is that harvesting plants also kills insects.

There are enough differences to warrant using different abstractions when appropriate. RAM never fails. Or, it never fails in a way that application code is expected to handle. RAM is cached, and cache is so fast that accessing small amounts of it is often negligible cost, and there's no need to count round trips. RAM is far less likely to be the connection point between different versions or implementations of an application. Are some examples.

There is a cause I believe in pationately, but somehow not everyone sees it the way I do. Do you think it's ok for me to use hyperbole, if I'm sufficiently convinced I'm defending the right viewpoint?

It's simple. "Bytecode" is just a kind if encoding. The only thing it does is make programs marginally smaller and marginally quicker to decode. It's not enough to justify enormous switching costs. Let's talk about what functionality this new thing should have. That's where the high-value opportunities are. But, it's also where there's no easy consensus.

Also worth mentioning the announcements of numerous other game engines, including Unity and Unreal, supporting HTML5:

https://blog.mozilla.org/blog/2014/03/18/gdc-2014-mozilla-an...

Or they could just target WebGL and asm.js, which already works in Chrome, and let's see how long Google sits around with Chrome being slower at a popular use case.