5 ms·

While Google may need this for building large applications, this is something that the web could do without. The web needs a standard Intermediate Language: a

by sambeau 15y ago

While Google may need this for building large applications, this is something that the web could do without. The web needs a standard Intermediate Language: a machine code. This is what Javascript is becoming and it isn't well designed for it.

ra 15y ago
> The web needs a standard Intermediate Language: a machine code. Definitely. > This is what Javascript is becoming and it isn't well designed for it. Maybe... but what does a bytecode layer provide? I wonder if something useful couldn't be written in JS that provides a thin service layer. I agree it's not ideal, but it's what we've got. Google already have a few to-javascript compilers, including one for Dart... I expect they're already all over this.
- sambeau 15y ago
  The point is not that they are already all over this but rather that an IL is something that all the browser makers could get behind. If Javascript is good enough as an IL why does Dart bypass it in Chrome?
  - ra 15y ago
    > The point is ... that an IL is something that all the browser makers could get behind. Sure, but that's not going to happen in the next decade unless that IL is in Javascript.
    - sambeau 15y ago
      If they built an IL that can also be implemented in Javascript they might have a chance. e.g: Javascript → IL → Javascript
      - ra 15y ago
        Yes, that's what I said!
        sambeau 15y ago
        Sorry, I must have missed the word 'in'.
  - bzbarsky 15y ago
    > If Javascript is good enough as an IL why does Dart > bypass it in Chrome? Because they decided that it was easier to make up a new language than improve the V8 implementation of ECMAScript, as far as I can tell. And at least locally, for Google, that may be true. Whether it's true for the web as a whole is unclear. Other ECMAScript implementors seem to think that V8 is not nearly as fast as an ES implementation could be and are working on proving their claims with actual running code...
ecopoesis 15y ago
Yes. And since Javascript is so popular, we should base the name of this IL on it- I suggest Java.
- alecco 15y ago
  I'd rather avoid Carpal Tunnel Syndrome, thanks.
  - eco 15y ago
    I'd suggest not typing out IL by hand then.
forgotusername 15y ago
I have no idea why people keep suggesting this. There isn't a single precedent for a "universal IL" that isn't somehow tightly bound to one implied runtime model, type system, etc., and yet people keep calling for something like this for the web. Look at the "bag on the side" that is the DLR, look at the attempts at making Jython run quickly, look at the failed attempts over the years at providing a common IL for UNIX (e.g. start reading here: http://en.wikipedia.org/wiki/Ten15 http://en.wikipedia.org/wiki/Ten15), look at the resounding failure of Parrot to become a universal VM, look at the recent rebuttals at attempts to use LLVM as an architecture-independent format. What benefit do you expect your "machine code" to have over JavaScript?
- sambeau 15y ago
  What benefit do you expect your "machine code" to have over JavaScript? All the benefits that people proposing new web languages would impart. There are a good reasons why Google are proposing running Dart straight on their VM in Chrome. It will be faster, safer, easier to jit, easier to prove correct etc. Having a firm foundation would make it easier to innovate. Companies could still be encouraged to compete for faster and safer implementations. The failure of Parrot to catch on has very little to do with the technology, nor the proposition of a general-purpose dynamic language VM. Parrot was simply in the wrong place at the wrong time (and it took too long to deliver). It also made the mistake of tying itself to an unfinished language spec. If they had concentrated on making a VM that could run Python, Ruby and Javascript they would have been in the right place at the right time when Perl 6 was finally ready to be implemented. People are beginning to use Javascript and the V8 engine in a manner similar to the original Parrot proposal. The time is right for a general-purpose IL so we can compile Coffeescript straight to the Javascript VM. LLVM is being questioned by some because a) it isn't a VM it's just an IL so it is a compiler technology not a VM tech b) it is too low level to make the jitting of dynamic languages suitably efficient. LLVM is too low-level; Javascript is too high (and opinionated). Judging innovation by precedence is always a bad idea.
- overgard 15y ago
  I agree with most of what you're saying, but I think an indirect counter-example is C. It's not technically a universal intermediate language, but it's widely considered to be a "portable assembly language"; which many vastly more dynamic languages compile down to. I think the web could use it's own version of something like C -- that is, a low level, no-frills language that maps closer to how hardware works. I imagine for this web version of C -- and it should be a language, not a byte code format -- it would need to satisfy these properties: - language constructs that map semi obviously to machine instructions (ie, you don't need to spend a lot of time guessing what "switch" or "while" or "struct" get turned into), while avoiding things that might not be so obvious. (What does a closure look like in assembly? Or a generator?) - types that correspond to machine types - some sort of predictable and low level memory model (without pointers, but with some sort of way to avoid garbage collection issues. Maybe something with reference counting)
mmatants 15y ago
The web needs a standard API for displaying content. 95% of the client-side headaches out there are due to browser DOM rendering and event model quirks and incompatibilities.
- silon3 15y ago
  Web != API

by sambeau 15y ago

ra 15y ago

> The web needs a standard Intermediate Language: a machine code. Definitely. > This is what Javascript is becoming and it isn't well designed for it. Maybe... but what does a bytecode layer provide? I wonder if something useful couldn't be written in JS that provides a thin service layer. I agree it's not ideal, but it's what we've got. Google already have a few to-javascript compilers, including one for Dart... I expect they're already all over this.

sambeau 15y ago
The point is not that they are already all over this but rather that an IL is something that all the browser makers could get behind. If Javascript is good enough as an IL why does Dart bypass it in Chrome?
- ra 15y ago
  > The point is ... that an IL is something that all the browser makers could get behind. Sure, but that's not going to happen in the next decade unless that IL is in Javascript.
  - sambeau 15y ago
    If they built an IL that can also be implemented in Javascript they might have a chance. e.g: Javascript → IL → Javascript
    - ra 15y ago
      Yes, that's what I said!
      - sambeau 15y ago
        Sorry, I must have missed the word 'in'.
- bzbarsky 15y ago
  > If Javascript is good enough as an IL why does Dart > bypass it in Chrome? Because they decided that it was easier to make up a new language than improve the V8 implementation of ECMAScript, as far as I can tell. And at least locally, for Google, that may be true. Whether it's true for the web as a whole is unclear. Other ECMAScript implementors seem to think that V8 is not nearly as fast as an ES implementation could be and are working on proving their claims with actual running code...

ecopoesis 15y ago

Yes. And since Javascript is so popular, we should base the name of this IL on it- I suggest Java.

alecco 15y ago
I'd rather avoid Carpal Tunnel Syndrome, thanks.
- eco 15y ago
  I'd suggest not typing out IL by hand then.

forgotusername 15y ago

I have no idea why people keep suggesting this. There isn't a single precedent for a "universal IL" that isn't somehow tightly bound to one implied runtime model, type system, etc., and yet people keep calling for something like this for the web. Look at the "bag on the side" that is the DLR, look at the attempts at making Jython run quickly, look at the failed attempts over the years at providing a common IL for UNIX (e.g. start reading here: http://en.wikipedia.org/wiki/Ten15 http://en.wikipedia.org/wiki/Ten15), look at the resounding failure of Parrot to become a universal VM, look at the recent rebuttals at attempts to use LLVM as an architecture-independent format. What benefit do you expect your "machine code" to have over JavaScript?

sambeau 15y ago
What benefit do you expect your "machine code" to have over JavaScript? All the benefits that people proposing new web languages would impart. There are a good reasons why Google are proposing running Dart straight on their VM in Chrome. It will be faster, safer, easier to jit, easier to prove correct etc. Having a firm foundation would make it easier to innovate. Companies could still be encouraged to compete for faster and safer implementations. The failure of Parrot to catch on has very little to do with the technology, nor the proposition of a general-purpose dynamic language VM. Parrot was simply in the wrong place at the wrong time (and it took too long to deliver). It also made the mistake of tying itself to an unfinished language spec. If they had concentrated on making a VM that could run Python, Ruby and Javascript they would have been in the right place at the right time when Perl 6 was finally ready to be implemented. People are beginning to use Javascript and the V8 engine in a manner similar to the original Parrot proposal. The time is right for a general-purpose IL so we can compile Coffeescript straight to the Javascript VM. LLVM is being questioned by some because a) it isn't a VM it's just an IL so it is a compiler technology not a VM tech b) it is too low level to make the jitting of dynamic languages suitably efficient. LLVM is too low-level; Javascript is too high (and opinionated). Judging innovation by precedence is always a bad idea.
overgard 15y ago
I agree with most of what you're saying, but I think an indirect counter-example is C. It's not technically a universal intermediate language, but it's widely considered to be a "portable assembly language"; which many vastly more dynamic languages compile down to. I think the web could use it's own version of something like C -- that is, a low level, no-frills language that maps closer to how hardware works. I imagine for this web version of C -- and it should be a language, not a byte code format -- it would need to satisfy these properties: - language constructs that map semi obviously to machine instructions (ie, you don't need to spend a lot of time guessing what "switch" or "while" or "struct" get turned into), while avoiding things that might not be so obvious. (What does a closure look like in assembly? Or a generator?) - types that correspond to machine types - some sort of predictable and low level memory model (without pointers, but with some sort of way to avoid garbage collection issues. Maybe something with reference counting)

mmatants 15y ago

The web needs a standard API for displaying content. 95% of the client-side headaches out there are due to browser DOM rendering and event model quirks and incompatibilities.

silon3 15y ago
Web != API