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

21–30 of 54 posts

Re: Opal - Ruby to Javascript compiler

#21

Post by threedaymonk »

5vforest wrote: post #4

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

If you can perform computation on the client, you can avoid some round trips to the server. Of course, you can't trust the client, so you still need to perform (some of) the same computations on the server.

If you can use the same code for both client and server, then it opens up the possibility of sending chunks of logic over the wire.

Here's a trivial example: a website uses Markdown for comment formatting. You can improve the feedback cycle, especially for those who aren't overly familiar with Markdown, by rendering a preview on the client side. However, this means that you need two Markdown parsers, one in your server-side language, and one in JavaScript. That's a potential duplication of effort. Someone has already written a JS Markdown parser, but it might not have exactly the same behaviour as your server implementation. So why not just write the code once and have it work on both sides?

I have a feeling that there are a lot more interesting things that you can do with split computation, but I haven't seen many examples yet. I think they'll come.

Re: Opal - Ruby to Javascript compiler

#22

Post by MatthewPhillips »

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.

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

Re: Opal - Ruby to Javascript compiler

#23

Post by tlrobinson »

DanielRibeiro wrote: post #7

Cool idea. Not the first attempt though: http://hotruby.yukoba.jp/ https://github.com/whitequark/coldruby http://rb2js.rubyforge.org/ http://www.ntecs.de/blog/articles/2007/01/08/rubyjs-javascri... https://github.com/jessesielaff/red http://www.playmycode.com/docs/quby https://github.com/mattknox/8ball Unfortunately, none of them seem to be to handle the mor dynamic features of ruby, like method_missing , which dimin…

While I never finished it, my "CappRuby" prototype supported method_missing since it compiled to use the Objective-J runtime. https://github.com/tlrobinson/cappruby

Re: Opal - Ruby to Javascript compiler

#24

Post by wtetzner »

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.

Re: Opal - Ruby to Javascript compiler

#25

Post by slurgfest »

Xcelerate wrote: post #10

I really like this idea of compiling code to Javascript. Brenden Eich makes some good points for it in his series of slides (starting here: http://brendaneich.github.com/Strange-Loop-2012/#/21 ). I'm working on a little programming language myself that compiles to Javascript. In most languages that do this, I wish there was better information on the mapping between the domain language and its Javascript codomain. I t…

Why is it not possible to engineer a basic VM to do this job from the start, rather than retrofitting Javascript to act as a bytecode?

Re: Opal - Ruby to Javascript compiler

#26

Post by scott_s »

Scriptor wrote: post #18
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…

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 "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.

Re: Opal - Ruby to Javascript compiler

#27

Post by rrouse »

MatthewPhillips wrote: post #22
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.

? 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.

Re: Opal - Ruby to Javascript compiler

#28

Post by adrusi »

slurgfest wrote: post #25
Xcelerate wrote: post #10

I really like this idea of compiling code to Javascript. Brenden Eich makes some good points for it in his series of slides (starting here: http://brendaneich.github.com/Strange-Loop-2012/#/21 ). I'm working on a little programming language myself that compiles to Javascript. In most languages that do this, I wish there was better information on the mapping between the domain language and its Javascript codomain. I t…

Why is it not possible to engineer a basic VM to do this job from the start, rather than retrofitting Javascript to act as a bytecode?

implementing a vm in javascript would be noticeably slower than compiling directly to javascript. Dart has its own vm, which will eventually be bundled with chrome since it's a google-backed project, but for backwards compatibility it still needs a dart source to javascript source compiler.

Re: Opal - Ruby to Javascript compiler

#29

Post by rcthompson »

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.

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

Re: Opal - Ruby to Javascript compiler

#30

Post by btilly »

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 2100 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.
Post reply on HN