71–80 of 187 posts
This is sort of taking Cappuccino/Objective-J's principle of "shipping the runtime" to the extreme.
I'd be really interested in seeing this develop. Define a bytecode interpreter (JSVM?) and push bytecode into it. Performance may be god-awful, but you'd be free to use whatever language you fancy. Parchment is an example of the approach, implementing the z-machine VM in javascript. http://code.google.com/p/parchment/
Performance may be god-awful Why, after decades of JIT bytecode VMs, do we still have this misconception? Many of the widespread JVM implementations are faster than V8. LuaJIT and C# Mono are also VM implementations that JIT bytecode and are faster than V8! Is this a troll? http://shootout.alioth.debian.org/u32/which-programming-lang...
Before speculating too much about "a bytecode standard", etc., it would probably be helpful to understand virtual machines and instruction sets. I know web programmers generally aren't big on assembly or writing virtual machines, but an instruction set (group of bytecodes) design and implementation predisposes a processor/VM to certain operations. A VM for an OO language is going to have bytecodes (and other infrastr…
For example, imagine that there was no threat of being sued by Oracle, etc. You could just use the JVM - that already has lots of things that compile to it which work reasonably well. I'm not arguing that we should use the JVM, but only that something like the JVM seems to work reasonably well.
Anyway - having a way that's OK or reasonable to run (say) Ruby in the browser is a lot better than the current situation where there is no such way (without using proprietary stuff).
In 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…
One difference is in compiler optimizations. For a given language, compilers can often make inferences based on the code and the semantics of the language, allowing for very targeted optimizations. If you go from LanguageFoo -> Javascript -> bytecode, then you may be limiting the range of optimizations possible (because Javascript may not be able to infer the same things about the code, be it because of program struc…
The main thing to do then is just to have a front end for your favourite language the outputs LLVM IF.
Earlier quoted context omitted.
I find Javascript depressing. If it had a few more years to develop, it could have been a really great language. I understand why it wound up that way, but, sigh. If you want to see a much better language with the same general design, look at Lua. It's made for scripting C programs rather than web pages, and it has had over a decade longer to mature.
JavaScript was released in 1995 as part of Netscape Navigator 2.0. Lua was released in 1993. I don't know about a decade .
Before speculating too much about "a bytecode standard", etc., it would probably be helpful to understand virtual machines and instruction sets. I know web programmers generally aren't big on assembly or writing virtual machines, but an instruction set (group of bytecodes) design and implementation predisposes a processor/VM to certain operations. A VM for an OO language is going to have bytecodes (and other infrastr…
All of this makes me think that if I was a VM researcher, I'd seriously consider going in this direction. And not being a VM researcher makes me think maybe I should be one.
Whenever I hear "standardized bytecode", I think of Parrot: http://www.parrot.org/
I believe you are looking for http://nodejs.org/
Did I say future? Oh, hello NodeJS.
I don't envision that we'll be writing JavaScript itself forever -- but rather a super-syntax on top of it that compiles down to JS. CoffeeScript is the first generation of this kind of programming language.
I do, however, believe that for the foreseeable future, JavaScript will become the lingua franca of day-to-day programming.
In 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…