4 ms·

> Bytecode on the web is a shitty idea. In my book, some kind of byte code or other intermediate language is a lot better idea than distributing the source cod

by exDM69 14y ago

> Bytecode on the web is a shitty idea. In my book, some kind of byte code or other intermediate language is a lot better idea than distributing the source code of web apps. There are a lot of disadvantages to delivering programs (for immediate execution) as source code. Note: this is orthogonal to open source and licensing. So what would be needed is an intermediate program representation that: - Is well defined - Is a good compilation target from various source languages - Is easy to validate for correctness and security - Is fast to interpret and compile - Distributed in fast to read binary format - Suits a dynamic language In my opinion LLVM IR or CLR bytecode are the most technically suitable alternatives out of existing ones. The web has quite a long legacy of Javascript and a tradition of supporting deprecated browsers so this kind of revolution is unlikely to happen any time soon. > Besides: I can't think of language-neutral bytecode projects that ever worked. Remember Parrot? JVM, CLR and LLVM are all popular compilation targets that are used with dozens of different source languages each. Bytecode and program representation was never the hard part, it's the frameworks of the OS/platform underneath.

masklinn 14y ago
LLVM's bitcode is an intermediate representation, not a bytecode (last time I looked at it, you couldn't even move it from one architecture to the next and be sure it worked), and developers of JVM-based language have almost as much work bridging the differences between their language's semantics and Java's (for which the JVM's bytecode exists first and foremost) as they'd need to create a new runtime. > Bytecode and program representation was never the hard part Bytecode is very much a hard part if you're trying to support more than a single language, many bytecode have both language and VM semantics leaking in, which essentially makes them even less useful than cross-language compilation.
- exDM69 14y ago
  > LLVM's bitcode is an intermediate representation, not a bytecode (last time I looked at it, you couldn't even move it from one architecture to the next and be sure it worked) Most of LLVM IR is portable, but naturally there are target-specific parts. If LLVM IR was to be used in the web, these target specific parts would be defined for the "web" target. LLVM IR is used in a similar manner in NaCl and OpenCL where it is used as a portable binary format. > Bytecode is very much a hard part if you're trying to support more than a single language It's not easy but it's mostly a solved problem. JVM was designed with a single language in mind, yet it's used by dozens of languages today. Similarly LLVM and CLR are widely used.
  - beagle3 14y ago
    > It's not easy but it's mostly a solved problem. JVM was designed with a single language in mind, yet it's used by dozens of languages today. Similarly LLVM and CLR are widely used. How is this statement qualitatively different from "JavaScript was designed with human writers in mind, yet it's used by dozens of languages today"?
knowtheory 14y ago
I strenuously disagree that distributing the source for web apps is orthogonal to open source. That the web is by default open presents the social dynamics that are quite different than in systems like java applets, which are by default closed. Open source can exist regardless of whether the web is open or not, but you are kidding yourself if you think whether or not source is distributed with a web page doesn't effect the open source landscape.
- exDM69 14y ago
  Today, JavaScript is distributed in minified and/or obfuscated form. And the JavaScript code might have originally been generated by a compiler from a different source language. So calling the stuff your web browser downloads and executes the "source" is not really a valid argument. Instead, JavaScript is used as a program representation with small size and immediate execution in mind, and it really sucks in that role. Even if the code is distributed in source code form with white space, identifier names and comments intact (bandwidth isn't cheap, you know), licensing is still the factor that legally determines if it is free software or just open source by default.
  - knowtheory 14y ago
    The ability to figure out how a piece of code works is different than being able to take that code and reuse it elsewhere. View source is important both for the sake of debugging in the case of 3rd party javascript, and also for the sake of being able to teach others. Regardless of the minification issue, it's possible to use a code formatter to expand a minified file and at least identify where declarations are being made and what functional behavior is being specified. Minification makes viewing source inconvenient, but that's not equivalent with closed.
    - moe 14y ago
      it's possible to use a code formatter to expand a minified file If you go to that length you can just as well use a decompiler, no difference.
bradleyjg 14y ago
It's quite difficult to write a VM target that is fast for both dynamic and statically typed languages. The CLR probably comes the closest but is far from perfect. Since we have to have legacy support for javascript approximately forever anyway, I'd say the best way forward is to embed a vm from the statically typed world as a target for static languages and leave js as a cross compilation target for dynamic languages. To avoid nasty cross vm memory leaks you'd probably want to limit interoperability -- at least at first.
- masklinn 14y ago
  > It's quite difficult to write a VM target that is fast for both dynamic and statically typed languages. It's also nigh-impossible to design a bytecode which does not significantly restrict (and dictate) the semantics of the VM running it. It mandates a bytecode-based VM, to start with (V8 does not use bytecode).

by exDM69 14y ago

masklinn 14y ago

LLVM's bitcode is an intermediate representation, not a bytecode (last time I looked at it, you couldn't even move it from one architecture to the next and be sure it worked), and developers of JVM-based language have almost as much work bridging the differences between their language's semantics and Java's (for which the JVM's bytecode exists first and foremost) as they'd need to create a new runtime. > Bytecode and program representation was never the hard part Bytecode is very much a hard part if you're trying to support more than a single language, many bytecode have both language and VM semantics leaking in, which essentially makes them even less useful than cross-language compilation.

exDM69 14y ago
> LLVM's bitcode is an intermediate representation, not a bytecode (last time I looked at it, you couldn't even move it from one architecture to the next and be sure it worked) Most of LLVM IR is portable, but naturally there are target-specific parts. If LLVM IR was to be used in the web, these target specific parts would be defined for the "web" target. LLVM IR is used in a similar manner in NaCl and OpenCL where it is used as a portable binary format. > Bytecode is very much a hard part if you're trying to support more than a single language It's not easy but it's mostly a solved problem. JVM was designed with a single language in mind, yet it's used by dozens of languages today. Similarly LLVM and CLR are widely used.
- beagle3 14y ago
  > It's not easy but it's mostly a solved problem. JVM was designed with a single language in mind, yet it's used by dozens of languages today. Similarly LLVM and CLR are widely used. How is this statement qualitatively different from "JavaScript was designed with human writers in mind, yet it's used by dozens of languages today"?

knowtheory 14y ago

I strenuously disagree that distributing the source for web apps is orthogonal to open source. That the web is by default open presents the social dynamics that are quite different than in systems like java applets, which are by default closed. Open source can exist regardless of whether the web is open or not, but you are kidding yourself if you think whether or not source is distributed with a web page doesn't effect the open source landscape.

exDM69 14y ago
Today, JavaScript is distributed in minified and/or obfuscated form. And the JavaScript code might have originally been generated by a compiler from a different source language. So calling the stuff your web browser downloads and executes the "source" is not really a valid argument. Instead, JavaScript is used as a program representation with small size and immediate execution in mind, and it really sucks in that role. Even if the code is distributed in source code form with white space, identifier names and comments intact (bandwidth isn't cheap, you know), licensing is still the factor that legally determines if it is free software or just open source by default.
- knowtheory 14y ago
  The ability to figure out how a piece of code works is different than being able to take that code and reuse it elsewhere. View source is important both for the sake of debugging in the case of 3rd party javascript, and also for the sake of being able to teach others. Regardless of the minification issue, it's possible to use a code formatter to expand a minified file and at least identify where declarations are being made and what functional behavior is being specified. Minification makes viewing source inconvenient, but that's not equivalent with closed.
  - moe 14y ago
    it's possible to use a code formatter to expand a minified file If you go to that length you can just as well use a decompiler, no difference.

bradleyjg 14y ago

It's quite difficult to write a VM target that is fast for both dynamic and statically typed languages. The CLR probably comes the closest but is far from perfect. Since we have to have legacy support for javascript approximately forever anyway, I'd say the best way forward is to embed a vm from the statically typed world as a target for static languages and leave js as a cross compilation target for dynamic languages. To avoid nasty cross vm memory leaks you'd probably want to limit interoperability -- at least at first.

masklinn 14y ago
> It's quite difficult to write a VM target that is fast for both dynamic and statically typed languages. It's also nigh-impossible to design a bytecode which does not significantly restrict (and dictate) the semantics of the VM running it. It mandates a bytecode-based VM, to start with (V8 does not use bytecode).