From: "M. Edward (Ed) Borasky" <znmeb@...>
Date: 2006-09-05T04:25:36+09:00
Subject: Re: Joel Spolsky on languages for web programming

Chad Perrin wrote:
>> 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.

You can usually do something like this in Forth. As you're developing,
you save off the whole enchilada (the Forth interpreters and compiler
and assembler, along with your application code, all of which reside in
the dictionary) as an executable. When you're ready to release the
application, you take a special pass and strip out everything your
application doesn't use, getting a smaller executable that only contains
the pieces of the Forth environment needed to run the application.

I haven't spent any appreciable time inside either Common Lisp or
Scheme, or for that matter Ruby, so I don't know how this would work in
any language except Forth. Maybe what you want is as "simple" as
implementing Ruby on top of Forth. :)

> 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.
No reason it can't be done. The question is only "should it be done?" :)

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

Java also has JIT, of course. Curiously enough, someone once told me
that if I looked at the JVM carefully, I'd see Forth. :)


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

Well ... maybe we should leave that to the chip? :)