[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bindings and assignments (was: Re: continuations)
Date: Thu, 21 Aug 2003 12:42:12 -0700
Subject: Re: bindings and assignments (was: Re: continuations)
To: Guy Steele - Sun Microsystems Labs <Guy.Steele@sun.com>
From: James McCartney <firstname.lastname@example.org>
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
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.