🚀 go-pugleaf

NORGUET Jean-Pierre wrote:
> 
> >
> > > Have you heard about such a work ?
> >
> > It couldn't compete with native TeX implementations.
> 
> That's not so sure: go on the javaworld site, it indicates how a JIT
> compiler competes just equal with C++ native.
> Sure an interpreter genders pityful performance (from 2 to 8 times away
> from native implementations)

It seems to me that for many reasons a Java implementation of TeX
would be valuable and could very well "compete" with native
implementations (in the long run).  The TeX community is very 
heterogeneous.  A cross platform implementation opens the possibility
of pooling the contributions of people running on different platforms.
There's now a diversity of auxiliary tools,  each available for a
limited set of platforms,  creating problems of maintenance,
redundancy,  and incompatibility.  Another issue is that programmers
usually produce applications several times faster when writing in Java 
than when writing in C.  Java's cross platform abstractions
also suggest ways of standardizing some of the aspects of TeX that
are implementation specific.  For instance,  one of the biggest problems 
with TeX now is the driver specific special commands,  especially for 
inclusion of graphics.  

I envision that in a few years,  Tex tools (like most software) will
be distributed as collections of JavaBean components that plug together
with each other,  or into other Java tools.  For instance,  as a 
mathematician,  I keep most of my research notes in TeX format.  
Eventually,  I will maintain this stuff in Java based PIM/database
type applications,  with JavaBean drivers that render the TeX when
I view it.

I am personally working on (not much time though!) tools for managing BibTeX 
databases in Java.  I originally considered writing these as native,  but I 
have come to the realization that Java is much superior.

Performance of java is much better than is generally realized.  The
perception of sluggishness is due mostly to the use of java in 
browsers that typically download the code over the net before it can 
be executed.  (Java executed locally on,  say,  a Pentium II is not
likely to be a problem.)  There's also the startup time and inefficient 
use of threads and memory management in the current implementation.  
These latter issues will be (hopefully) dramatically improved in Java 
1.2,  now in beta, with further improvements in HotSpot, now in prerelease.

To improve performance in the short term,  you could, at the very least, 
put the guts in an external module written 
entirely in portable C.  The C code could be compiled by any compiler
native to your target platform.  Using Java's JNI interface,  the
java part of the code would interface with the resulting C code
identically on every platform.  The java code would handle all of
the platform specific issues like the user interface,  the text
format,  etc.

> > For example, I can compile the 500 page TeX book in 11 seconds
> > on this aging two year old Pentium.  I don't think I want
> > to go back to where I have to wait :-)
> 
> Portability has a prize and it becomes more and more cheap.
> JIT has solved this problem.
> Things can be done smoothly, can't they ?
> >
> > Also TeX has been ported already to just about any machine
> > you can think off, probably more than what Java runs on.
> >
> Alright! Let's hope it will evolve!
> So that M$ office suite monopol will give back TeX its noble titles :)
> 
> Jip