Re:Moonshine – A lightweight Lua VM for the browser
by swah on Tuesday April 01, 2014 @08:58AM
(#7507693)
I hate how everything is moving to JS :) I wish somehow there were multiple languages targetting a common bytecode.. but that won't happen for some reason I can't understand because I stopped in the middle of the dragon book.
[ Parent
| on HN ]
Re:Moonshine – A lightweight Lua VM for the browser
by Yorrrick on Tuesday April 01, 2014 @10:26AM
(#7508386)
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.
Re:Moonshine – A lightweight Lua VM for the browser
by stcredzero on Tuesday April 01, 2014 @10:31AM
(#7508423)
Hence, there are high value opportunities in JS as a compilation target/runtime platform.
Re:Moonshine – A lightweight Lua VM for the browser
by duaneb on Tuesday April 01, 2014 @06:12PM
(#7512108)
You know what's a perfect, concise byte code? An ast-laden ASCII blob. What's the byte code for a byte array again? Oh there isn't one.... What's the byte code for a compare and swap? Shit....
Re:Moonshine – A lightweight Lua VM for the browser
by rubiquity on Tuesday April 01, 2014 @09:20AM
(#7507874)
Personally, I feel that the biggest slap in the face to developers in the last decade is that V8 uses native code instead of byte code. In 10-20 years I hope we look back on Google's decision to do that and hate them for it.
Re:Moonshine – A lightweight Lua VM for the browser
by CmonDev on Tuesday April 01, 2014 @01:01PM
(#7509773)
"In 10-20 years" - let's hope ES6 is released before that.
Re:Moonshine – A lightweight Lua VM for the browser
by herokusaki on Tuesday April 01, 2014 @07:40PM
(#7512565)
Honest question: why is it a slap in the face to developers?
Re:Moonshine – A lightweight Lua VM for the browser
by rubiquity on Sunday April 06, 2014 @11:52AM
(#7541330)
Because we could then have a virtual machine that we could send bytecode to, instead of having all of these languages that compile to JavaScript, which eventually gets compiled to native code by V8.
Re:Moonshine – A lightweight Lua VM for the browser
by jlebrech on Tuesday April 01, 2014 @09:25AM
(#7507911)
it compiles to an ast first
Re:Moonshine – A lightweight Lua VM for the browser
by stcredzero on Tuesday April 01, 2014 @10:34AM
(#7508452)
Years ago at Camp Smalltalk, Smalltalk VM implementers talked about compiling everything to ASTs instead of bytecode.
Re:Moonshine – A lightweight Lua VM for the browser
by espadrine on Tuesday April 01, 2014 @11:22AM
(#7508919)
I do understand why nobody would want to target Hydrogen directly, but here's a Hydrogen IR inspector tool: http://mrale.ph/irhydra/1/#ir
Re:Moonshine – A lightweight Lua VM for the browser
by ben0x539 on Tuesday April 01, 2014 @09:30AM
(#7507960)
I think the point of contention is that there isn't really such a thing as a completely language-neutral bytecode, so nobody can agree on whose language-specific-js-replacement vm to ship.
Re:Moonshine – A lightweight Lua VM for the browser
by stormbrew on Tuesday April 01, 2014 @03:12PM
(#7510918)
If JS ever gets finalizers we could probably consider the total feature set JS has at that point sufficient for the implementation of most other dynamic languages without resorting to writing a VM in js or using asm.js to embed a full C runtime using arraymaps for a heap.
At that point we'd probably see some subset of JS devolve to a bytecode, I'll bet.
Re:Moonshine – A lightweight Lua VM for the browser
by chrisdevereux on Tuesday April 01, 2014 @09:08AM
(#7507762)
I don't think the dragon book will help unless the new edition has a section on how to organise a standards committee for your new language.