[antlr-interest] philosophy about translation

[Anthony W. Youngman]

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