The real bummer is that Cognitect drives Clojure, and Cognitect's business is Clojure consulting. Now, if you look at some presentations about how Cognitect consults companies, you'll see that the advice often boils down to "don't use persistent data structures, use Java's", "don't use STM, use Java ConcurrentHashMap".
They stay in business by selling the cure to the poisonous snake oil they sell.
I don't have a reference for the sentiment, but I do have a couple thoughts on the matter.
The first is that I've actively used Clojure on a number of (small) projects, and tend not to have had significant performance issues with the persistent data structures. Where I have run into issues is around laziness, but that's probably a design issue more than anything else. (http://www.ksmpartners.com/2014/01/clojure-lazy-seq-and-the-...)
Having said that, I do find it very easy to believe that the persistent data structures cause performance problems. A few months ago, I was working on a small search program using ES6 and ImmutableJS. Removing ImmutableJS (and retaining the same number of object copies in my replacement code) resulted in something like a 100-fold increase in performance (making my program fit for the intended purpose.)
I need to do a bit more analysis, but my general thought on the reason why this happened is that the the data structures I was managing were too small for the structure sharing to offer any real benefit. The net result being that the negative performance impact caused by the more complex underlying data structure and API access just swamped whatever gains there were in the faster copying. Of course, for this to become favorable for the persistent data structure, the size of the data would need to be considerably larger. I don't know how common a use case that really is.
I find it highly implausible. Most likely OP ignored the full context of the statement. I can't imagine any of my co-workers recommending Java Maps over PHMs except in very rare interop situations. Likewise, I can't remember the last time I even saw a ConcurrentHashMap used in Clojure code, or STM for that matter. Most of the code I write, and work with, is as recommended for years: Persistent data in as few atoms as possible.
No ill-will directed at the OP, but it's hard not to take umbrage at the suggestion that I am a snake-oil salesman. So yes, references please!
21:40. He mentions in the video that they had a one-producer, one-consumer input queue that they originally implemented with clojure.lang.PersistentQueue. They engaged Cognitect for some code review/consulting, and Cognitect's advice was to use a regular Java ConcurrentLinkedQueue for this instead.
I think this particular example supports this "Cognitect snake oil" theory very poorly. I don't think PersistentQueue can be properly considered a first-class data structure in Clojure, as it doesn't even have a constructor function in clojure.core. The Clojure documentation, and the other writings of Rich Hickey and Cognitect don't encourage people to use this data structure. It exists, I think, for completeness and because there are some situations where it's appropriate, but unlike the core Clojure persistent data structures - maps, vectors, seqs, etc. - it's not designed as a general abstraction that covers the vast majority of general use cases.
Clojure is meant to be a practical language. It's hosted on the JVM and other platforms, and designed to make it is easy to use what those platforms provide. Where it's sensible to do so, Cognitect and other Clojure developers would certainly advocate using Java libraries to solve problems.
The other thing mentioned in the GP post was the idea of not using STM. This falls under the same umbrella. There are problems for which STM is the best solution, but there's a big space where something simpler is the right answer. In my observation, overuse of Clojure's STM is far more often the result of a developer impulse of "wow this is a cool looking feature, I want to try it" than any advocacy by Rich or Cognitect.
I also have some firsthand knowledge here, having been involved in a Cognitect engagement. I have some concerns about Cognitect as a result, but certainly nothing like this suggestion that Clojure is a real manifestation of the old fake Bjarne Stroustrup interview. [1]
Comments
The real bummer is that Cognitect drives Clojure, and Cognitect's business is Clojure consulting. Now, if you look at some presentations about how Cognitect consults companies, you'll see that the advice often boils down to "don't use persistent data structures, use Java's", "don't use STM, use Java ConcurrentHashMap".
They stay in business by selling the cure to the poisonous snake oil they sell.
I don't have a reference for the sentiment, but I do have a couple thoughts on the matter.
The first is that I've actively used Clojure on a number of (small) projects, and tend not to have had significant performance issues with the persistent data structures. Where I have run into issues is around laziness, but that's probably a design issue more than anything else. (http://www.ksmpartners.com/2014/01/clojure-lazy-seq-and-the-...)
Having said that, I do find it very easy to believe that the persistent data structures cause performance problems. A few months ago, I was working on a small search program using ES6 and ImmutableJS. Removing ImmutableJS (and retaining the same number of object copies in my replacement code) resulted in something like a 100-fold increase in performance (making my program fit for the intended purpose.)
I need to do a bit more analysis, but my general thought on the reason why this happened is that the the data structures I was managing were too small for the structure sharing to offer any real benefit. The net result being that the negative performance impact caused by the more complex underlying data structure and API access just swamped whatever gains there were in the faster copying. Of course, for this to become favorable for the persistent data structure, the size of the data would need to be considerably larger. I don't know how common a use case that really is.
Seconded, i find this plausible, but need to see a source.
I find it highly implausible. Most likely OP ignored the full context of the statement. I can't imagine any of my co-workers recommending Java Maps over PHMs except in very rare interop situations. Likewise, I can't remember the last time I even saw a ConcurrentHashMap used in Clojure code, or STM for that matter. Most of the code I write, and work with, is as recommended for years: Persistent data in as few atoms as possible.
No ill-will directed at the OP, but it's hard not to take umbrage at the suggestion that I am a snake-oil salesman. So yes, references please!
Clojure at Boeing[0]
[0] https://www.youtube.com/watch?v=iUC7noGU1mQ
Can you link a quote or a point in that video? What does Boeing's use of Clojure have to do with Cognitect?
21:40. He mentions in the video that they had a one-producer, one-consumer input queue that they originally implemented with clojure.lang.PersistentQueue. They engaged Cognitect for some code review/consulting, and Cognitect's advice was to use a regular Java ConcurrentLinkedQueue for this instead.
I think this particular example supports this "Cognitect snake oil" theory very poorly. I don't think PersistentQueue can be properly considered a first-class data structure in Clojure, as it doesn't even have a constructor function in clojure.core. The Clojure documentation, and the other writings of Rich Hickey and Cognitect don't encourage people to use this data structure. It exists, I think, for completeness and because there are some situations where it's appropriate, but unlike the core Clojure persistent data structures - maps, vectors, seqs, etc. - it's not designed as a general abstraction that covers the vast majority of general use cases.
Clojure is meant to be a practical language. It's hosted on the JVM and other platforms, and designed to make it is easy to use what those platforms provide. Where it's sensible to do so, Cognitect and other Clojure developers would certainly advocate using Java libraries to solve problems.
The other thing mentioned in the GP post was the idea of not using STM. This falls under the same umbrella. There are problems for which STM is the best solution, but there's a big space where something simpler is the right answer. In my observation, overuse of Clojure's STM is far more often the result of a developer impulse of "wow this is a cool looking feature, I want to try it" than any advocacy by Rich or Cognitect.
I also have some firsthand knowledge here, having been involved in a Cognitect engagement. I have some concerns about Cognitect as a result, but certainly nothing like this suggestion that Clojure is a real manifestation of the old fake Bjarne Stroustrup interview. [1]
[1] https://www-users.cs.york.ac.uk/susan/joke/cpp.htm
References?