Re: bindings and assignments (was: Re: continuations)

[Guy Steele - Sun Microsystems Labs <address@hidden>]

   Date: Thu, 21 Aug 2003 12:42:12 -0700
   Subject: Re: bindings and assignments (was: Re: continuations)
   Cc: ll1-discuss@ai.mit.edu
   To: Guy Steele - Sun Microsystems Labs <Guy.Steele@sun.com>
   From: James McCartney <asynth@io.com>
   
   
   On Thursday, August 21, 2003, at 10:41 AM, Guy Steele - Sun 
   Microsystems Labs wrote:
   
   > Actually, the prototype implementation *did* allow non-final
   > variables to be referenced from within inner classes.  There was
   > an outcry from *users*, complaining that they did not want this!
   > The reason was interesting: in order to support such variables,
   > it was necessary to heap-allocate them, and (at that time, at least)
   > the average Java programmer was still pretty skittish about heap
   > allocation and garbage collection and all that.  They disapproved
   > of the language performing heap allocation "under the table" when
   > there was no occurrence of the "new" keyword in sight.
   
   I find this very ironic. It is too bad that programmers who do not use 
   Java *because* it doesn't have closures were not asked about this 
   issue, instead of those programmers who were already willing to make 
   such a compromise. This decision insured that this potential new 
   audience's desires will not be met.

Some such programmers were asked, and we got a number of reactions,
including, "Ugh, bletch, even if you support full closures, they'll
be really ugly with all that syntax...  I'm sticking to Lisp!"

Please remember that the design of a programming language consists
not just in a laundry list of features, but also in making judicious
choices of what to *omit* and, more importantly, in establishing
design principles that are easy to understand.

Java does not support decimal arithmetic well, nor classic coroutines,
nor full IEEE 754 floating-point arithmetic, nor computed GOTO,
nor Fortran-style (or Common Lisp-style) FORMAT operations, nor
automatic backtracking, nor pattern matching, nor unification of
PROLOG-style expressions, nor tail calls, nor a host of other features.
I've been beat up pretty hard over some of these.  Some of them I even
argued for myself in the early days of Java (such as tail calls).
But others simply aren't needed for the clientele Java is trying to
serve.

One of the early design principles of Java was that heap allocation
occurrs if and only if a construct involving the "new" keyword is
executed.  Adding full-blown closures violated this design principle.
(Dynamic class loading also violated the principle, but users seemed
to be comfortable with that, perhaps because they believed that
"once the computation got going" no more heap allocation would occur.)

Other features for Java release 1.5 will perform certain kinds
of autoboxing, which also violates the design principle.  This fact
will make it easier to argue for restoring full-blown support
for closures in the future.

--Guy Steele