

Clojure and Complexity (2011) - GetSSL_me
http://lisp-univ-etc.blogspot.kr/2011/11/clojure-complexity.html

======
discreteevent
"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.

~~~
PuercoPop
But then if Lisp is the goal, why stop at halfway to it?

~~~
spacemanaki
Because selling C++ programmers on Java was hard enough ;)

The full discussion that quote is from is a very interesting read:
[http://people.csail.mit.edu/gregs/ll1-discuss-archive-
html/m...](http://people.csail.mit.edu/gregs/ll1-discuss-archive-
html/msg04045.html)

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."
    

[http://people.csail.mit.edu/gregs/ll1-discuss-archive-
html/m...](http://people.csail.mit.edu/gregs/ll1-discuss-archive-
html/msg04056.html)

Reading through this thread is delightful, I developed quite a lot of respect
for Mr Steele.

------
moomin
A quick analysis of the article from the point of view of an ordinary Clojure
programmer: 1) Yes, it's tied to the JVM (or JS). This is a huge trade-off and
not without its costs, but it's one Clojure programmers are happy to make. 2)
You can't do reader macros: true, Rich Hickey dislikes them because of the
nasty effects they have on re-use. However, Clojure now has reader literals
which fill in _some_ of this gap. Again, a trade-off. 3) He doesn't like []
and {}. I don't really understand why: paredit copes perfectly well with them.
I never actually need to parse ))]))}) in my head. 4) Over-reliance on
recursion. Possibly true, but a decent generator macro would probably address
his issue. (And we're quite close to having one.) Bear in mind you _can_ have
mutable private state in Clojure, it's just rarely used. 5) Lazy sequences
complect sequences and streams: true. Lazy sequences are not, in fact, perfect
for all use cases. That's why reducers and async got introduced. 6) It doesn't
feel like a LISP: if that means it doesn't feel like elisp, you're not going
to catch me crying. 7) It didn't have a killer app: now it has several.

Overall, many of the criticisms are valid, but a) some are design decisions
with practical trade-offs* b) some have been addressed since the article was
written

*I mean seriously, using the JVM is a huge negative in certain ways, but does anyone believe Clojure could have got off the ground if it didn't? Rich Hickey tried other approaches for years before this one worked.

------
moomin
Of course, since the article was written, we've had Storm, Riemann and
Cascalog. That's 3 killer apps on the platform. I don't think Clojure is going
away anytime soon.

~~~
plinkplonk
Two of those (Storm and Cascalog) created by the incredibly talented Nathan
Marz. Just shows how much a few talented early adopters can push a programming
language forward.

------
kenko
"Rich argues, that defining both lists and vectors with parens (in Lisp list
is '() and vector is #()) is complecting."

Really? That strikes me as, well, kind of absurd.

The author of the linked post complains about the use of exceptions over
conditions, but you can define conditions using dynamic scope anyway:
[https://github.com/bwo/conditions](https://github.com/bwo/conditions)

------
goldfeld
I wonder, where does Scheme fall in on this whole, uhm, scheme? Especially
w.r.t. this part:

"[Clojure] doesn't have facilities to control the reader in the same way CL
does: actually, in this regard Clojure is very different from Lisp — it hardly
provides facilities for controlling any aspect of the language — and this
control is a critical part of Lisp's DNA"

Or, is Scheme as good for stratified design as CL?

