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

Opal - Ruby to Javascript compiler

opalrb.org

Post reply on HN
Print view View original

31–40 of 54 posts

Re: Opal - Ruby to Javascript compiler

#31

Post by jonny_eh »

wtetzner wrote: post #24
jonny_eh wrote: post #2

While very impressive it makes me nervous. The JS it outputs just in the basic tutorial looks extremely complex, I'd hate to debug that code! Compare with CoffeeScript, where the output is quite easy to follow, and therefore debug.

The difference is that CoffeeScript was designed to compile to JavaScript, so it can adopt JavaScript semantics. Ruby doesn't have the same semantics as JavaScript, so you can't have a 1-to-1 mapping of language constructs.

Oh I get that. I'm sure they did as good as job as possible, but it still makes me nervous.

As nice a language as Ruby is, I don't think it's worth the trade-off. I'll stick with CoffeeScript since it's a nice compromise between Ruby and JavaScript.

Re: Opal - Ruby to Javascript compiler

#32

Post by pygy_ »

tlack wrote: post #15
pygy_ wrote: post #12

Earlier quoted context omitted.

Javascript Harmony (ES6) Proxies will allow to define getter catchall and other kinds of traps. See https://developer.mozilla.org/en-US/docs/JavaScript/Referenc...

Minor FYI: for this who want to play with Proxies right now, you can use a recent-ish copy of node invoked with node --harmony_proxies Enjoy!

Actually, V8 implements an older version of the spec. You can get a polyfill created by the designer of the Proxy spec here: https://github.com/tvcutsem/harmony-reflect

It requires `node --harmony` (actually only Harmony Proxies and Harmony WeakMaps, but the rest doesn't hurt.)

Re: Opal - Ruby to Javascript compiler

#34

Post by iso8859-1 »

Sanddancer wrote: post #11
5vforest wrote: post #4

What the use case for something like this? Am I missing something?

Using the language you're comfortable with client-side. Though what this really shows, once again, is that we really need a good, open, virtual machine specification for client-side byte code so we aren't stuck with the same javascript hammer for all problems.

Native Client? Or PNaCl if you insist on extreme portability.

Re: Opal - Ruby to Javascript compiler

#35

Post by doktrin »

Being relatively new to cross-language compilation, how are one language's class APIs typically translated into another?

For example :

   [1,2,3].shuffle
[turns into] =>

   (function() {
     var __opal = Opal, self = __opal.top, __scope = __opal, nil = __opal.nil, __breaker = __opal.breaker, __slice = __opal.slice;
  
     return [1, 2, 3].$shuffle()
   })();
Of course, since JS arrays do not have a "shuffle" method, the output reads :

   TypeError: Object 1,2,3 has no method '$shuffle'
Is the answer to simply use class/object methods that are present in both languages?

Re: Opal - Ruby to Javascript compiler

#36

Post by robwgibbons »

scott_s wrote: post #26
Scriptor wrote: post #18

Earlier quoted context omitted.

It's really not terribly complicated to figure out what it does, here's the formatted version for adding two numbers (function() { var __opal = Opal, self = __opal.top, __scope = __opal, nil = __opal.nil, __breaker = __opal.breaker, __slice = __opal.slice; var __a, __b; return self.$puts((__a = 1, __b = 2, typeof(__a) === 'number' ? __a + __b : __a['$+'](__b))) })(); The first line just declares some Opal-specific va…

I agree that it's reasonable. Consider this C program: int main() { return 4 + 2 + 5 + (19 + 3 * 4) - 8 / 10; } Becomes the following assembly: .section __TEXT,__text,regular,pure_instructions .globl _main .align 4, 0x90 _main: Leh_func_begin1: pushq %rbp Ltmp0: movq %rsp, %rbp Ltmp1: movl $42, -8(%rbp) movl -8(%rbp), %eax movl %eax, -4(%rbp) movl -4(%rbp), %eax popq %rbp ret Leh_func_end1: Yes, that's going from "hi…

Yeah, not really. Basic statements (arithmetic no less) exploded into an unreadable mess is not reasonable.

Re: Opal - Ruby to Javascript compiler

#37

Post by ville »

rrouse wrote: post #27
MatthewPhillips wrote: post #22

Earlier quoted context omitted.

? Doesn't this show that we aren't stuck with the same hammer? Opal is a different hammer.

Not really. You're still using Javascript in the end.

How is that a bad thing? Source code VMs are easier to secure and as the tooling improves, you don't need to look a the generated JS anymore to debug, it becomes "byte code".

Re: Opal - Ruby to Javascript compiler

#38

Post by omaranto »

btilly wrote: post #30
dyscrete wrote: post #16

It's a great idea, but it seems ridiculous how even simple arithmetic gets translated to an unreadable mess of javascript. puts 4 + 2 + 5 + (19 + 3 * 4) - 8 / 10 translates to: (function() { var __opal = Opal, self = __opal.top, __scope = __opal, nil = __opal.nil, __breaker = __opal.breaker, __slice = __opal.slice; var __a, __b, __c, __d, __e, __f, __g, __h; return self.$puts((__a = (__c = (__e = (__g = 4, __h = 2, t…

In Ruby 2 100 is an exact integer. In JavaScript, it is promoted to a poor floating point approximation. If you want to try to preserve Ruby's numeric semantics, you can't use native math.

I think IEEE doubles can represent up to 53 bit integers exactly. (Someone here will know if that's true.)

Re: Opal - Ruby to Javascript compiler

#39

Post by Sanddancer »

rcthompson wrote: post #29
Sanddancer wrote: post #11

Earlier quoted context omitted.

Using the language you're comfortable with client-side. Though what this really shows, once again, is that we really need a good, open, virtual machine specification for client-side byte code so we aren't stuck with the same javascript hammer for all problems.

Wasn't that the original goal of Java, like, 20 years ago?

It was, but the big issue there was that sun decided to keep all the keys of the castle to themselves. Hence the desire for an open bytecode format.

Re: Opal - Ruby to Javascript compiler

#40

Post by btilly »

omaranto wrote: post #38
btilly wrote: post #30

Earlier quoted context omitted.

In Ruby 2 100 is an exact integer. In JavaScript, it is promoted to a poor floating point approximation. If you want to try to preserve Ruby's numeric semantics, you can't use native math.

I think IEEE doubles can represent up to 53 bit integers exactly. (Someone here will know if that's true.)

Gah, the website ruined what I was typing. I meant 2 to the power of 100. Which is a 100 bit integer, and certainly not correctly calculated in JavaScript.
Post reply on HN