Clojure and Complexity (2011)(lisp-univ-etc.blogspot.kr)
lisp-univ-etc.blogspot.kr
Clojure and Complexity (2011)
http://lisp-univ-etc.blogspot.kr/2011/11/clojure-complexity.html
5 comments
But then if Lisp is the goal, why stop at halfway to it?
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...
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.
Reading through this thread is delightful, I developed quite a lot of respect for Mr Steele.
The full discussion that quote is from is a very interesting read: http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...
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."
Reading through this thread is delightful, I developed quite a lot of respect for Mr Steele.
Because there would be significantly less adopters? Disclaimer: I like lisp
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.
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.
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.
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.
"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
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
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?
"[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?
- 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.