In comp.lang.java.advocacy, Joe Jitsu
<
[email protected]>
wrote
Then why not keep everything to a minimum, with c#/mono ?
Mono is going to be on every desktop, everywhere worldwide.
Why not build on an installed based of assemblies, rather
than porting libraries around, like a caveman toting water
on the backs of his oxen?
And the difference is precisely...what?
Library model:
- download header files
- download source code (if building the library locally for some reason)
- download relocatable machine code (or in the case of Java, bytecode)
- compile library (if building locally)
- compile local source against header files
- link, either during build, during program load, or during class load
- run
Kernel model:
- essentially the same as the library model except that no linking
is involved; the kernel instead sets up "interrupt trap" vectors
which the application calls
Assembly model (AFAICT):
- download assembly
* contents: header files, intermediate code, symboldefs, references, etc.
- compile local source
- construct local assembly, with proper references (one might construe
this as "link", although there are a number of methods by which one
can do outside references; I'd have to look)
- run
I'm not sure I see that much of a difference although the
assembly model (which I've described here generally enough
for it to apply to Java as well as C#/.NET) might be a
little cleaner from an organizational standpoint. The only
real difference is that the intermediate code language is
now standardized -- but intermediate forms have been around
ever since compilers were developed, check the "dragon book"
(_Complexity of Compiler Design_, Aho, Sethi, Ullman,
called the "dragon book" because of the cover showing
a knight armed with the then-current tools attacking
an appropriately-labeled dragon) for example. That was in 1986.
And there is something else being toted around: namely, the
JVM or runtime environment. Something has to be toted
around; even the most pessimistic "trust scenarios" require
something prebuilt on the client machine, even if it's only
DOS's DEBUG.EXE into which one types the firstlevel compiler,
or firmware that activates a reader that swallows digital media.
(On an old HP 2114B, something had to process the paper
tapes that got stuck into memory when one simultaneously
pressed [LOAD] and [START]. I don't know offhand what
it was though it might have simply been a counter cycling
through the memory addresses. I also built a 1802-based
microprocessor with the capability of reading from cassette
tape -- but only after I toggled in (or keyed in; I later
wired up a 19-key hexpad) a simple bootstrapping machine.)
In this case the OS can be construed as a library; certainly a
large chunk of it is designed to be callable from executables.
I could see the next generation of Windows -- "all .NET,
all the time" -- could eliminate the entire current crop
of viruses, as buffer overruns and stack tricks become
a thing of the past. Of course if badly done one might
sport a crop of entirely new viruses taking advantage of
such things as DNS hijacks, link takeovers, certificate
theft, and Trojaning -- which admittedly is about what most
"viruses" (OE scripts) do now anyway.
"Oooh, nekkid pictures of Anna K...erm...wait..."
Hold onto your hats, flags, coffee cups, lizards, penguins,
swirly things, spacecraft, flying stars, ...
