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/21
Message-ID: <dewar.874847757@merv>#1/1
X-Deja-AN: 274345530
References: <6008fe$9lm$2@trumpet.uni-mannheim.de>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-09-21T00:00:00+00:00
List-Id: <comp.lang.ada>


Marc says

<<To be practical, it's also important that compile time is reasonably small
for acceptably good code; a compiler must not use too much resources, as it's
part of the system. Some slim-binary-systems do also use post-optimization
at run time (possibly adapting to the empirical system behaviour), after
having generated relatively simple and slow code on loading. It surely helps
that Oberon(-2), the language for which slim binaries have been developed,
is extremely simple and straight-forward to compile, and as integrated part
of the Oberon operating system or a browser, it tends to stay around between
different programs. I'm not sure whether the same concept would work well for
stand-alone programs in much more complicated (for the compiler) languages.>>

No language is "simple and straight-forward to compile" if you want
efficient code. Especially with modern processors with speculative
execution, and super-scalar super-pipelined implementations, the
optimization phases of the compiler are by far the most complex, and
take the most effort to write, and the most execution time to run,
and this is true even with todays large languages (Fortran-90, OO COBOL,
C++, Ada 95 etc).

If you don't want efficient code, then depending on the extent to which
you really mean what you say (as another thread points out, people don't
always know what they areally want), then it is of course much easier
to provide complete portability with very fast compilers. I don't see
any particular merit in the "slim binary" approach over distribution of
source code except for the case where the distributor of the software
is concerned with deliberate obfuscation of proprietary sources. This is
a definite issue for some people, but not really a technical one!