[135] in java-interest
Re: Premature freezing of designs?
daemon@ATHENA.MIT.EDU (Scott Hudson)
Sun May 28 20:07:57 1995
From: hudson@cc.gatech.edu (Scott Hudson)
Date: Sat, 27 May 1995 22:59:20 -0400 (EDT)
To: java-interest@java.Eng.Sun.COM
> Date: Sat, 27 May 1995 13:22:47 -0700
> From: Arthur.Vanhoff@Eng.Sun.COM (Arthur van Hoff)
> To: hudson@cc.gatech.edu
> Subject: Re: Premature freezing of designs?
>
...
> I feel exactly the same way. However, stability of the language and
> its interfaces is also desirable. Based on user feedback we are
> willing to make upward compatible changes but we have to be careful
> that we don't change too much. Systems that eveolve quickly and that
> are not upward compatible between releases are not likely to become
> very successful. One of the reasons that X windows is so successful
> is that it has changed so little over time.
Funny you should use X as an example. I think it (particularly Xt) is
one of the best examples of some *really bad* design decisions being
locked in in order to preserve a code/user base. A key Xt designer
said as much at a panel discussion at UIST '91 (of course he didn't
use quite the term "really bad"). Its also a great example of just
how truly horrific the cost of this sort of thing is. Compare the
cost of creating a new widget class in Xt or Motif with a well designed
toolkit (say InterViews). That has had a very significant effect on the
quality of interfaces produced.
I think your fears of [Hot]Java not succeeding because you aren't backward
compatible, while understandable, are actually sort of silly. This is
a great system and its on an unstoppable roll. Have the courage to
pay a small price now for a larger benefit later.
>
> Check out http://java.sun.com/1.0alpha3/doc/misc/compatibility.html.
> This document describes what compatibility we are willing to commit to.
OK, I did. I don't want to be too critical, because I know its a *lot*
easier for me to say things at this end of the wire, than to do them
at that end (and you guys really are doing a *very* good job). But...
Personally, I think the fact that the Applet API is backward compatible
looks to me like a big first step in the wrong direction. Again, the
number of current users is absolutely *miniscule* compared to how many
you are going to have in a year. Your criteria for considering design
alternatives at this point ought to be "is it the best thing" with almost
no consideration for "will it be backward compatible". Your opening
sentence would say you at least partially agree, but I don't really see
that reflected in what's actually happening.
I think part of the problem/disagreement in this is that you folks have
been working on this for a long time but we've only just seen it. Hence
it seems later in the design cycle to you than it does to me.
...
> Note that we are warning applet developers that some of the APIs are
> likely to change between the alpha and beta releases.
Too late. If beta is (nearly) cast in stone, then you need iterations
within the alpha releases. (I will follow this up with a specific
proposal for how the Applet API should change.)
Scott Hudson
http://www.cc.gatech.edu/gvu/people/Faculty/Scott.E.Hudson.html
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
