5 ms·

Much of the excitement around Clojure seems rather buzzwordy. You should check out some of its criticism, such as http://jng.imagine27.com/index.php/2009-08-19-

Much of the excitement around Clojure seems rather buzzwordy. You should check out some of its criticism, such as http://jng.imagine27.com/index.php/2009-08-19-011225_clojure_the_false_lisp.html http://jng.imagine27.com/index.php/2009-08-19-011225_clojure... and http://www.loper-os.org/?p=42 http://www.loper-os.org/?p=42

gauravk92 14y ago
These language enthusiasts forget that the best language is the best one for the task at hand. They'll get it eventually IMHO.
dkersten 14y ago
The loper os guy hates all languages that aren't the Symbolics flavour of common lisp and all systems that aren't Symbolics' Genera. His criticism of clojure is based only on those two facts and not on actual real problems or gripes with the language. He doesn't back up any claims and seems to hate clojure because its not Symbolics lisp. If I hate all food but pancakes, then my opinion on steak is hardly relevant.
- asciilifeform 14y ago
  Author of linked article speaking. I dislike Clojure because it is a cheap knock-off of Common Lisp, with no upsides that I'm aware of - besides trendiness. The article mentions one serious flaw - Clojure barfs Java stack traces, instead of serious debug information (the way Common Lisp does - with restarts, etc.) Another flaw is the lack of reader macros. But what is the point of listing said flaws? I could go on and on, and no one will care a whit. Why? Because Clojure is a product of immature minds who piss on the past work of serious people (the Common Lisp community) simply for the sake of faux-novelty. In this, it resembles Newlisp and other backwards steps disguised as progress. It is, in fact, best understood as yet another product of the idiotic language-of-the-day mentality which gave us Dylan, Python, Ruby, and the many other shoddy "infix Lisps." > hates all languages that aren't the Symbolics flavour of common lisp This is patently untrue, as anyone who actually bothers to read my articles knows well. Symbolics (or rather, the MIT Lisp machine architecture their products were based on) was simply an example of a Lisp system done well. Clojure, a thin veneer on the Java cesspool, is not. To run with your analogy, I am a lover of steak, who is upset by tofu peddlers' success in passing off their cheap trash as real meat.
  - deleted 14y ago
    [deleted]
  - Xcelerate 14y ago
    "Astonishing" is exactly what I was thinking of as well. There's a lot of vitriol in this post. You say that you could go on and on and no one would care. But that's not true. If you list good, logical arguments against something, people will listen. Instead, there's an almost instinctive urge to rebel against your points solely because of your post's tone, which is antagonistic to what I assume is your goal. In my opinion, Clojure doesn't try to one-up Lisp. Rich Hickey recognizes the great value of Lisp and wants to share these features with a wider audience -- I can't say I would have ever taken an interest in Lisp if it weren't for Clojure in fact. Check out Clojure's rationale page (http://clojure.org/rationale http://clojure.org/rationale). Rich says he wanted a language that is: *A Lisp *for Functional Programming *symbiotic with an established Platform *designed for Concurrency And he says he couldn't find one. That's not a subjective statement -- there wasn't a language with all those features before Clojure. And I'll bet there's a lot of people that want those four things. His language does that very well. That doesn't mean it should be used for everything, but he never implied it that anyway -- quite to the contrary, he explicitly points out the problem domain that Clojure addresses. I think you misunderstand the designers of these new languages. Most of them aren't trying to make something "trendy" (that should be obvious by how many esoteric hobby languages there are). They are trying to solve problems. And if some people other than the author of the language can get some use along the way, well then that's just great. Clojure isn't the product of "immature minds" either. It's the product of one mind, and one that's spent many years thinking about good language design and many years working with software in industry.
  - dxbydt 14y ago
    > Symbolics...was simply an example of a Lisp system done well Gratuitous reference: http://news.ycombinator.com/item?id=80662 http://news.ycombinator.com/item?id=80662 (checkout pg's first comment on that post ) Symbolics was the future. CS has in many ways regressed since then, mostly because of the stupendous success of worse-is-better unix/c mindset coupled with lack of DARPA funding ,the AI winter & the rise of cheap wintel cpu's. At Goldman Sachs, I was incredibly fortunate to work alongside one of the original Symbolics guys ( listed here: http://www.asl.dsl.pipex.com/symbolics/legacy.html http://www.asl.dsl.pipex.com/symbolics/legacy.html ). He complained long and hard about how the c/c++/java family of PLs were "absolute shit" and OOP was doomed from the get go and why functional will be back someday. This was back in the 1999-2000 timeframe when Sun was in the driver's seat and everywhere you looked, it was OOP or bust. Now, ten years hence, functional is all the rage, and you've got clojure, functional java, scala, several functional JS libs...all that's old is new once again! Who knows, with all this VC $$$ searching for a home, we might actually see the resurgence of a LISP Machine. Symbolics 2.0 FTW!!!
aphyr 14y ago
The author claims this first article is satire, but in case you were tempted to take it literally, allow me to rebut: Why not simply add support for concurrent programming as a library instead? Clojure's concurrency primitives are libraries. You don't have to use them; it's perfectly OK to use, say, kilim or java.util.concurrent, and many do. Why not provide both immutable and mutable versions of the same data types? The mutable variants of these structures are already there in java.util, and the stdlib is designed to interact well with java interfaces like List, Map, etc. [1] Also when writing real-world software, what about the effort required to align the multitude of Java libraries that assume an imperative environment with Clojure? I've used nontrivial Java libraries in Clojure: it looks about the same as the Java code, only shorter and with fewer parentheses. Yes, fewer. Can these libraries be used easily, safely and with the same performance? Yes. Obviously the Clojure parts won't run quite as fast as the Java parts, but interop is complete, concise, and well-designed. InvokeVirtual is InvokeVirtual either way. Meanwhile Clojure makes obvious improvements over CL in reader forms for readability: the vector, set, map, and regex literals make it much easier to write and understand. It may not be as pure as some other Lisps, but it's a competent addition to the family. [1] A property I miss in Scala. :-(
- agentultra 14y ago
  Meanwhile Clojure makes obvious improvements over CL I would beg to differ. The features you note are pretty subjective and not obvious improvements at all. I've done a few small non-trivial prototypes in Clojure. I cannot stand the syntax for literals. Or the mangled hell that is the literal for lambda. At least CL lets you define your own reader macros -- something that Clojure cannot do (yet). These features you mention are not improvements over CL IMO.
  - aphyr 14y ago
    Huh, I find the syntax for literals a breath of fresh air--but I also grew up in languages with rich data structure literals and find the {}, (), [], #"", #{} distinctions make it much easier for me to understand, at a glance, the shape of a structure. I also prefer the vector notation for arguments in (fn [arg1 arg2 & friends])--the brackets make it easier to recognize the argument boundaries, especially in one-liners. In general, Clojure code seems to have less nesting, which makes it easier for me to read and parse. You're honestly the first person I've heard express a dislike for the reader forms, so I thought it was universally liked. I think you're right: a lack of configurable reader macros is a problem. I'd also point to the lack of tail recursion (and consequent mucking about with (recur) and (trampoline) as a notable flaw in Clojure. Its error messages are pathologically malicious. On the other hand, I think Clojure's packaging environment, thanks to lein and clojars, is quite good. There also seems to be more consistency in Clojure coding... style? preference? than in CL, which I attribute partly to its young age and small user base, but also, perhaps, to a more opinionated set of attitudes around mutability and types. Regarding the #() form, I almost never reach for it, partly because it never seems to work as expected. (fn) and (partial) feel more natural to me, so I've never taken the time to understand how #() works. I also prefer Lisp-1s in general, although I understand that's a more contentious differentiation. Either way, my CL experience is minimal, so it was wrong of me to claim these as obvious improvements. I'll defer to your expertise here: it sounds like you've used CL enough to understand it better.
Ygg2 14y ago
I'd be the first to think that they would like Clojure for bringing Lisp to the "masses". What does irk me about it is that language outputs some really bizarre stack-traces and that 4clojure.com (which people recommended but it's learning curve jumps after a couple of exercise like it saw Chtulu). Speaking of learning Clojure, anyone got a good book/tutorial/demo?
- dkersten 14y ago
  Good books: Programming Clojure (2nd edition) by Stuart Halloway http://pragprog.com/book/shcloj/programming-clojure http://pragprog.com/book/shcloj/programming-clojure Clojure in Action, by Amit Rathore http://manning.com/rathore/ http://manning.com/rathore/ The Joy of Clojure, by Michael Fogus and Chris Houser http://joyofclojure.com/ http://joyofclojure.com/
  - equalsione 14y ago
    If you have no prior lisp experience then I would recommend Clojure Programming as the starting point - http://www.clojurebook.com/ http://www.clojurebook.com/ I found it to be the best beginner book on Clojure and one of the best written programming language books I've come across in a while. Programming Clojure would be a good followup. I found that Clojure Programming gives the "how" of the language and Progamming Clojure gives the "why", if that makes sense. Clojure in Action is good, but it is definitely an "In Action" book. Depends on your learning style. I've only skimmed the Joy Of Clojure. It looks really good too but I don't think it's targeted at beginners. Could be wrong.
    - unlogic 14y ago
      You are right that The Joy of Clojure is for developers with some prior experience in Clojure and it explains the "why" of the language even further.

gauravk92 14y ago

These language enthusiasts forget that the best language is the best one for the task at hand. They'll get it eventually IMHO.

dkersten 14y ago

The loper os guy hates all languages that aren't the Symbolics flavour of common lisp and all systems that aren't Symbolics' Genera. His criticism of clojure is based only on those two facts and not on actual real problems or gripes with the language. He doesn't back up any claims and seems to hate clojure because its not Symbolics lisp. If I hate all food but pancakes, then my opinion on steak is hardly relevant.

asciilifeform 14y ago
Author of linked article speaking. I dislike Clojure because it is a cheap knock-off of Common Lisp, with no upsides that I'm aware of - besides trendiness. The article mentions one serious flaw - Clojure barfs Java stack traces, instead of serious debug information (the way Common Lisp does - with restarts, etc.) Another flaw is the lack of reader macros. But what is the point of listing said flaws? I could go on and on, and no one will care a whit. Why? Because Clojure is a product of immature minds who piss on the past work of serious people (the Common Lisp community) simply for the sake of faux-novelty. In this, it resembles Newlisp and other backwards steps disguised as progress. It is, in fact, best understood as yet another product of the idiotic language-of-the-day mentality which gave us Dylan, Python, Ruby, and the many other shoddy "infix Lisps." > hates all languages that aren't the Symbolics flavour of common lisp This is patently untrue, as anyone who actually bothers to read my articles knows well. Symbolics (or rather, the MIT Lisp machine architecture their products were based on) was simply an example of a Lisp system done well. Clojure, a thin veneer on the Java cesspool, is not. To run with your analogy, I am a lover of steak, who is upset by tofu peddlers' success in passing off their cheap trash as real meat.
- deleted 14y ago
  [deleted]
- Xcelerate 14y ago
  "Astonishing" is exactly what I was thinking of as well. There's a lot of vitriol in this post. You say that you could go on and on and no one would care. But that's not true. If you list good, logical arguments against something, people will listen. Instead, there's an almost instinctive urge to rebel against your points solely because of your post's tone, which is antagonistic to what I assume is your goal. In my opinion, Clojure doesn't try to one-up Lisp. Rich Hickey recognizes the great value of Lisp and wants to share these features with a wider audience -- I can't say I would have ever taken an interest in Lisp if it weren't for Clojure in fact. Check out Clojure's rationale page (http://clojure.org/rationale http://clojure.org/rationale). Rich says he wanted a language that is: *A Lisp *for Functional Programming *symbiotic with an established Platform *designed for Concurrency And he says he couldn't find one. That's not a subjective statement -- there wasn't a language with all those features before Clojure. And I'll bet there's a lot of people that want those four things. His language does that very well. That doesn't mean it should be used for everything, but he never implied it that anyway -- quite to the contrary, he explicitly points out the problem domain that Clojure addresses. I think you misunderstand the designers of these new languages. Most of them aren't trying to make something "trendy" (that should be obvious by how many esoteric hobby languages there are). They are trying to solve problems. And if some people other than the author of the language can get some use along the way, well then that's just great. Clojure isn't the product of "immature minds" either. It's the product of one mind, and one that's spent many years thinking about good language design and many years working with software in industry.
- dxbydt 14y ago
  > Symbolics...was simply an example of a Lisp system done well Gratuitous reference: http://news.ycombinator.com/item?id=80662 http://news.ycombinator.com/item?id=80662 (checkout pg's first comment on that post ) Symbolics was the future. CS has in many ways regressed since then, mostly because of the stupendous success of worse-is-better unix/c mindset coupled with lack of DARPA funding ,the AI winter & the rise of cheap wintel cpu's. At Goldman Sachs, I was incredibly fortunate to work alongside one of the original Symbolics guys ( listed here: http://www.asl.dsl.pipex.com/symbolics/legacy.html http://www.asl.dsl.pipex.com/symbolics/legacy.html ). He complained long and hard about how the c/c++/java family of PLs were "absolute shit" and OOP was doomed from the get go and why functional will be back someday. This was back in the 1999-2000 timeframe when Sun was in the driver's seat and everywhere you looked, it was OOP or bust. Now, ten years hence, functional is all the rage, and you've got clojure, functional java, scala, several functional JS libs...all that's old is new once again! Who knows, with all this VC $$$ searching for a home, we might actually see the resurgence of a LISP Machine. Symbolics 2.0 FTW!!!

aphyr 14y ago

The author claims this first article is satire, but in case you were tempted to take it literally, allow me to rebut: Why not simply add support for concurrent programming as a library instead? Clojure's concurrency primitives are libraries. You don't have to use them; it's perfectly OK to use, say, kilim or java.util.concurrent, and many do. Why not provide both immutable and mutable versions of the same data types? The mutable variants of these structures are already there in java.util, and the stdlib is designed to interact well with java interfaces like List, Map, etc. [1] Also when writing real-world software, what about the effort required to align the multitude of Java libraries that assume an imperative environment with Clojure? I've used nontrivial Java libraries in Clojure: it looks about the same as the Java code, only shorter and with fewer parentheses. Yes, fewer. Can these libraries be used easily, safely and with the same performance? Yes. Obviously the Clojure parts won't run quite as fast as the Java parts, but interop is complete, concise, and well-designed. InvokeVirtual is InvokeVirtual either way. Meanwhile Clojure makes obvious improvements over CL in reader forms for readability: the vector, set, map, and regex literals make it much easier to write and understand. It may not be as pure as some other Lisps, but it's a competent addition to the family. [1] A property I miss in Scala. :-(

agentultra 14y ago
Meanwhile Clojure makes obvious improvements over CL I would beg to differ. The features you note are pretty subjective and not obvious improvements at all. I've done a few small non-trivial prototypes in Clojure. I cannot stand the syntax for literals. Or the mangled hell that is the literal for lambda. At least CL lets you define your own reader macros -- something that Clojure cannot do (yet). These features you mention are not improvements over CL IMO.
- aphyr 14y ago
  Huh, I find the syntax for literals a breath of fresh air--but I also grew up in languages with rich data structure literals and find the {}, (), [], #"", #{} distinctions make it much easier for me to understand, at a glance, the shape of a structure. I also prefer the vector notation for arguments in (fn [arg1 arg2 & friends])--the brackets make it easier to recognize the argument boundaries, especially in one-liners. In general, Clojure code seems to have less nesting, which makes it easier for me to read and parse. You're honestly the first person I've heard express a dislike for the reader forms, so I thought it was universally liked. I think you're right: a lack of configurable reader macros is a problem. I'd also point to the lack of tail recursion (and consequent mucking about with (recur) and (trampoline) as a notable flaw in Clojure. Its error messages are pathologically malicious. On the other hand, I think Clojure's packaging environment, thanks to lein and clojars, is quite good. There also seems to be more consistency in Clojure coding... style? preference? than in CL, which I attribute partly to its young age and small user base, but also, perhaps, to a more opinionated set of attitudes around mutability and types. Regarding the #() form, I almost never reach for it, partly because it never seems to work as expected. (fn) and (partial) feel more natural to me, so I've never taken the time to understand how #() works. I also prefer Lisp-1s in general, although I understand that's a more contentious differentiation. Either way, my CL experience is minimal, so it was wrong of me to claim these as obvious improvements. I'll defer to your expertise here: it sounds like you've used CL enough to understand it better.

Ygg2 14y ago

I'd be the first to think that they would like Clojure for bringing Lisp to the "masses". What does irk me about it is that language outputs some really bizarre stack-traces and that 4clojure.com (which people recommended but it's learning curve jumps after a couple of exercise like it saw Chtulu). Speaking of learning Clojure, anyone got a good book/tutorial/demo?

dkersten 14y ago
Good books: Programming Clojure (2nd edition) by Stuart Halloway http://pragprog.com/book/shcloj/programming-clojure http://pragprog.com/book/shcloj/programming-clojure Clojure in Action, by Amit Rathore http://manning.com/rathore/ http://manning.com/rathore/ The Joy of Clojure, by Michael Fogus and Chris Houser http://joyofclojure.com/ http://joyofclojure.com/
- equalsione 14y ago
  If you have no prior lisp experience then I would recommend Clojure Programming as the starting point - http://www.clojurebook.com/ http://www.clojurebook.com/ I found it to be the best beginner book on Clojure and one of the best written programming language books I've come across in a while. Programming Clojure would be a good followup. I found that Clojure Programming gives the "how" of the language and Progamming Clojure gives the "why", if that makes sense. Clojure in Action is good, but it is definitely an "In Action" book. Depends on your learning style. I've only skimmed the Joy Of Clojure. It looks really good too but I don't think it's targeted at beginners. Could be wrong.
  - unlogic 14y ago
    You are right that The Joy of Clojure is for developers with some prior experience in Clojure and it explains the "why" of the language even further.