5 ms·

Well there's always been interesting talk about getting LLVM to run in browsers, which would be wicked cool, and open up a lot of different programming language

Well there's always been interesting talk about getting LLVM to run in browsers, which would be wicked cool, and open up a lot of different programming languages. That said, JavaScript really is an awesome language to use, if you can get over the syntax. So i really can't see how JS would be unsuitable for future use, especially in light of the changes that have happened and continue to come down the pipeline in newer versions of JS. Coffeescript is a fantastic view of the power and capabilities of JavaScript packaged in a way that is considerably more elegant to look at and use on a daily basis. Check out the talk that Brendan Eich and Jeremy Ashkenas did at JSConf (http://news.ycombinator.com/item?id=2662846 http://news.ycombinator.com/item?id=2662846 ). Javascript really is going to be a development powerhouse for the foreseeable future. And i'm actually happy about that.

jerf 15y ago
No one language can meet every need. Even if it has been done, Javascript is a terrible language to write an MP3 decoder in, relative to more suitable languages. So if we're continuing to expand what the browser can do, shouldn't we expand what languages we can express them in? Why do we have to write our WebGL programs in Javascript? Javascript isn't a terribly great bytecode language, either, unless you're basically just writing a thin skin over Javascript. The logical conclusion of this line of argument is pretty much NaCL: http://code.google.com/p/nativeclient/ http://code.google.com/p/nativeclient/ Is that the anwser? Is there some intermediate where Javascript isn't the only choice for everything but we don't go to the other extreme? Beats me, but we'll all find out together. But my main point is that it definitely is not the case that Javascript is just the answer to everything and the situation is just peachy keen as it is. It isn't the answer to everything. No one language is. Either we get something else into the client, or we face some combination of wasted effort jamming programs into a language that doesn't really want them and applications simply never written because they don't work well with Javascript's abstractions. Maybe that's OK too, maybe we want a distinction between "native" and "web" app.
- knowtheory 15y ago
  So i'm curious what you mean by "more suitable languages" for writing an mp3 decoder. Also which of Javascript's abstractions are do you think are so inherently unsuitable? As far as general purpose programming languages Javscript does pretty well with regard to object semantics. That's why things like Coffeescript are as powerful as they are. Javascript certainly doesn't have the elegance that say Ruby or Python has built in, but thanks to JavaScript's powerful and flexible nature, a lot of those capabilities are possible to build on top of JS's core. http://documentcloud.github.com/underscore/ http://documentcloud.github.com/underscore/ (which was also written by jashkenas and others) is a great example of this. On the performance front, given all of the work that's gone into the various browser implementations of JS, that you could call it unsuitable from a performance standpoint. Could perhaps elaborate on this further?
  - jules 15y ago
    An example that shows that Javascript wasn't designed for performance: it doesn't support integers. They can be used in some Javascript implementations that do smart tricks to convert float arithmetic to integer arithmetic, but it is not reliable. If you were designing a language for performance in the first place, this would be a ridiculous method to get access to integers. Same for dense arrays. Yeah, JS is pretty fast if you know how the particular implementation that you're targeting works, but even then there are many things that just need a lot more performance than JS can offer. On the expressiveness front: Javascript doesn't support proper lexical scoping. It's object model is broken. It doesn't use proper abstractions in the standard library. Etc. These can all be fixed by compiling another language to Javascript, but then you lose on the performance side.
    - cpr 15y ago
      Dense arrays are coming in Harmony, thanks to WebGL. (JS.next) CoffeeScript incurs no penalty when compiling to Javascript; in fact, in many cases it's faster than handwritten code.
      - chc 15y ago
        CoffeeScript is only kinda "another language." It's very intentionally designed to map closely to JavaScript. Try it with an actual independent language like Python, Ruby or Haskell and you'll have more trouble.

jerf 15y ago

No one language can meet every need. Even if it has been done, Javascript is a terrible language to write an MP3 decoder in, relative to more suitable languages. So if we're continuing to expand what the browser can do, shouldn't we expand what languages we can express them in? Why do we have to write our WebGL programs in Javascript? Javascript isn't a terribly great bytecode language, either, unless you're basically just writing a thin skin over Javascript. The logical conclusion of this line of argument is pretty much NaCL: http://code.google.com/p/nativeclient/ http://code.google.com/p/nativeclient/ Is that the anwser? Is there some intermediate where Javascript isn't the only choice for everything but we don't go to the other extreme? Beats me, but we'll all find out together. But my main point is that it definitely is not the case that Javascript is just the answer to everything and the situation is just peachy keen as it is. It isn't the answer to everything. No one language is. Either we get something else into the client, or we face some combination of wasted effort jamming programs into a language that doesn't really want them and applications simply never written because they don't work well with Javascript's abstractions. Maybe that's OK too, maybe we want a distinction between "native" and "web" app.

knowtheory 15y ago
So i'm curious what you mean by "more suitable languages" for writing an mp3 decoder. Also which of Javascript's abstractions are do you think are so inherently unsuitable? As far as general purpose programming languages Javscript does pretty well with regard to object semantics. That's why things like Coffeescript are as powerful as they are. Javascript certainly doesn't have the elegance that say Ruby or Python has built in, but thanks to JavaScript's powerful and flexible nature, a lot of those capabilities are possible to build on top of JS's core. http://documentcloud.github.com/underscore/ http://documentcloud.github.com/underscore/ (which was also written by jashkenas and others) is a great example of this. On the performance front, given all of the work that's gone into the various browser implementations of JS, that you could call it unsuitable from a performance standpoint. Could perhaps elaborate on this further?
- jules 15y ago
  An example that shows that Javascript wasn't designed for performance: it doesn't support integers. They can be used in some Javascript implementations that do smart tricks to convert float arithmetic to integer arithmetic, but it is not reliable. If you were designing a language for performance in the first place, this would be a ridiculous method to get access to integers. Same for dense arrays. Yeah, JS is pretty fast if you know how the particular implementation that you're targeting works, but even then there are many things that just need a lot more performance than JS can offer. On the expressiveness front: Javascript doesn't support proper lexical scoping. It's object model is broken. It doesn't use proper abstractions in the standard library. Etc. These can all be fixed by compiling another language to Javascript, but then you lose on the performance side.
  - cpr 15y ago
    Dense arrays are coming in Harmony, thanks to WebGL. (JS.next) CoffeeScript incurs no penalty when compiling to Javascript; in fact, in many cases it's faster than handwritten code.
    - chc 15y ago
      CoffeeScript is only kinda "another language." It's very intentionally designed to map closely to JavaScript. Try it with an actual independent language like Python, Ruby or Haskell and you'll have more trouble.