[Scriptor]

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]

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.