From: "Vladimir Z. Nuri" <vznuri@netcom.com>
Date: Thu, 6 Jun 1996 15:38:04 +0800
To: Raph Levien <raph@cs.berkeley.edu>
Subject: Re: Java
In-Reply-To: <31B58982.1F54@cs.berkeley.edu>
Message-ID: <199606051901.MAA14910@netcom18.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


>
>>  c is "sort of" portable. it is
>> "in theory" portable. Java is portable "in theory and practice".
>
>   This point is simply not true, at least for Java as it exists in 
>Spring 1996. Almost every Java applet I've seen has little UI glitches 
>that prevent it from displaying and operating correctly on all 
>platforms.

you caveat, as you write it, is very significant. what I wrote about
was that the burden of portability is placed on the PROGRAMMER for
C. the burden of portability is placed on the Java language implementers
for Java. a BIG difference. Java may be *riddled* with bugs at the moment.
but who is responsible for fixing them? every single programmer in 
existence who wants to port code? (that is what effectively happens
with C makefiles) or the language designers? i.e. Java Inc.?  you
can see the tremendous difference here. the level of portability
*demanded* by the language specification of Java is far higher than
C. whether this works out in practice will take years of fine tuning.
but look how old C is-- 20 years-- and has its portability gotten
better with time, or worse? give Java another few years and its going
to be so good that no one will be arguing with supporters.

 Further, there are little glitches in the language 
>implementation and library design that often cause portability problems. 
>For example, the first cut of Hal's PGP applet had the standard UI 
>problems, plus the fact that a "spinner" thread caused the entire 
>browser to lock up -- on Unix, but not on Windows. 

whose problem is this? his or Java implementors? not his. granted,
in practice he may have to design around it. but Java is in its infancy
and you can't demand mature characteristics. as I emphasized, it
is evolving. it is a step in the right direction. you can't ask Excel
to be written before the PC has been invented. similarly, Java will
not crystallize for some time yet. (however UI problems do seem to me
to be the source of the greatest amount of intrinsic compatibility
problems. I was not wholly impressed with the labor that seemed to
go into the Java UI at first-- it seemed like a little of an afterthought)

And this was a 5000 
>line of code applet. Hal was able to fix the problems, but it's easy to 
>see how the effort involved in this "portability engineering" could 
>become comparable to your thousand-line makefile as applications scale 
>up.
>   The promise is there, but Java has not yet delivered.

I agree that in practice Java is pretty weak at the moment. but consider
how much money Sun has made from it. do you realize they poured 5M
initial development costs into it? can you be sure they will recoup
that? they probably have, but they've been incredibly generous. I am
never ceased to be amazed at how much people rant at stuff that is
given away for free or amazingly low cost.

>   Another concern with Java is that it acheives portability at the cost 
>of enforcing a lowest common denominator. For example, all real Windows 
>applications support OLE, and all real Mac applications support Apple 
>Events. Java applets, and even applications, can't do either. To me, 
>that makes the accomplishment of portability a bit less impressive, even 
>if it were so.

Java cannot solve every programming problem on the planet. it cannot
be a secure OS. it cannot give you a worldwide object standard. Java
has an event mechanism just as Apple does, and it supports object
oriented programming just as OLE is a standard associated with OO.
IMHO it did what it did well. if you want OLE go to microsoft, if
you want Apple Events program on the apple!!! if you want one language
in which you don't have to worry about every standard in the world,
try Java.