5 ms·

Despite the parent comment getting downmodded, I think it makes a valid point. Why don't we see a true plurality of programming languages supported within the

Despite the parent comment getting downmodded, I think it makes a valid point. Why don't we see a true plurality of programming languages supported within the browser? I'm talking about proper implementations, too. Not hacks that use something like Emscripten to mangle C code down to JavaScript (which is all that asm.js is, after all). NaCl and PNaCl are a much more general and sensible approach, rather than trying to contort JavaScript into a psuedo-bytecode. If Mozilla really does care about openness and freedom, then we'd see more emphasis being placed on languages other than JavaScript. But CmonDev is right, we just don't see that happening. We see a monoculture developing around JavaScript and only JavaScript. In general, monocultures of any type are an unhealthy thing, and lead to stagnation.

k__ 12y ago
JavaScript is open and free. Also, with Rust, they are already developing another language. You might be right with the monoculture problem, but JS is a big thing with many developers, it would be dumb not to use this resource.
abnormalbrains 12y ago
Do you think it's also worrying that we all communicate in English? Is the English language a stagnated monoculture? Pandering to language fanboys isn't a good idea. Javascript is a good enough language, and if you don't like it, write in something else and compile it to javascript.
- rifung 12y ago
  I'm not smart or experienced enough to know the answer to this, it's an honest question. Doesn't compiling things to javascript inherently limit what we can do? For example, if a feature is supported in some other language but not javascript then I imagine even if there were a way to compile to javascript, there might be a severe performance impact. I guess what I am saying is that it seems like we are stuck with javascript for historical reasons and it's a shame that we aren't exploring other options. Of course, I can also completely see that sticking with javascript is the most practical option as well.
  - azakai 12y ago
    > Doesn't compiling things to javascript inherently limit what we can do? Yes, any concrete compilation target has limitations, including JavaScript. For example, in JavaScript, there are no 64-bit integers, which can slow down some code. As another example, strings on .NET and Python are different, causing Python on the CLR to either behave differently or run more slowly. I think the important thing to realize is that there isn't a "perfect" compilation target. What we really want is a target that is (1) fast on all languages, (2) portable to run on all OSes and architectures, and (3) safe to run in a sandboxed manner. There is no target I am aware of that maximizes all 3. All we can do is try to get close. I would say that JavaScript is doing pretty well in that respect already (that is, like all other options, it isn't perfect, but it's relatively decent), and remaining missing features are being worked on. > it's a shame that we aren't exploring other options. I don't think that's true at all - such experiments have been done! We had or have ActiveX, Java, Flash with its multiple VMs, Silverlight/.NET, NaCl, PNaCl, and others I forgot. Given the performance of JavaScript engines today, those experiments of other VMs don't show a big enough reason to prefer them. asm.js code runs fast enough to run AAA game engines, which is a very good test.
    - rifung 12y ago
      Thanks for the response. I'm glad to see that I was wrong. asm.js looks extremely promising
bad_user 12y ago
NaCL is not portable and PNaCL will never be a standard, because it's very complex, very implementation specific and the other browser vendors will never adopt it. Quite the contrary, I view PNaCL as being the hack you're talking about, being Google's version of ActiveX. The great thing about JavaScript is that it can be used as a compilation target, like bytecode. There are already many compilers that do that, like ClojureScript and Scala.js, I'm working on a mixed JVM/JS project in Scala right now. And I get the secure sandbox, the portability of JS and the tools for free. Which is the advantage of a standard, otherwise I might as well go native. And given that you can compile C++ to JavaScript with really good results, I really don't get what problems you're trying to solve. And yes Mozilla is responsible for making this happen, getting everybody on board with ASM.js, even Microsoft. And I find that to be a great development.
- hajile 12y ago
  Compile C to LLVM bytecode. Compile LLVM bytecode to Javascript. Compile C to a subset of LLVM bytecode. I fail to see how the second is harder than the first. In both cases, there are major implementation issues to overcome. The difference is that LLVM bytecode was designed to deal with this while asm.js is contorting an already problematic language and making unofficial (non-spec) guarantees. The argument that compilers to JS exist is a non-issue because there already exist compilers from JS to LLVM (eg. javascriptCore). LLVM already has advanced optimizers that are well tested, so writing compilers targeting LLVM will already give a performance head start. The argument that the bytecode is somewhat implementation specific does not matter for three reasons. The first is that a monopoly on implementation does not matter unless the choice was wrong (and even today, all the major JS engines share a lot of similarity in their high-level structure). Secondly, there are multiple LLVM JITs and native compilers around with each one having it's own take on implementation which seems to indicate that LLVM isn't that closely tied to a single way of doing things. Finally, in JavaScript itself, new features are not simply designed with the programmer in mind. A major factor is whether the big 4 find it easy to implement showing that JavaScript itself is implementation specific to those 4 companies opinion. Couldn't a bytecode do the same if necessary? As there exists a way to compile LLVM code to JS code, backward compatibility with older browsers is simply a matter of adding an additional step in the compilation chain. The JS could check if LLVM was supported and browsers without support would simply ignore script tags that use LLVM. As to the question of "why not just stick with JavaScript". I program in JS every day and really like most of the good parts of the language. This does not excuse the aweful parts of the language nor the problems it causes in real world companies where most programmers aren't "rock stars". For a programmer new to JavaScript (even if they already have lots of programming experience), takes a disproportionately long time compared to other languages and until this is learned, the programmer is probably installing land mines that will need to be fixed later. Every fundamental feature of JavaScript (with the possible exception of closures) has a gotcha that you will run into (and not esoteric gotchas -- many of these will be run into very early on). Even the most advanced of us find reasoning about JS inheritance to be nearly impossible for non-trivial systems and teaching this is even harder. Aside from ubiquity, what reason is there to keep the language around? The only awesome features are that it's very function centric (minus proper tail calls) and it's combined dict/object take on prototypal inheritance is very nice to work with (unless you actually need to use the inheritance part).
bobajeff 12y ago
Think of JavaScript as the JVM, CLR or ABC of the Web runtime. Now imagine someone trying to add a sperate bytecode/intermediate language to those runtimes. There are security issues and architecture issues to consider. The language monoculture problem exists just as much on other runtimes as it's does on the Web. It's just nobody is expected to write in JVM or CLR. That's why projects like asm.js and Emscripten are important. These projects show vendors what things are needed to make JavaScript into a better compile target so that someday writing in other language for the Web is as natural as it is on JVM and CLR.

k__ 12y ago

JavaScript is open and free. Also, with Rust, they are already developing another language. You might be right with the monoculture problem, but JS is a big thing with many developers, it would be dumb not to use this resource.

abnormalbrains 12y ago

Do you think it's also worrying that we all communicate in English? Is the English language a stagnated monoculture? Pandering to language fanboys isn't a good idea. Javascript is a good enough language, and if you don't like it, write in something else and compile it to javascript.

rifung 12y ago
I'm not smart or experienced enough to know the answer to this, it's an honest question. Doesn't compiling things to javascript inherently limit what we can do? For example, if a feature is supported in some other language but not javascript then I imagine even if there were a way to compile to javascript, there might be a severe performance impact. I guess what I am saying is that it seems like we are stuck with javascript for historical reasons and it's a shame that we aren't exploring other options. Of course, I can also completely see that sticking with javascript is the most practical option as well.
- azakai 12y ago
  > Doesn't compiling things to javascript inherently limit what we can do? Yes, any concrete compilation target has limitations, including JavaScript. For example, in JavaScript, there are no 64-bit integers, which can slow down some code. As another example, strings on .NET and Python are different, causing Python on the CLR to either behave differently or run more slowly. I think the important thing to realize is that there isn't a "perfect" compilation target. What we really want is a target that is (1) fast on all languages, (2) portable to run on all OSes and architectures, and (3) safe to run in a sandboxed manner. There is no target I am aware of that maximizes all 3. All we can do is try to get close. I would say that JavaScript is doing pretty well in that respect already (that is, like all other options, it isn't perfect, but it's relatively decent), and remaining missing features are being worked on. > it's a shame that we aren't exploring other options. I don't think that's true at all - such experiments have been done! We had or have ActiveX, Java, Flash with its multiple VMs, Silverlight/.NET, NaCl, PNaCl, and others I forgot. Given the performance of JavaScript engines today, those experiments of other VMs don't show a big enough reason to prefer them. asm.js code runs fast enough to run AAA game engines, which is a very good test.
  - rifung 12y ago
    Thanks for the response. I'm glad to see that I was wrong. asm.js looks extremely promising

bad_user 12y ago

NaCL is not portable and PNaCL will never be a standard, because it's very complex, very implementation specific and the other browser vendors will never adopt it. Quite the contrary, I view PNaCL as being the hack you're talking about, being Google's version of ActiveX. The great thing about JavaScript is that it can be used as a compilation target, like bytecode. There are already many compilers that do that, like ClojureScript and Scala.js, I'm working on a mixed JVM/JS project in Scala right now. And I get the secure sandbox, the portability of JS and the tools for free. Which is the advantage of a standard, otherwise I might as well go native. And given that you can compile C++ to JavaScript with really good results, I really don't get what problems you're trying to solve. And yes Mozilla is responsible for making this happen, getting everybody on board with ASM.js, even Microsoft. And I find that to be a great development.

hajile 12y ago
Compile C to LLVM bytecode. Compile LLVM bytecode to Javascript. Compile C to a subset of LLVM bytecode. I fail to see how the second is harder than the first. In both cases, there are major implementation issues to overcome. The difference is that LLVM bytecode was designed to deal with this while asm.js is contorting an already problematic language and making unofficial (non-spec) guarantees. The argument that compilers to JS exist is a non-issue because there already exist compilers from JS to LLVM (eg. javascriptCore). LLVM already has advanced optimizers that are well tested, so writing compilers targeting LLVM will already give a performance head start. The argument that the bytecode is somewhat implementation specific does not matter for three reasons. The first is that a monopoly on implementation does not matter unless the choice was wrong (and even today, all the major JS engines share a lot of similarity in their high-level structure). Secondly, there are multiple LLVM JITs and native compilers around with each one having it's own take on implementation which seems to indicate that LLVM isn't that closely tied to a single way of doing things. Finally, in JavaScript itself, new features are not simply designed with the programmer in mind. A major factor is whether the big 4 find it easy to implement showing that JavaScript itself is implementation specific to those 4 companies opinion. Couldn't a bytecode do the same if necessary? As there exists a way to compile LLVM code to JS code, backward compatibility with older browsers is simply a matter of adding an additional step in the compilation chain. The JS could check if LLVM was supported and browsers without support would simply ignore script tags that use LLVM. As to the question of "why not just stick with JavaScript". I program in JS every day and really like most of the good parts of the language. This does not excuse the aweful parts of the language nor the problems it causes in real world companies where most programmers aren't "rock stars". For a programmer new to JavaScript (even if they already have lots of programming experience), takes a disproportionately long time compared to other languages and until this is learned, the programmer is probably installing land mines that will need to be fixed later. Every fundamental feature of JavaScript (with the possible exception of closures) has a gotcha that you will run into (and not esoteric gotchas -- many of these will be run into very early on). Even the most advanced of us find reasoning about JS inheritance to be nearly impossible for non-trivial systems and teaching this is even harder. Aside from ubiquity, what reason is there to keep the language around? The only awesome features are that it's very function centric (minus proper tail calls) and it's combined dict/object take on prototypal inheritance is very nice to work with (unless you actually need to use the inheritance part).

bobajeff 12y ago

Think of JavaScript as the JVM, CLR or ABC of the Web runtime. Now imagine someone trying to add a sperate bytecode/intermediate language to those runtimes. There are security issues and architecture issues to consider. The language monoculture problem exists just as much on other runtimes as it's does on the Web. It's just nobody is expected to write in JVM or CLR. That's why projects like asm.js and Emscripten are important. These projects show vendors what things are needed to make JavaScript into a better compile target so that someday writing in other language for the Web is as natural as it is on JVM and CLR.