🚀 go-pugleaf

On Sun, 25 Jan 1998 12:27:51 -0700, Robert Morelli
<morelli@math.utah.edu> wrote: 
>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.

Unfortunately, Java does not run on as many different platforms as CTeX.
Just counting different UNIXes, there are approximately 125 different
platforms.  And it is probable that CTeX can run on virtually all of
them.  That does not consider the sundry platforms based on MS-DOS, MVS,
and VMS, as well as other, more obscure platforms. 

It's not as if Java has been around long enough to have as many
compilers written, debugged, and optimized for it as there are for C.

There are, what, 3 officially supported Java platforms?  (NT, Solaris,
W95) That obviously isn't the whole list of platforms where one can run
Java code, but that is hardly as heterogeneous as what we already have
with CWEB/CTeX. 

>There's now a diversity of auxiliary tools, each available for a
>limited set of platforms,  creating problems of maintenance,
>redundancy,  and incompatibility.  

Hmm...  If such tools were targetted in some reasonably portable modern
language such as: 
- Perl
- Python
- Scheme
we might well have a higher degree of portability than there is for Java
at this time.  These languages support at least as many platforms as
Java, and have the added benefit that there are *not* billion dollar
enterprises engaged in warfare over their control and standardization... 

>Another issue is that programmers usually produce applications several
>times faster when writing in Java than when writing in C.  

Numbers, please?  This sort of multiplication of productivity is often
claimed, but evidence seems to be lacking. 

Are there objective numbers that can be verified for the assertion that
writing Java-Web code can be done at least three times faster than CWEB?
("Several" isn't particularly useful unless it refers to a value of at
least 3.)

I don't believe that there *are* objective numbers to be quoted, and am
generally skeptical of the truth of this assertion. 

>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 presume that you are assuming the introduction of some
platform-independent methodology for rendering graphics? 

There is no reason to believe that Java has anything to do with this;
Java is merely a programming language.  Java does not portably specify:
- File systems
- Directory hierarchies
- Printer rendering schemes

The "problems" with TeX's non-standardized graphics inclusion schemes
lie in the fact that there are a variety of ways of rendering graphics. 

It *could* be resolved by asserting that "the" output format would be
PostScript, which would then allow us to eliminate a whole variety of
DVI formatters, and then allow us to use \specials oriented towards use
with PS/EPS/TIFF along with some particular dvips implementation.  This
leaves people that can't use PS out in the cold.  That doesn't require
any Java transition. 

Java doesn't (and cannot reasonably) specify a file system standard,
thus it does not in and of itself provide any resolution for file system
issues. 

>Performance of java is much better than is generally realized.  

I consider *that* aspect a relative non-issue.

TeX is a relatively fast system that due to its maturity and stability
has readily taken advantage of improvements in computing technology.
Since modern computer systems are hundreds of times faster than they
were ten years ago, TeX can and does process documents hundreds of times
faster.  

Throwing some of that improvement away as a result of moving to Java
would be acceptable *assuming* that other substantive improvements would
result from the migration. 

And I don't see that Java magically resolves the issues of portability
or functionality that people have been having with TeX or LaTeX.

- When C++ came along, everybody wanted to rewrite everything in C++,
whether it needed it or not.

- When GUIs came along, everybody wanted to use WYSIWYG, whether it was
useful for the application or not.  (And "GUI", "CUA", and "WYSIWYG" are
three separate acronyms that are not in any way synomymous, not forcibly
related, and do not necessarily result in "user friendly systems."
Whatever the pointy-haired bosses may believe...)

- When Java came along, people that think it's cool stuff now want to
hammer everything into a Java-shaped hole.  Whether it's necessary or
not. 

- One of these days, Microsoft or its successor in "preeminence" may get
over the '60s technology of implementing everything as DLLs, and
discover the notion of processing data as "streams." And suddenly
everyone will decide that "streams" are really cool, and that we should
do everything that way.  And UNIX curmudgeons will complain that they've
been trying to say that since the 1970s... 
-- 
"Microsoft: The People who Brought the Y2K Bug into Software Titling"
(cbbrowne@hex.net) 
cbbrowne@hex.net -  <http://www.hex.net/~cbbrowne/lsf.html>