Re:Opal: Ruby to JavaScript Compiler
by munificent on Monday June 09, 2014 @04:14PM
(#7870237)
It's not just readability that suffers. Even inlining the check like you do here, what you have will be dramatically slower then raw arithmetic.
(My hunch is that your inlined check would actually be slower than just calling the method, actually. If you just do a method call, the inline caching will optimize it away in many cases.)
> I agree that “compiling to JS is hard”, but I don't think that this demonstrates anything.
All I was trying to demonstrate was just that. If you want a new language that runs in a browser, you can have:
1. Different (presumably better) semantics from JS.
2. A simple compiler that generates readable JS.
3. Performance competitive with raw JS.
But you only get to pick two. CoffeeScript picks 2 and 3 (though it does subset out some of the bad JS behavior). Dart picks 1 and 3. Opal (from the very little that I know about it) seems to be picking 1 and 2.
By belief is that for a client-side language (i.e. a language that runs on the end user's hardware, which you don't control), that you don't have the luxury of sacrificing perf. You can in a server-side language since you can just throw more hardware at it. That's why languages like C++ still dominate client-side apps and games.
Given that, I don't think a language that targets the browser can really discard #3 and expect to get a decent number of users. Given that I love different languages, I'd be happy to be proven wrong here.
(My hunch is that your inlined check would actually be slower than just calling the method, actually. If you just do a method call, the inline caching will optimize it away in many cases.)
> I agree that “compiling to JS is hard”, but I don't think that this demonstrates anything.
All I was trying to demonstrate was just that. If you want a new language that runs in a browser, you can have:
But you only get to pick two. CoffeeScript picks 2 and 3 (though it does subset out some of the bad JS behavior). Dart picks 1 and 3. Opal (from the very little that I know about it) seems to be picking 1 and 2.By belief is that for a client-side language (i.e. a language that runs on the end user's hardware, which you don't control), that you don't have the luxury of sacrificing perf. You can in a server-side language since you can just throw more hardware at it. That's why languages like C++ still dominate client-side apps and games.
Given that, I don't think a language that targets the browser can really discard #3 and expect to get a decent number of users. Given that I love different languages, I'd be happy to be proven wrong here.