Dan Sugalski <[EMAIL PROTECTED]> wrote:
> More importantly, what we're doing is outside Java's area of competence.
> We're writing system-level code here. Java isn't a system-level programming
> language. This isn't a bad thing, but it means it's an inappropriate
> solution to the problem. We might as well write perl 6 in perl.
I think that Java is closer to system-level programming than Perl, and
certainly not as close as C.
However, I don't think we should dismiss it out of hand because people don't
do a lot of systems programming C. some of the things we are going to build
for C (if that's what we pick), are already there automatically in Java,
such as:
* garbage collection for internal data structures
* vtables
And, it will make the barrier for entry for new internals hacker lower.
I just don't think we should dismiss Java out of hand because it isn't
traditionally used for systems-level programming.
> 1) Targeting a single compiler, no matter whose it is, is a bad
> idea. We're writing in a *language*, not for a compiler. Targeting a
> specific compiler restricts us even more than choosing a language.
I would note that if we write in Java, we aren't targeting a single
compiler, although at the moment, the only efficient compiler for Java might
be GCJ.
> 2) GCC produces slow code on all platforms where there's an alternative.
This is likely going to change with the release of GCC 3.0, based on current
benchmarks of test releases of GCC 3.0.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
