From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_MSGID,
	SUBJ_ALL_CAPS autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,9e20292f693f1408
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM
Date: 1997/09/20
Message-ID: <dewar.874760620@merv>#1/1
X-Deja-AN: 274165472
References: <dewar.873998738@merv> <34196E8E.1790@gsfc.nasa.gov>
 <dewar.874165896@merv> <341B2309.4A41@ibm.net> <dewar.874272343@merv>
 <Pine.SGI.3.95.970916190623.19184E-100000@shellx.best.com>
 <34204085.5377@ibm.net> <dewar.874623267@merv>
 <5vt73c$3nk$1@goanna.cs.rmit.edu.au>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-09-20T00:00:00+00:00
List-Id: <comp.lang.ada>


<<Nope.  "Slim binaries" are absolutely NOTHING LIKE P-code.
Slim binaries are based on two ideas:
    - source code compresses very well
    - IO is slow.

Slim Binaries are used in the Juice system, currently available for
PCs and PowerMacs.  The idea is very simple, and the implementation is
rather elegant.  The precompiler parses a source file, does all the
static checks, may make other completely portable transformations,
and then emits

    > compressed annotated abstract syntax graphs <

At run-time, the Juice system reads the slim binary, decompressing and
building the AST as it goes, and then runs a normal compiler back end
to generate native code.>>


This only makes sense if your compilers have succeeded in employing the
techniques we developed in the 70's and early 80's to make compiler
front ends absurdly slow. Lexical analysis and parsing are instantaneous
if done right. My Ada lex/parser for Ada 83 runs at over 10 million
lines a minute on a reasonable fast PC, including IO, and trying to
optimize this part away is a waste of time. Distributing compressed
sources makes sense, doing anything more to them does not if you
are following this kind of approach. I find the slim binary approach
to be completely without merit.

But to understand why your "nope" is wrong, bump your level of 
abstraction up a bit. The slim binary approach and the P-Code approach
and the Java approach, and similar approaches over time, are all trying
to solve the problem of how to distribute software in a completely
portable manner. 

Actually it is not hard at all to solve this problem, you can just
distribute sourrce and be done with it, and that of course is
Richard Stallman's precsription for how to solve this problem.

In practice, distribution of source has two problems, of a very different
nature:

1. Building large systems from sources can be a very tricky business,
requiring skills that a user of the system does not necessarily have.

2. For those who want to keep their software proprietary, distributing
sources fills them with horror :-)