Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript's sweet spot

blog.mrale.ph

Post reply on HN
Print view View original

11–19 of 19 posts

Re: JavaScript's sweet spot

#11

Post by mraleph »

Sigma0 wrote: post #8

This is an interesting article with regards to helping the V8 compiler optimise JavaScript code. Often, if C like speed is required, it would be easier to just write C rather than try emulate it through esoteric language features, but I wonder if these kind of compiler optimisations could be included via a language that compiles to JavaScript, such as CoffeeScript, at the expense of readability.

emscripten generates very similar code from LLVM bitcode which in turn was generated (optimized) from say C or C++.

It's next to impossible to emit such code from language that is not statically typed.

Also it's not necessarily going to be faster than handwritten "human" JavaScript. There are a lot of factors in play. That's exactly what I am trying to stress in the blog post.

Re: JavaScript's sweet spot

#12

Post by Peaker »

Good article. I strongly disagree with this though:

> And implementation complexity is the worst kind of complexity in the world: it leads to subtle bugs that occur on 0.000001% of programs, it leads to unpredictable and hard to analyze performance, it leads to volumes of rulebooks that specify how to appease the compiler

Implementation complexity is much better than interface complexity. It does not necessarily break down subtly. Unlike interface complexity, it is localized.

Re: JavaScript's sweet spot

#14

Post by mraleph »

wickedchicken wrote: post #13

is the author a C programmer or a C++ programmer? naming a struct 'Point' is suspicious (instead of 'point' or 'POINT')

yeah, I am sorry, I did not follow C naming etiquette to the letter. You are right: these days I am a bit accustomed to starting struct's names with a capital letter because I do a lot of C++ programming.

(I would not call the struct POINT though because it would feel like something from WinAPI :-))

Re: JavaScript's sweet spot

#15

Post by wickedchicken »

mraleph wrote: post #14
wickedchicken wrote: post #13

is the author a C programmer or a C++ programmer? naming a struct 'Point' is suspicious (instead of 'point' or 'POINT')

yeah, I am sorry, I did not follow C naming etiquette to the letter. You are right: these days I am a bit accustomed to starting struct's names with a capital letter because I do a lot of C++ programming. (I would not call the struct POINT though because it would feel like something from WinAPI :-))

;p

Re: JavaScript's sweet spot

#16

Post by ender7 »

What kind of performance increases could we see if we simply added type annotations to Javascript? Would this give the VMs a significant boost?

Something like AS3 (Harmony) syntax:

  var foo:int = 3;
  var bar:string = "A nice string";
  var baz:Array = ["a", "polymorphous", 4, "array"];
  var v:Array. = [2,3,4];

  function f(a:int, b:string):string {
    return a + " " + b;
  }
Sidenote: I really want someone to write a Coffeescript compiler that supports type annotations like the above. It can strip them out when it compiles the code; I just want it to yell at me if I violate one of my declared types.

Re: JavaScript's sweet spot

#17

Post by mraleph »

ender7 wrote: post #16

What kind of performance increases could we see if we simply added type annotations to Javascript? Would this give the VMs a significant boost? Something like AS3 (Harmony) syntax: var foo:int = 3; var bar:string = "A nice string"; var baz:Array = ["a", "polymorphous", 4, "array"]; var v:Array. = [2,3,4]; function f(a:int, b:string):string { return a + " " + b; } Sidenote: I really want someone to write a Coffeescrip…

It really depends on the semantics of those annotations.

For example: how is v:Array. enforced (and is it enforced at all)?

Type annotations can be a good to seed type inference analysis or adjust collected type feedback. But unless they guarantee stability of objects shapes (e.g. Array. can contain only floating point numbers) they'll give little.

Re: JavaScript's sweet spot

#18

Post by masterj »

mraleph wrote: post #11
Sigma0 wrote: post #8

This is an interesting article with regards to helping the V8 compiler optimise JavaScript code. Often, if C like speed is required, it would be easier to just write C rather than try emulate it through esoteric language features, but I wonder if these kind of compiler optimisations could be included via a language that compiles to JavaScript, such as CoffeeScript, at the expense of readability.

emscripten generates very similar code from LLVM bitcode which in turn was generated (optimized) from say C or C++. It's next to impossible to emit such code from language that is not statically typed. Also it's not necessarily going to be faster than handwritten "human" JavaScript. There are a lot of factors in play. That's exactly what I am trying to stress in the blog post.

I think the OP was suggesting that another language could be used for this purpose, similar in function to CoffeeScript in that it compiles down to JavaScript, but statically typed (or even just straight C). That way most of your app could be written in CoffeeScript or JavaScript, but for those few functions who's performance REALLY matters, you could reach for a different tool that makes writing this inhumane but performant flavor of JavaScript easy.

It's an interesting idea, and having little to no knowledge of compilers, I'd be interested in your take on it. Could emscripten already be used for something like this?

Re: JavaScript's sweet spot

#19

Post by scubaguy »

Peaker wrote: post #12

Good article. I strongly disagree with this though: > And implementation complexity is the worst kind of complexity in the world: it leads to subtle bugs that occur on 0.000001% of programs, it leads to unpredictable and hard to analyze performance, it leads to volumes of rulebooks that specify how to appease the compiler Implementation complexity is much better than interface complexity. It does not necessarily brea…

Android (VM based language) has the following API:

public View getDropDownView (int position, View convertView, ViewGroup parent)

convertView - the old view to reuse, if possible. Note: You should check that this view is non-null and of an appropriate type before using. If it is not possible to convert this view to display the correct data, this method can create a new view.

The presence of the unintuitive 'convertView' object is caused by the underlying VM and the unpredictable GC nature. This demonstrates that implementation complexity can lead to a complex interface.

IMO the design of the interface is an implementation. A language that is complex to implement will lead to complex interfaces.

Post reply on HN