[antlr-interest] philosophy about translation
Anthony W. Youngman
antlr at thewolery.demon.co.uk
Thu Nov 2 08:13:09 PST 2006
In message
<F89BA86F375B2F43B05CB04E01B199BA0AAF13 at castor-srvr1.benchmarkcanada.com>
, Oliver Wong <owong at benchmarkconsulting.com> writes
>
>
>-----Original Message-----
>From: antlr-interest-bounces at antlr.org
>[mailto:antlr-interest-bounces at antlr.org] On Behalf Of Anthony W.
>Youngman
>
>>>> A C compiler can compile itself. Can a Java system build itself?
>>>> How much of Java is actually written in Java? (Oh and I'm
>>>> including the supporting libraries here!)
>>>
>>>Almost all of Java is written in Java. The only part that's not
>>>is the lowest layer, which is OS and hardware specific.
>>>
>> Assembler is written in assembler, pretty much without exception.
>> C is written in C, pretty much without exception.
>
> I think you (plural) might be conflating a language with an
>implementation of the toolset for that language. Java, C and assembler
>are languages, and you can't "write" (in the sense of program) a
>language. You could program a compiler or an interpreter for these
>languages. But you can't "write" the languages themselves.
Ummm ... I see what you're getting at ... the C spec is written in
English, not C ... (plus, of course, BNF :-)
>
> And yes, there are assembler "compilers" (though an "assembler
>compiler" is typically called "an assembler") written in assembler, but
>there are also assembler compilers written in C, and possibly in Java.
>
> Similarly, there are C compilers written in C, but there may
>also be C compilers written in assembler, and there's definitely C
>compilers written in Java.
This is what I'm getting at. The C compiler should, itself, be written
using the C language. I must admit, you could almost certainly write a C
compiler in Java using Antlr :-)
>
> And there are Java compilers and Java virtual machines written
>in C, but there are also Java compilers and Java virtual machines
>written in Java (see the SableCC and SableVM projects).
>
>[...]
>> Fine. Since Java is such a great language, let's see you write
>> the BIOS for all new computers in it ... what? you mean all new
>> computers will be bricks if you do? What a crap tool ...
>
> The fact that Sun's javac compiler takes Java as an input
>language and emits JVM Bytecode as an output language is a
>characteristic of the compiler, and not of the Java language itself.
>There's no reason why you couldn't have a compiler take Java as an input
>language, and machine code as an output language (The gcj compiler does
>exactly this).
>
> I don't know what's involved in writing BIOSes, but I suspect
>that if you can program a BIOS in software (as opposed to fiddling with
>wiring at the hardware level), then you essentially need to "burn" a
>bytestream representing the BIOS program into the FlashROM containing
>the BIOS. Well, you can write a compiler which takes Java as its source
>language, and emits the appropriate bytestream in whatever format the
>FlashROM expects (which may or may not be machine code; I don't know).
>
The point I was trying to make there, is that even if you change the
compiler output from bytecode to machine code, there is NO WAY - using
Java - to express the concepts needed by a BIOS in Java source code.
Java enforces a virtual-mode paradigm onto the executable, be it
bytecode, machinecode, p-code or whatever, where it does not need to
know anything about the underlying hardware. The whole point of a BIOS
is to provide the layer between the underlying hardware and the
overlaying application. Therefore, you cannot write a BIOS in Java
because the basic philosophy of the language says "what you need to do,
I've been designed to make sure you can't do it".
I don't know whether Java is or isn't a great tool. What seems apparent
from this discussion is that it is a simple, popular tool, that is just
perfect for many situations. But to my mind that doesn't make it great.
To give a concrete example of what I *do* consider a great tool, take
WordPerfect. (Not the modern versions, they've been bastardised :-( On
the surface, it was an incredibly simple tool - start it up, start
typing, <alt-f7> print. Out comes your document (okay, dos tools weren't
that simple :-)
But it presented a very simple interface to novices. Start scratching
beneath the surface, however, and it was amazingly complex and powerful
- and easy to use with it! My opinions on Word (and OOo Writer) are
unprintable, in comparison.
Java, to me, presents me with an incomprehensible interface (though I
admit that may simply be because it's object-oriented, with which I
haven't really got to grips), and it strikes me as being fundamentally
limited. It's been DESIGNED to be fundamentally limited. I don't know
what half the missing stuff the other people are going on about even IS,
but I do know, if I wanted to use it and it weren't there, I'd be
slating Java as crap. Oh - and like pointers in C - I'd only want to use
it if I thought it were the simplest solution to my problem.
At the end of the day, it always comes back to using the right tool for
the job. And while a deliberately crippled tool may be great for the job
in hand, I don't see how it can be a great tool full stop.
At the end of the day, I know I said a great tool "has to be written in
itself". I think I'll add to that. It has to be self-contained, and
complete in its own world. FORTRAN didn't have pointers, because they're
meaningless when doing maths, but it does now have operator overloading
- you can do matrix arithmetic using +, * etc, because it DOES make
sense within FORTRAN's problem space. Java doesn't have pointers because
it doesn't make sense within its security paradigm. I don't know enough
about Java to comment on other stuff.
But it seems to me that Andy thinks the "great"ness of Java, and Antlr,
would be *improved* by deleting features that lie within their problem
space. No!!! That merely gives us crippleware.
Cheers,
Wol
--
Anthony W. Youngman - anthony at thewolery.demon.co.uk
More information about the antlr-interest
mailing list