From: Chad Perrin <perrin@...>
Date: 2006-09-05T03:29:08+09:00
Subject: Re: Joel Spolsky on languages for web programming

On Tue, Sep 05, 2006 at 03:12:07AM +0900, M. Edward (Ed) Borasky wrote:
> Chad Perrin wrote:
> > This brings me to a thought I've been having a lot, lately: that the
> > future of compiled code will probably start looking in some ways more
> > and more like interpreted code.  I don't see why we can't, relatively
> > soon, have a compiler that produces a compiled executable of a dynamic
> > language such as Ruby that does not require a VM or interpreter to be
> > run (outside of the very loose definition of "interpreter" or "VM" that
> > might include your whole OS in that definition).  The dynamic aspects of
> > the language would be handled by the executable binary itself, rather
> > than by an interpreter external to the program.
> > 
> > I'm not entirely sure how to explain what I'm thinking at this time so
> > I'm sure I get my point across.  Hopefully someone who reads this will
> > get where I'm aiming, and may even be able to help me clarify it.
> Perhaps you're thinking along the lines of Lisp or Forth, where an
> application is layered on top of the entire compiler/interpreter/runtime
> package and then saved as an executable. As far as I can tell, there's
> absolutely no reason this couldn't be done for Ruby. IIRC that's also
> the way the Squeak Smalltalk environment works and the way Self worked.

No . . . that's not quite it.  Maybe a really bad diagram will help.

interpreter for a dynamic language:
 |--------------------------------------------------|

interpreter capabilities exercised by a program in a dynamic language:
 |++++++++++++|

compiled static binary for an equivalent program from a static language:
 |++++++++++++|

combination static/dynamic compiled binary from a dynamic language:
 |+++++++++++----|

. . . roughly.

There would likely be more binary size necessary, but considering that
even an interpreter is (generally) a compiled binary that just operates
on input, I don't see any reason to assume we cannot cannot compile
dynamic language code into a persistent binary with accomodations made
for the parts of the program that require runtime dynamic behavior.
This strikes me as a superior approach to a JIT compiler/interpreter
approach like Perl's, a pure interpreter approach like Ruby's, or a
bytecode compilation plus runtime interpreter VM like Java's, for
performance.  Add to that the potential increased performance for some
parts of a program written in a more dynamic language something like the
following might actually run faster than the equivalent compiled program
I diagrammed above:

 |+++++++--------|

. . . depending on how well those dynamic bits (represented by the
hyphens) optimize at runtime for a particular run of the program.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"It's just incredible that a trillion-synapse computer could actually
spend Saturday afternoon watching a football game." - Marvin Minsky