I at least partly agree with most of the replies here. Yes, interop counts for something, and I arguably should have started there, but it's orthogonal to the question of how solid clojure libraries are, on average. You might choose not to write a library because it adds nothing beyond what interop gives you. But having written a library, interop is not relevant to the quality of the library. And in this case, as others have pointed out, the host is inconsistent, so "use interop" is not a complete solution. Interop is a poor excuse for writing poor libraries. For comparison, consider that javascript library authors manage to deliver a consistent API across a much more challenging set of VMs.
Another example: I also needed binary data transforms. Gloss was recommended, but it was unreliable: it would hang at exit. smee.binary was reliable, but too slow for my application. So, I ditched them both and wrote it in java interop. But this is a painful way to develop: try clojure library, find it's buggy; try second clojure library, find it's slow; write it in interop and wonder at this point why I'm not just using java. And then there are all the globals, ugh. I was happy Stuart brought this up at Clojure/West this year. And, again, I realize it's a young language, so rough edges are expected. I'm just surprised at the poll results. On Tuesday, November 19, 2013 7:00:20 AM UTC-8, Michael Klishin wrote: > > > 2013/11/19 Brian Craft <craft...@gmail.com <javascript:>> > >> Bold statement, Brian. Surely you've tried at least 60% of the libraries >> out there to make >> > your judgement more scientific than a survey with thousands of > participants ;) > > Please try finding a sane concurrency library in Ruby, or use the standard > library primitives. > Try working with binary protocols or even basic statistical problems in > JavaScript. And ask yourself > what % of Python libraries is of the same quality as Requests. Or go work > with crypto libraries > in any of the above. > > Clojure's standard library is small but at least if you ask me, overall it > is higher quality than most languages > out there. Certainly leaps and bounds better engineering-wise than Ruby. > Random sampling to discover the shape of a distribution is entirely reasonable, doesn't require anything like 60% coverage, and isn't self-evidently worse than this poll, which of course is not well controlled. Clojure is on the fringe of the fringe among programming languages. Most developers have not found it compelling. I'm willing to bet that the state of the libraries is one factor in that result: that my opinion on this subject would be the majority opinion if the polling were broader, and not self-selecting. I partly agree with your list of design deficiencies in other languages, above, but note that many of them are solved by falling back to native code, which can be quite simple. Also, the demand for concurrency is much smaller than the need for solid core libraries. -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
