"We were not out to win over the Lisp
programmers; we were after the C++
programmers. We managed to drag a lot of them
about halfway to Lisp."
- Guy Steele, Java spec co-author
Steele seemed to be trying to encourage those who saw the glass as half empty to see it as being half full. The article makes some valid points but surely, from a high level, clojure can only be seen as a glass that's very nearly full.
Guy Steele suggests that even though some of the people working on Java at the time might have been ok with closures, it was a hard sell when programmers used to manual memory management in C++ were worried about whether things were allocated on the stack or the heap and how much control they had over them. Thus you get the awkwardness that is anonymous inner classes in Java, which are effectively closures, but by another name and papered over with boilerplate.
"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."
- Guy Steele, Java spec co-author
Steele seemed to be trying to encourage those who saw the glass as half empty to see it as being half full. The article makes some valid points but surely, from a high level, clojure can only be seen as a glass that's very nearly full.