18 ms·

It's really not terribly complicated to figure out what it does, here's the formatted version for adding two numbers (function() { var __opal = O

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 variables (__scope, nil, __breaker, etc.), which I guess are created whether or not they're actually used. The second line defines the temporary variables used to store the numbers. Then, depending on the type, it either actually adds them or use its own '$+' function, which I guess it adds to the prototype for all objects. In terms of having to ever debug something like that, I agree that it'd probably be a huge pain.

scott_s 14y ago
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 "high level" to "low level," but much of the same concepts exist. You have to set up a bunch of stuff unrelated to the computation first, which in the Ruby-to-JavaScript case means setting up the runtime system. In the C-to-assembly case, it means mucking around with the stack. Then the actual computation may not be the most optimal thing, because it was generated by a general framework which can handle any arbitrary computation. Reducing it to something more reasonable looking is an optimization.
- robwgibbons 14y ago
  Yeah, not really. Basic statements (arithmetic no less) exploded into an unreadable mess is not reasonable.
- deleted 14y ago
  [deleted]

scott_s 14y ago

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 "high level" to "low level," but much of the same concepts exist. You have to set up a bunch of stuff unrelated to the computation first, which in the Ruby-to-JavaScript case means setting up the runtime system. In the C-to-assembly case, it means mucking around with the stack. Then the actual computation may not be the most optimal thing, because it was generated by a general framework which can handle any arbitrary computation. Reducing it to something more reasonable looking is an optimization.

robwgibbons 14y ago
Yeah, not really. Basic statements (arithmetic no less) exploded into an unreadable mess is not reasonable.
deleted 14y ago
[deleted]