Subject: Re: bindings and assignments (was: Re: continuations)
Newsgroups: gmane.comp.lang.lightweight
Date: 2003-08-21 19:57:51 GMT (5 years, 45 weeks, 1 day, 22 hours and 45 minutes ago)
Date: Thu, 21 Aug 2003 12:42:12 -0700 Subject: Re: bindings and assignments (was: Re: continuations) Cc: ll1-discuss <at> ai.mit.edu To: Guy Steele - Sun Microsystems Labs <Guy.Steele <at> sun.com> From: James McCartney <asynth <at> 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