From: Rick DeNatale <rick.denatale@...>
Date: 2010-10-06T21:11:12+09:00
Subject: Re: how can we make a ruby compiler

On Wed, Oct 6, 2010 at 12:13 AM, Tony Arcieri <tony.arcieri@medioh.com> wrote:
> On Tue, Oct 5, 2010 at 9:54 PM, Mohit Sindhwani <mo_mail@onghu.com> wrote:
>
>> I tend to write Ruby code that avoids the advanced constructs of Ruby,
>> making translation to C++ easier.
>>
>
> This is pretty much a staple of static type inferencers for dynamic
> languages that output C++... many language features simply cannot be
> supported using this approach, most notably eval, and eval is pretty much
> the most powerful tool for Ruby metaprogramming. Source translation to C++
> would preclude many of the things which make Ruby fun and interesting.

This is very true.  Dipping into what seems to have been attempted in
this area reveals lots of attempts which solve a small but easy subset
of the problem, like translating a "hello world" program, or a small
numerical problem with some polymorphic numeric values from Ruby or
Python to C or C++, and then stall out either when the hard problems
arise, or when the requirements to qualify for a Master's degree
project are met.

And Mohit's original observation is also important:

> If you get to that scale (and are hopefully making money by then or have very large investments that
> match your scale of users/ traffic), there is a high chance that you will need to re-architect
> or rewrite a bunch of stuff - I don't think source translation will solve the problem.

Languages differ in much more important and subtle ways than their
syntax and surface-level semantics.  Those differences lead to very
different architectures/strategies or whatever you want to call it.

Converting an OO program written in, say Ruby, requires adaptation of
not only the language syntax, but the underlying class library, if you
are converting to C++, you need to figure out what to do about the
usage in the Ruby program of base classes, you do probably have
several choices of C++ libraries providing things like collection
classes, all of which will mismatch the interfaces of their Ruby
equivalents, probably in frightening ways.

Replace Smalltalk/Ruby message send semantics with C++ virtual
function calls, and the constraints change. Move the burden of
accounting for and reclaiming the memory used by objects from a GC to
the programmer and things get complicated, and often the performance
of the hand-written memory management (copy constructors, reference
counts ...) starts making the performance 'win' of switching horses
much less certain.

This is Greenspun's tenth rule of programming at work.
http://philip.greenspun.com/research/

-- 
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: http://github.com/rubyredrick
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale