3 ms·
> Why? What critical problem requires a bytecode VM? Developers refusing to write in anything but their favorite language? Your argument was that it wasn't tec
by nupark2 15y ago
> Why? What critical problem requires a bytecode VM? Developers refusing to write in anything but their favorite language?
Your argument was that it wasn't technically achievable because it would break the web, yet it's clear that it can be done and HAS been done.
I'll try to address this new argument.
JS isn't perfect, it will never be perfect, and the lack of a bytecode VM is a hindrance to experiments and production language implementations that can lead to better solutions for developers.
Look at the language design that has occurred elsewhere. I may not use Erlang, but I learned a lot from it. Clojure introduced a ton of interesting concurrency constructs (among other advances). C# demonstrated LINQ, and F# is OCaml revisited.
In all of these cases it has nothing to do with whiny developers "refusing to write in anything but their favorite language". We're simply attempting to advance the state of the art, because nothing is perfect, especially JavaScript.
> This is solvable without alternative VMs. WebKit is working on CoffeeScript/other language debugging:
It's a work-around, not a solution. JavaScript still isn't an efficient bytecode format, this won't solve performance issues. We've seen similar work on languages that compile down to C, and it's not an adequate solution to debugging, especially when the debuggers benefit from language-specific enhancements.
- jasonlotito 15y agoExcuse my ignorance, but what browser-based non-JS VM was introduced successfully? You mentioned this was done before, and I assume you mean it was done successfully, so just curious to know which one it is?
- nupark2 15y agoWe were actually discussing JS VM replacement in the browser, related to: > True, but the JS VMs we have today have been refined over 15+ years and switching to another risks breaking the web in profound ways. The counter-point being that all the major browser vendors have swapped out their VM or performed significant rewrites in the past few years; it's clear that it's possible to implement a new VM and not "break the web in profound ways".
- jasonlotito 15y agoI think you are misreading that quote. It's not replacing a JS VM with another JS VM that's a problem, it's replacing a JS VM with a non-JS specific VM would cause problems and break the web (something that has been proven to happen). Arguing that you can replace a JS VM with a JS VM doesn't help the case of replacing a JS VM with a non-JS VM.
- nupark2 15y agoAt the surface level, I could see how your position would appear logical. However, the nature of the replacement VM doesn't really matter in the context of what we're describing here. The problems of compatibility remain the same regardless of whether the target VM is a JS-specific VM, or a general purpose VM; reliance on undefined behavior, accidental changes in semantics, optimization bugs, and so on. If browser makers were able to swap-out the VM, they've already demonstrated the ability to solve the exact same kind of compatibility problems they'd face here.
- bad_user 15y agoThere is no such thing as general purpose VM.
- nupark2 15y agoA VM that provides a standardized bytecode and execution model capable of executing most modern dynamic and static turing complete languages with sufficient performance. This requires more general facilities for common functionality required; refer to tail call support, JVM's invokedynamic, etc. Or, shorthand, a general purpose browser VM. Unless, of course, you're arguing that the above is not truly possible, in which case I'd argue that's exactly what Google is exploring via PNaCL, and has (if not completely efficiently) been implemented across existing VMs. The PNaCL choice of LLVM bitcode was likely in error, but regardless, "no such thing" is a stretch.
- 15y ago