3 ms·

> JavaScript is locked in. It's too entrenched, it's never going away. Let's just accept that. JavaScript doesn't have to go anywhere, it can run on a shared V

by nupark2 15y ago

> JavaScript is locked in. It's too entrenched, it's never going away. Let's just accept that. JavaScript doesn't have to go anywhere, it can run on a shared VM like any other language. > That means that adding additional languages creates a burden. You're now supporting, at minimum 2 VMs. If you're going to support a second VM you better get it positively right. That doesn't proclude doing it, it just means it's not coming tomorrow. There is literally zero investment in moving such an idea forward on the part of Mozilla and WebKit (sans Google). In fact, there's active resistance, while at the same time strongly favoring JavaScript as the one option. The position more seems to be "we might chip in if someone else comes up with the perfect answer" rather than "yes, this is a problem that needs to be solved to improve developer productivity, application quality, and help the web compete with other platforms".

maximusprime 15y ago
> JavaScript doesn't have to go anywhere, it can run on a shared VM like any other language. JS running on a general VM would be slower. That's against the interests of the user. People should stop caring what language it is. If you really don't have the skill required to use Javascript, use something easier for you and get it to compile to JS. I've really never understood developers that bitch and whine about programming languages all day. Adding alternate languages to the browser does absolutely nothing for the user. It would only be there to appease the "I shall only develop in lisp" extremist developers.
- nupark2 15y ago
  > JS running on a general VM would be slower. That's against the interests of the user. What do you base this on? It's sounds like an unsupported assumption regarding the complex technical constraints involved in implementing a general purpose VM and JIT. Putting the technical specifics aside, intuitively, why would the general VM be slower, especially since the requirement to support JavaScript would be obvious to everyone involved from day 1?
  - azakai 15y ago
    >> JS running on a general VM would be slower. That's against the interests of the user. > What do you base this on? It's sounds like an unsupported assumption No, he is entirely correct. JavaScript and most dynamic languages do not run at full speed on static-language VMs like the JVM and .NET. This is despite tremendous efforts and motivation to run those languages quickly on such environments, see for example Microsoft's SPUR paper and everything it has done in the CLR to speed up dynamic languages. The fact is, despite all those efforts, even Microsoft did not implement JS on .NET in IE. This despite Microsoft more than anyone having the capability and moreso the motivation ("everything on .NET"). Microsoft gave up and implemented a new JS engine in native code, and it made that new native JS VM a peer of .NET in Windows 8. The reasons for this are technical: We do not know how to make a single VM that runs all languages quickly. It's very difficult to do! Dynamic languages need hand-crafted PICs for example, which are extremely difficult to make portable and safe, which is necessary for a VM on the web. Also, low-level details like even how to implement numbers are significant: NaNboxing for example is used in most JS engines, but it probably doesn't make sense in a static language VM. Having both NaNboxed numbers and 'normal' ones in one VM is cumbersome and complex.
    - nupark2 15y ago
      > JavaScript and most dynamic languages do not run at full speed on static-language VMs like the JVM and .NET. This is despite tremendous efforts and motivation to run those languages quickly on such environments, see for example Microsoft's SPUR paper and everything it has done in the CLR to speed up dynamic languages. I'd argue the opposite regarding tremendous efforts and motivation; dynamic languages were an after-thought for both the JVM and .NET, and on the JVM side you've only seen any attempts to improve performance recently, with invokedynamic for Java 7. The investments here occurred long after the VMs were developed. > The reasons for this are technical: We do not know how to make a single VM that runs all languages quickly. The same applies to compilers across the board; we do not know how to make a compiler that applies all possible optimization available to code always, either. I still have to manually vectorize critical paths, re-order code (sometimes in C!) to help the compiler avoid pipeline stalls, etc. Instead, we do the best general purpose job we can, and it's usually more than fast enough. What we're talking about here is a VM that has JS support as its first-order target. Using the JVM and CLR as performance examples here -- given what they were built for, and when -- is not particularly valid. Speaking to NaN-boxing in particular; it's one solution to the problem, but not the only one. I'm going to remain unconvinced here, given that dynamic languages have almost always been a late, second-tier concern for anyone investing serious R&D in the development of a VM/JIT/compiler. All that said ... > The fact is, despite all those efforts, even Microsoft did not implement JS on .NET in IE. This despite Microsoft more than anyone having the capability and moreso the motivation ("everything on .NET"). Microsoft gave up and implemented a new JS engine in native code, and it made that new native JS VM a peer of .NET in Windows 8. Even given the above, implementing a custom optimized JavaScript VM -- even if it was only available in JS-only case -- would not be a failure scenario.
- tikhonj 15y ago
  It's not the lisp extremists that want this, it's the Python and Ruby ones. Lisp people already have plenty of options: I can think of ParenScript and ClojureScript off the top of my head. (And I'm not even (much of) a Lisp weenie. :) (parenscript http://common-lisp.net/project/parenscript/ http://common-lisp.net/project/parenscript/) (clojurescript https://github.com/clojure/clojurescript https://github.com/clojure/clojurescript)
- rbxbx 15y ago
  >If you really don't have the skill required to use Javascript... So it's a lack of skill that makes JavaScript a poor choice for largescale application development? No. Developers like this are a large part of the reason we can't have nice things.
MatthewPhillips 15y ago
> JavaScript doesn't have to go anywhere, it can run on a shared VM like any other language. 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. Even Google would be against dropping V8 for JS use. >There is literally zero investment in moving such an idea forward on the part of Mozilla and WebKit (sans Google). In fact, there's active resistance, while at the same time strongly favoring JavaScript as the one option. >The position more seems to be "we might chip in if someone else comes up with the perfect answer" rather than "yes, this is a problem that needs to be solved to improve developer productivity, application quality, and help the web compete with other platforms". I read the mailing list and that's not the impression I get at all. The impression I get is: 1) JavaScript still has a lot of room for improvement. Putting resources in an alternative (whatever shape that might take) distracts from improving JavaScript. 2) Most of the problems people have with JavaScript are being addressed by EmcaScript.next. 3) For those who have a general syntax/style problem, there are numerous alternatives that compile to JS to choose from, and more are likely to become popular in future as programmers from different backgrounds are compelled to write for the browser.
- nupark2 15y ago
  > 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. Even Google would be against dropping V8 for JS use. And yet, Google, Apple, AND Mozilla have all successfully introduced entirely new or significantly refactored VMs in the past few years. This is solvable; it HAS been solved. > JavaScript still has a lot of room for improvement. Putting resources in an alternative (whatever shape that might take) distracts from improving JavaScript. This doesn't seem contrary to what I've stated above; it's an argument in favor of JavaScript over investing in a generic VM that would open up the ability to develop new browser languages to everyone. In that regard, failing to allow others to implement custom/experimental languages seems counterproductive to the ultimate goals you seem to be stating here. > For those who have a general syntax/style problem, there are numerous alternatives that compile to JS In terms of performance, debugging, profiling, and simple functionality, compiling to JS is simply a work-around, not a solution.

by nupark2 15y ago

maximusprime 15y ago

> JavaScript doesn't have to go anywhere, it can run on a shared VM like any other language. JS running on a general VM would be slower. That's against the interests of the user. People should stop caring what language it is. If you really don't have the skill required to use Javascript, use something easier for you and get it to compile to JS. I've really never understood developers that bitch and whine about programming languages all day. Adding alternate languages to the browser does absolutely nothing for the user. It would only be there to appease the "I shall only develop in lisp" extremist developers.

nupark2 15y ago
> JS running on a general VM would be slower. That's against the interests of the user. What do you base this on? It's sounds like an unsupported assumption regarding the complex technical constraints involved in implementing a general purpose VM and JIT. Putting the technical specifics aside, intuitively, why would the general VM be slower, especially since the requirement to support JavaScript would be obvious to everyone involved from day 1?
- azakai 15y ago
  >> JS running on a general VM would be slower. That's against the interests of the user. > What do you base this on? It's sounds like an unsupported assumption No, he is entirely correct. JavaScript and most dynamic languages do not run at full speed on static-language VMs like the JVM and .NET. This is despite tremendous efforts and motivation to run those languages quickly on such environments, see for example Microsoft's SPUR paper and everything it has done in the CLR to speed up dynamic languages. The fact is, despite all those efforts, even Microsoft did not implement JS on .NET in IE. This despite Microsoft more than anyone having the capability and moreso the motivation ("everything on .NET"). Microsoft gave up and implemented a new JS engine in native code, and it made that new native JS VM a peer of .NET in Windows 8. The reasons for this are technical: We do not know how to make a single VM that runs all languages quickly. It's very difficult to do! Dynamic languages need hand-crafted PICs for example, which are extremely difficult to make portable and safe, which is necessary for a VM on the web. Also, low-level details like even how to implement numbers are significant: NaNboxing for example is used in most JS engines, but it probably doesn't make sense in a static language VM. Having both NaNboxed numbers and 'normal' ones in one VM is cumbersome and complex.
  - nupark2 15y ago
    > JavaScript and most dynamic languages do not run at full speed on static-language VMs like the JVM and .NET. This is despite tremendous efforts and motivation to run those languages quickly on such environments, see for example Microsoft's SPUR paper and everything it has done in the CLR to speed up dynamic languages. I'd argue the opposite regarding tremendous efforts and motivation; dynamic languages were an after-thought for both the JVM and .NET, and on the JVM side you've only seen any attempts to improve performance recently, with invokedynamic for Java 7. The investments here occurred long after the VMs were developed. > The reasons for this are technical: We do not know how to make a single VM that runs all languages quickly. The same applies to compilers across the board; we do not know how to make a compiler that applies all possible optimization available to code always, either. I still have to manually vectorize critical paths, re-order code (sometimes in C!) to help the compiler avoid pipeline stalls, etc. Instead, we do the best general purpose job we can, and it's usually more than fast enough. What we're talking about here is a VM that has JS support as its first-order target. Using the JVM and CLR as performance examples here -- given what they were built for, and when -- is not particularly valid. Speaking to NaN-boxing in particular; it's one solution to the problem, but not the only one. I'm going to remain unconvinced here, given that dynamic languages have almost always been a late, second-tier concern for anyone investing serious R&D in the development of a VM/JIT/compiler. All that said ... > The fact is, despite all those efforts, even Microsoft did not implement JS on .NET in IE. This despite Microsoft more than anyone having the capability and moreso the motivation ("everything on .NET"). Microsoft gave up and implemented a new JS engine in native code, and it made that new native JS VM a peer of .NET in Windows 8. Even given the above, implementing a custom optimized JavaScript VM -- even if it was only available in JS-only case -- would not be a failure scenario.
tikhonj 15y ago
It's not the lisp extremists that want this, it's the Python and Ruby ones. Lisp people already have plenty of options: I can think of ParenScript and ClojureScript off the top of my head. (And I'm not even (much of) a Lisp weenie. :) (parenscript http://common-lisp.net/project/parenscript/ http://common-lisp.net/project/parenscript/) (clojurescript https://github.com/clojure/clojurescript https://github.com/clojure/clojurescript)
rbxbx 15y ago
>If you really don't have the skill required to use Javascript... So it's a lack of skill that makes JavaScript a poor choice for largescale application development? No. Developers like this are a large part of the reason we can't have nice things.

MatthewPhillips 15y ago

> JavaScript doesn't have to go anywhere, it can run on a shared VM like any other language. 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. Even Google would be against dropping V8 for JS use. >There is literally zero investment in moving such an idea forward on the part of Mozilla and WebKit (sans Google). In fact, there's active resistance, while at the same time strongly favoring JavaScript as the one option. >The position more seems to be "we might chip in if someone else comes up with the perfect answer" rather than "yes, this is a problem that needs to be solved to improve developer productivity, application quality, and help the web compete with other platforms". I read the mailing list and that's not the impression I get at all. The impression I get is: 1) JavaScript still has a lot of room for improvement. Putting resources in an alternative (whatever shape that might take) distracts from improving JavaScript. 2) Most of the problems people have with JavaScript are being addressed by EmcaScript.next. 3) For those who have a general syntax/style problem, there are numerous alternatives that compile to JS to choose from, and more are likely to become popular in future as programmers from different backgrounds are compelled to write for the browser.

nupark2 15y ago
> 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. Even Google would be against dropping V8 for JS use. And yet, Google, Apple, AND Mozilla have all successfully introduced entirely new or significantly refactored VMs in the past few years. This is solvable; it HAS been solved. > JavaScript still has a lot of room for improvement. Putting resources in an alternative (whatever shape that might take) distracts from improving JavaScript. This doesn't seem contrary to what I've stated above; it's an argument in favor of JavaScript over investing in a generic VM that would open up the ability to develop new browser languages to everyone. In that regard, failing to allow others to implement custom/experimental languages seems counterproductive to the ultimate goals you seem to be stating here. > For those who have a general syntax/style problem, there are numerous alternatives that compile to JS In terms of performance, debugging, profiling, and simple functionality, compiling to JS is simply a work-around, not a solution.