If bytecode became the standard it would further obscure scripting code and make it tougher to read other people's code.
Why are we limited to JS in browsers - would a bytecode standard help?
131–140 of 187 posts
Re: Why are we limited to JS in browsers - would a bytecode standard help?
#132Earlier quoted context omitted.
I believe some work went on to produce a Java-running chip at one point. It proved better to compile down to whatever suited the chip best.
There have been several JVM (without the "V") created[1]. None of them really caught on other than the ARM Jazelle[2], which isn't really a JM, it is more of a JVM accelerator: it has support for direct execution of many of the JVM opcodes. After investing lots of time and money into creating a JM, the companies were chagrined to find a general purpose processor with a good JVM (especially with JIT) could run circles…
I find it mildly amusing that the Android phone I use, an HTC Magic, has hardware acceleration for Java built in. Talk about a white elephant.
Re: Why are we limited to JS in browsers - would a bytecode standard help?
#133In all honesty... what's the difference? Turing complete language ≈ Turing complete language. Just make something to compile your language of choice into JavaScript, or make a new one (CoffeeScript). Bytecode is just a little more dense, little faster executing, far harder to investigate language than JavaScript, which the browser can compile for added speed anyway. I prefer my language-of-the-web to be readable, tha…
The difference is that Javascript is about the worst possible IL for a compiler to compile down to. Yeah you can recover some of the speed by spending man years on making Javascript execute somewhat fast. As a bytecode you wouldn't use a bytecode that is targeted at handling Javascript constructs. You'd use a bytecode that, for example, supports machine integers (unlike Javascript). Something that allows you to alloc…
The browser provides very high level constructs (e.g., the DOM), handling numbers quickly is uninteresting and would be a poor direction for optimization. While I think an appropriate VM could be something interesting, I doubt an appropriate VM in this case would look like the JVM.
Re: Why are we limited to JS in browsers - would a bytecode standard help?
#134I really liked this comment (by khoth): "And once we have standardised bytecode, the next logical step would presumably be to improve performance by creating CPUs that can execute it directly. In 20 years we'll all be back where we started."
Talk to Cliff Click (or sift through his blog http://www.azulsystems.com/blogs/cliff) and he will quickly disabuse you of the notion that having bytecode instructions in a processor is a good idea. For optimal performance you want a generic RISC-type processor with good hardware performance for critical things like read-barriers that the bytecode might require; you really don't want to design a processor that directly executes Java bytecode.
There's a whole hell of a lot of optimization that gets done in the JIT layer besides just translating bytecode to machine code, and you want all that stuff to get done in software rather than trying to build it into your processor. Once you've done all that stuff, emitting actual assembly code isn't really the hard part, so you might as well just design a processor that you can make fast, give it a simple general-purpose instruction set, target that instruction set in your JIT, and then add a few special goodies as you need them for things that are really, really hard to do fast without specialized hardware support.
Re: Why are we limited to JS in browsers - would a bytecode standard help?
#135My admittedly biased view: I spent two years of my life trying to make the JVM communicate gracefully with Javascript - there were plenty of us at Netscape who thought that bytecode was a better foundation for mobile code. But Sun made it very difficult, building their complete bloated software stack from scratch. They didn't want Java to cooperate with anything else, let alone make it embeddable into another piece o…
x86 is a perfect comparative example. An architecture that is a patch on a patch on a patch (add several more layers here until you're tired) going back to the 8086 a kajillion years ago (a processor which was less sophisticated and powerful than an arduino). Intel tried to kill the architecture (replacing it with IA64) but AMD patched it yet again and the result was successful. Nobody sane would design an architectu…
I would just like to point out that IA64 wasn't really a significant step up. VLIW is a good idea for DSPs and GPUs and whatnot, but for the kind of dynamic, branchy code that we all know and love, IA-64 was quite probably the only somewhat modern CPU arch that was actually worse than x86.
Re: Why are we limited to JS in browsers - would a bytecode standard help?
#136I tried to make this point in this submission: http://news.ycombinator.com/item?id=1790311 The fact that it also ranted about Javascript shifted the discussion though
I remembered that post when I saw this headline. I think from a philosophical viewpoint it's a good idea - though I've no idea what the implementation difficulties might be (could google have created V8 if we had a bytecode system?). But from a practical stance, what's the benefit? What would it achieve?
Re: Why are we limited to JS in browsers - would a bytecode standard help?
#137Earlier quoted context omitted.
It was never integrated into the DOM, though, was it? I am only aware of it being used in a separate, sandboxed area on the page, unable to interact with anything else except in a very limited way. (Never mind the slow loading time etc)
You could integrate Java applets into the DOM. Now you have two problems. (Keep in mind that back when this was popular IE 4 was busy kicking the pants off of Netscape Navigator. Fancy programming against IE 4 ?)
Fancy programming against IE 4
Re: Why are we limited to JS in browsers - would a bytecode standard help?
#138Earlier quoted context omitted.
x86 is a perfect comparative example. An architecture that is a patch on a patch on a patch (add several more layers here until you're tired) going back to the 8086 a kajillion years ago (a processor which was less sophisticated and powerful than an arduino). Intel tried to kill the architecture (replacing it with IA64) but AMD patched it yet again and the result was successful. Nobody sane would design an architectu…
I would just like to point out that IA64 wasn't really a significant step up. VLIW is a good idea for DSPs and GPUs and whatnot, but for the kind of dynamic, branchy code that we all know and love, IA-64 was quite probably the only somewhat modern CPU arch that was actually worse than x86.
I'm not so sure about that. Modern IA64 compilers and systems are actually pretty damned decent. Though the fact that they are still only comparable to a monstrous, teetering pile of hacks and kludges (x86) is not much of a recommendation.
Re: Why are we limited to JS in browsers - would a bytecode standard help?
#139I took a whack at this 9 years ago. My code's at http://wry.me/~darius/software/idel and there were other, probably worthier, attempts around the same time and before, like Michael Franz's work with Oberon. Basically: make a low-level VM more or less like LLVM without the machine-dependent semantics and with a compact, easy-to-verify wire format. Apparently PNaCl is working on fixing those infelicities now, or at least the machine dependence.
(I had some fun but decided the obstacles to addoption were too great and we'd end up with x86 in the browser someday. So the NaCl announcement years later amused and gratified me.)
Re: Why are we limited to JS in browsers - would a bytecode standard help?
#140Earlier quoted context omitted.
I find Lua depressing and Javascript exciting. So where does that leave us? If it's all a matter of taste as to what's desirable in a "mature" language, your argument doesn't go very far.
I'm mostly thinking about how many of the problems highlighted in "Javscript: The Good Parts" have been fixed in Lua, while Javascript can't be fixed. Not a matter of design and taste, but outright bugs.
OK, don't use the "bad parts."
But it's a lot more than that. It's the "taste" of the language itself, and Javascript tastes much more like the kind of language I like using.
Lua always struck me as being so simple it crosses the line into Factor/Forth territory.