Re: 2013 State of Clojure ClojureScript survey results
Two follow-ups categorizing results from the missing language and weaknesses questions: http://tech.puredanger.com/2013/11/19/state-of-clojure-language-features/ http://tech.puredanger.com/2013/12/01/clj-problems/ Alex On Monday, November 18, 2013 1:32:56 PM UTC-6, Chas Emerick wrote: Results of this year's survey are available here: http://cemerick.com/2013/11/18/results-of-the-2013-state-of-clojure-clojurescript-survey/ Thank you to all that participated! Best, - Chas -- -- 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.
Re: 2013 State of Clojure ClojureScript survey results
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.
Re: 2013 State of Clojure ClojureScript survey results
On Wed, Nov 27, 2013 at 1:41 PM, Brian Craft craft.br...@gmail.com wrote: 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. I don't have anything to contribute to this thread except to point out that this statement passed as fact does not correspond with reality. David -- -- 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.
Re: 2013 State of Clojure ClojureScript survey results
The increased # of questions probably also reduces survey conversion ... I ran out of time because it was so long, and had a lot of other things to do, so I didn't submit my entry this year. On Tue, Nov 19, 2013 at 7:09 PM, Sean Corfield seancorfi...@gmail.comwrote: Yes, the path separator is O/S dependent: user (import '(java.io File)) java.io.File user (reduce #(File. %1 %2) [one two .. three]) #File one/two/../three user (.getCanonicalFile (reduce #(File. %1 %2) [one two .. three])) #File /Developer/workspace/worldsingles/ws/model/clojure/worldsingles/one/three user (.getPath (reduce #(File. %1 %2) [one two .. three])) one/two/../three Note that .getCanonicalFile renders the file path relative to the directory in which the REPL's JVM instance was started. Sean On Tue, Nov 19, 2013 at 7:02 PM, Cedric Greevey cgree...@gmail.com wrote: On Tue, Nov 19, 2013 at 10:02 AM, James Reeves ja...@booleanknot.com wrote: I think in this case it's more a problem with the Java API, which the fs library wraps. Until Java 7, I don't think relative path normalisation existed in the core Java libraries. It didn't, and .toPath isn't in the 1.6 java.io.File class in particular. 1.6 gives you these options: user= (reduce #(File. %1 %2) [one two .. three]) #File one\two\..\three user= (.getCanonicalFile (reduce #(File. %1 %2) [one two .. three])) #File C:\Windows\System32\one\three user= (.getPath (reduce #(File. %1 %2) [one two .. three])) one\\two\\..\\three Of these only getCanonicalFile normalizes, but it also makes it absolute, treating it as having been relative to (on the Win32 box I tested it on) the OS system directory of all places. It *is* interesting that Ruby Pathname objects and Java File objects get printed very similarly by Ruby and Clojure, respectively. I assume that / will replace \ as the separator (and the base directory used by getCanonicalFile will vary) if the above is used on other operating systems' JVMs. -- -- 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. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- 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. -- -- 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.
Re: 2013 State of Clojure ClojureScript survey results
One note on the ordering questions: each of them were constructed to present a randomized ordering to each new respondent, so there was no bias introduced by a default ordering. Cheers, - Chas On 11/18/2013 03:09 PM, kovas boguta wrote: Great job Chas. Some notes on methodology and then some general comments - That the survey was not featured on HN this time without a doubt alone accounts for the slight dip in responses - The 'missing' people are more likely fall into the 'hobbyist' camp, which might explain the increased % of people using clojure at work in this year's survey - The increased # of questions probably also reduces survey conversion (I wonder how many people viewed versus completed the survey) - There is some bias inherent to the initial ordering in the reordering-based questions; I for one dragged the most important items to the top, and didn't carefully think about changing the ordering beneath that. I find it impressive that 76% of respondents report using clojure for web development. This, in spite of a lack of a unified web framework stretching from the DB to the client, and general confusion in the masses about what the best solution to use is. On Mon, Nov 18, 2013 at 2:32 PM, Chas Emerick c...@cemerick.com wrote: Results of this year's survey are available here: http://cemerick.com/2013/11/18/results-of-the-2013-state-of-clojure-clojurescript-survey/ Thank you to all that participated! Best, - Chas -- -- 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. -- -- 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.
Re: 2013 State of Clojure ClojureScript survey results
On Monday, November 18, 2013 3:58:10 PM UTC-8, kovasb wrote: There are a large number of high quality libraries like instaparse, cascalog, storm, overtone, friend, etc. I find it pretty easy to tell the difference between a hobby and production project. Besides the typically liveliness measures, its also helpful to know the reputation (or lack thereof) of the people behind the projects. Yes, there are these fairly advanced libraries in very specific domains, but the core libraries are extremely weak. For example, I have a project with rather modest requirements, one of them being abstract path manipulation. In javascript: path.normalize(path.join(one, two, .., three)) 'one/three' ruby: irb(main):003:0 Pathname.new(one) + two + .. + three = #Pathname:one/three python: os.path.normpath(os.path.join(one, two, .., three)) 'one/three' In clojure, people recommend me.raynes.fs: = (fs/file one two .. three) #File /inside/home/craft/cavm/one/two/../three ugh. = (fs/normalized-path (fs/file one two .. three)) #File /inside/home/craft/cavm/one/three um, no. Turns out there is no abstract path join + normalization in me.raynes.fs. I haven't found an alternative in clojure. This is trivial to work around, but I hit this kind of thing constantly with every clojure library I use: clojure libraries are about 70% implemented, and 90% correct, which makes a weak foundation. I was amused to find the Lisp Curse article a few weeks ago, which describes this situation. It's often easier to write something from scratch than to patch one of the partially-implemented libraries. But this scales poorly, and one is truly starting from zero with clojure. Of course clojure is a relatively new language, with a much smaller number of users than javascript, python, and ruby, so I expect the libraries to be less complete. What I don't expect is clojure users to report that the libraries are just great. Clojure libraries are very weak compared to other modern languages. -- -- 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.
Re: 2013 State of Clojure ClojureScript survey results
This is trivial to work around, but I hit this kind of thing constantly with every clojure library I use: clojure libraries are about 70% implemented, and 90% correct, which makes a weak foundation. I was amused to find the Lisp Curse article a few weeks ago, which describes this situation. It's often easier to write something from scratch than to patch one of the partially-implemented libraries. But this scales poorly, and one is truly starting from zero with clojure. Of course clojure is a relatively new language, with a much smaller number of users than javascript, python, and ruby, so I expect the libraries to be less complete. What I don't expect is clojure users to report that the libraries are just great. Clojure libraries are very weak compared to other modern languages. Don't you think it counts that you can easily use the underlying platform's facilities? If you are using ClojureScript with nodejs, you can just use the path functions present there. If you are using Clojure on the JVM, you have an equivalent option. This may even be the explanation that you feel Clojure libraries are 70 % implemented, because it is so easy to use what is already available. I don't think it is always feasible or a good idea to reimplement the platform's facilities just to make them look more Clojuresque. Furthermore, I don't believe that you can even consider it unidiomatic to use your platform through Clojure's interop. Remember, one of Clojure's value proposition is exactly that: the ability to reuse the libraries already available on the host platform. Best regards, Patrick -- -- 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.
Re: 2013 State of Clojure ClojureScript survey results
I realize that's just an example, but I wouldn't expect to need anything other than interop to do this (off the top, maybe java.nio.file.Path can be constructed directly?): (defn normalize-path [ rest] (- (reduce #(new java.io.File %1 %2) rest) .toPath .normalize)) On Tue, Nov 19, 2013 at 8:22 AM, Brian Craft craft.br...@gmail.com wrote: On Monday, November 18, 2013 3:58:10 PM UTC-8, kovasb wrote: There are a large number of high quality libraries like instaparse, cascalog, storm, overtone, friend, etc. I find it pretty easy to tell the difference between a hobby and production project. Besides the typically liveliness measures, its also helpful to know the reputation (or lack thereof) of the people behind the projects. Yes, there are these fairly advanced libraries in very specific domains, but the core libraries are extremely weak. For example, I have a project with rather modest requirements, one of them being abstract path manipulation. In javascript: path.normalize(path.join(one, two, .., three)) 'one/three' ruby: irb(main):003:0 Pathname.new(one) + two + .. + three = #Pathname:one/three python: os.path.normpath(os.path.join(one, two, .., three)) 'one/three' In clojure, people recommend me.raynes.fs: = (fs/file one two .. three) #File /inside/home/craft/cavm/one/two/../three ugh. = (fs/normalized-path (fs/file one two .. three)) #File /inside/home/craft/cavm/one/three um, no. Turns out there is no abstract path join + normalization in me.raynes.fs. I haven't found an alternative in clojure. This is trivial to work around, but I hit this kind of thing constantly with every clojure library I use: clojure libraries are about 70% implemented, and 90% correct, which makes a weak foundation. I was amused to find the Lisp Curse article a few weeks ago, which describes this situation. It's often easier to write something from scratch than to patch one of the partially-implemented libraries. But this scales poorly, and one is truly starting from zero with clojure. Of course clojure is a relatively new language, with a much smaller number of users than javascript, python, and ruby, so I expect the libraries to be less complete. What I don't expect is clojure users to report that the libraries are just great. Clojure libraries are very weak compared to other modern languages. -- -- 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. -- -- 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.
Re: 2013 State of Clojure ClojureScript survey results
Brian Craft craft.br...@gmail.com writes: For example, I have a project with rather modest requirements, one of them being abstract path manipulation. In javascript: path.normalize(path.join(one, two, .., three)) 'one/three' ruby: irb(main):003:0 Pathname.new(one) + two + .. + three = #Pathname:one/three python: os.path.normpath(os.path.join(one, two, .., three)) 'one/three' In clojure, people recommend me.raynes.fs: = (fs/file one two .. three) #File /inside/home/craft/cavm/one/two/../three ugh. = (fs/normalized-path (fs/file one two .. three)) #File /inside/home/craft/cavm/one/three um, no. Turns out there is no abstract path join + normalization in me.raynes.fs. I haven't found an alternative in clojure. This is trivial to work around, but I hit this kind of thing constantly with every clojure library I use: clojure libraries are about 70% implemented, and 90% correct, which makes a weak foundation. I was amused to find the Lisp Curse article a few weeks ago, which describes this situation. It's often easier to write something from scratch than to patch one of the partially-implemented libraries. But this scales poorly, and one is truly starting from zero with clojure. One of the interesting questions, I think, is the embrace the host notion. One solution to the problems you describe is to just use the equivalent java libraries. Is this a failure of the clojure library ecosystem or a pragmatic solution? Phil -- -- 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.
Re: 2013 State of Clojure ClojureScript survey results
2013/11/19 Phillip Lord phillip.l...@newcastle.ac.uk Brian Craft craft.br...@gmail.com writes: For example, I have a project with rather modest requirements, one of them being abstract path manipulation. In javascript: path.normalize(path.join(one, two, .., three)) 'one/three' ruby: irb(main):003:0 Pathname.new(one) + two + .. + three = #Pathname:one/three python: os.path.normpath(os.path.join(one, two, .., three)) 'one/three' In clojure, people recommend me.raynes.fs: = (fs/file one two .. three) #File /inside/home/craft/cavm/one/two/../three ugh. = (fs/normalized-path (fs/file one two .. three)) #File /inside/home/craft/cavm/one/three um, no. Turns out there is no abstract path join + normalization in me.raynes.fs. I haven't found an alternative in clojure. This is trivial to work around, but I hit this kind of thing constantly with every clojure library I use: clojure libraries are about 70% implemented, and 90% correct, which makes a weak foundation. I was amused to find the Lisp Curse article a few weeks ago, which describes this situation. It's often easier to write something from scratch than to patch one of the partially-implemented libraries. But this scales poorly, and one is truly starting from zero with clojure. One of the interesting questions, I think, is the embrace the host notion. One solution to the problems you describe is to just use the equivalent java libraries. Is this a failure of the clojure library ecosystem or a pragmatic solution? YMMV : a pragmatic solution to not have to do host interop, which is less supported by text editors / IDEs than aliased clojure functions :-) -- -- 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.
Re: 2013 State of Clojure ClojureScript survey results
2013/11/19 Brian Craft craft.br...@gmail.com What I don't expect is clojure users to report that the libraries are just great. Clojure libraries are very weak compared to other modern languages. 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. -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- 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.
Re: 2013 State of Clojure ClojureScript survey results
On 19 November 2013 14:22, Brian Craft craft.br...@gmail.com wrote: For example, I have a project with rather modest requirements, one of them being abstract path manipulation. In javascript: path.normalize(path.join(one, two, .., three)) 'one/three' ruby: irb(main):003:0 Pathname.new(one) + two + .. + three = #Pathname:one/three python: os.path.normpath(os.path.join(one, two, .., three)) 'one/three' In clojure, people recommend me.raynes.fs: = (fs/file one two .. three) #File /inside/home/craft/cavm/one/two/../three What about: (- (io/file one two .. three) .toPath .normalizePath) I think in this case it's more a problem with the Java API, which the fs library wraps. Until Java 7, I don't think relative path normalisation existed in the core Java libraries. - James -- -- 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.
Re: 2013 State of Clojure ClojureScript survey results
Laurent PETIT laurent.pe...@gmail.com writes: One of the interesting questions, I think, is the embrace the host notion. One solution to the problems you describe is to just use the equivalent java libraries. Is this a failure of the clojure library ecosystem or a pragmatic solution? YMMV : a pragmatic solution to not have to do host interop, which is less supported by text editors / IDEs than aliased clojure functions :-) Oh, I've written an reasonably large library over the top of a Java API which adds (relatively) little but adds a nice syntax, in a evaluative environment, and hides a few of the boring details (using Stuart Sierra's top antipattern in clojure http://stuartsierra.com/2013/03/29/perils-of-dynamic-scope!). I really don't know the answer to the question yet. Phil -- -- 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.
Re: 2013 State of Clojure ClojureScript survey results
2013/11/19 Phillip Lord phillip.l...@newcastle.ac.uk Laurent PETIT laurent.pe...@gmail.com writes: One of the interesting questions, I think, is the embrace the host notion. One solution to the problems you describe is to just use the equivalent java libraries. Is this a failure of the clojure library ecosystem or a pragmatic solution? YMMV : a pragmatic solution to not have to do host interop, which is less supported by text editors / IDEs than aliased clojure functions :-) Oh, I've written an reasonably large library over the top of a Java API which adds (relatively) little but adds a nice syntax, in a evaluative environment, and hides a few of the boring details (using Stuart Sierra's top antipattern in clojure http://stuartsierra.com/2013/03/29/perils-of-dynamic-scope!). I really don't know the answer to the question yet. Me neither, I can just observe that those days, I'm writing little wrappers over the libraries I learn (in the Eclipse world), starting with just very thin wrappers just to isolate interop. And that I build upon that. A layer after the other. Too early to draw any conclusion for me. Time will tell. -- -- 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.
Re: 2013 State of Clojure ClojureScript survey results
On Tue, Nov 19, 2013 at 10:02 AM, James Reeves ja...@booleanknot.comwrote: I think in this case it's more a problem with the Java API, which the fs library wraps. Until Java 7, I don't think relative path normalisation existed in the core Java libraries. It didn't, and .toPath isn't in the 1.6 java.io.File class in particular. 1.6 gives you these options: user= (reduce #(File. %1 %2) [one two .. three]) #File one\two\..\three user= (.getCanonicalFile (reduce #(File. %1 %2) [one two .. three])) #File C:\Windows\System32\one\three user= (.getPath (reduce #(File. %1 %2) [one two .. three])) one\\two\\..\\three Of these only getCanonicalFile normalizes, but it also makes it absolute, treating it as having been relative to (on the Win32 box I tested it on) the OS system directory of all places. It *is* interesting that Ruby Pathname objects and Java File objects get printed very similarly by Ruby and Clojure, respectively. I assume that / will replace \ as the separator (and the base directory used by getCanonicalFile will vary) if the above is used on other operating systems' JVMs. -- -- 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.
Re: 2013 State of Clojure ClojureScript survey results
Yes, the path separator is O/S dependent: user (import '(java.io File)) java.io.File user (reduce #(File. %1 %2) [one two .. three]) #File one/two/../three user (.getCanonicalFile (reduce #(File. %1 %2) [one two .. three])) #File /Developer/workspace/worldsingles/ws/model/clojure/worldsingles/one/three user (.getPath (reduce #(File. %1 %2) [one two .. three])) one/two/../three Note that .getCanonicalFile renders the file path relative to the directory in which the REPL's JVM instance was started. Sean On Tue, Nov 19, 2013 at 7:02 PM, Cedric Greevey cgree...@gmail.com wrote: On Tue, Nov 19, 2013 at 10:02 AM, James Reeves ja...@booleanknot.com wrote: I think in this case it's more a problem with the Java API, which the fs library wraps. Until Java 7, I don't think relative path normalisation existed in the core Java libraries. It didn't, and .toPath isn't in the 1.6 java.io.File class in particular. 1.6 gives you these options: user= (reduce #(File. %1 %2) [one two .. three]) #File one\two\..\three user= (.getCanonicalFile (reduce #(File. %1 %2) [one two .. three])) #File C:\Windows\System32\one\three user= (.getPath (reduce #(File. %1 %2) [one two .. three])) one\\two\\..\\three Of these only getCanonicalFile normalizes, but it also makes it absolute, treating it as having been relative to (on the Win32 box I tested it on) the OS system directory of all places. It *is* interesting that Ruby Pathname objects and Java File objects get printed very similarly by Ruby and Clojure, respectively. I assume that / will replace \ as the separator (and the base directory used by getCanonicalFile will vary) if the above is used on other operating systems' JVMs. -- -- 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. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- 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.
2013 State of Clojure ClojureScript survey results
Results of this year's survey are available here: http://cemerick.com/2013/11/18/results-of-the-2013-state-of-clojure-clojurescript-survey/ Thank you to all that participated! Best, - Chas -- -- 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.
Re: 2013 State of Clojure ClojureScript survey results
Great job Chas. Some notes on methodology and then some general comments - That the survey was not featured on HN this time without a doubt alone accounts for the slight dip in responses - The 'missing' people are more likely fall into the 'hobbyist' camp, which might explain the increased % of people using clojure at work in this year's survey - The increased # of questions probably also reduces survey conversion (I wonder how many people viewed versus completed the survey) - There is some bias inherent to the initial ordering in the reordering-based questions; I for one dragged the most important items to the top, and didn't carefully think about changing the ordering beneath that. I find it impressive that 76% of respondents report using clojure for web development. This, in spite of a lack of a unified web framework stretching from the DB to the client, and general confusion in the masses about what the best solution to use is. On Mon, Nov 18, 2013 at 2:32 PM, Chas Emerick c...@cemerick.com wrote: Results of this year's survey are available here: http://cemerick.com/2013/11/18/results-of-the-2013-state-of-clojure-clojurescript-survey/ Thank you to all that participated! Best, - Chas -- -- 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. -- -- 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.
Re: 2013 State of Clojure ClojureScript survey results
Wow, this result is shocking to me: In short, Clojure libraries are easy to find, their maintainers are receptive to feedback and patches, they are technically of high quality, but they’re not always very well-documented. None of that is surprising or particularly different from last year. This could not be more starkly different than my experience. I'm not sure I've used a clojure library that doesn't have quirky bugs like hanging at exit, blowing the heap by holding the heads of seqs, or just doing the wrong thing. Also, I find it difficult to find libraries. When I do find libraries they're often deprecated, or moribund. What's the easy way to find clojure libraries? On Monday, November 18, 2013 11:32:56 AM UTC-8, Chas Emerick wrote: Results of this year's survey are available here: http://cemerick.com/2013/11/18/results-of-the-2013-state-of-clojure-clojurescript-survey/ Thank you to all that participated! Best, - Chas -- -- 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.
Re: 2013 State of Clojure ClojureScript survey results
I used to find libraries using github's now-modified-to-the-point-of-uselessness explore feature. Its probably still possible to set up a decent search though. There are a large number of high quality libraries like instaparse, cascalog, storm, overtone, friend, etc. I find it pretty easy to tell the difference between a hobby and production project. Besides the typically liveliness measures, its also helpful to know the reputation (or lack thereof) of the people behind the projects. On Mon, Nov 18, 2013 at 4:01 PM, Brian Craft craft.br...@gmail.com wrote: Wow, this result is shocking to me: In short, Clojure libraries are easy to find, their maintainers are receptive to feedback and patches, they are technically of high quality, but they’re not always very well-documented. None of that is surprising or particularly different from last year. This could not be more starkly different than my experience. I'm not sure I've used a clojure library that doesn't have quirky bugs like hanging at exit, blowing the heap by holding the heads of seqs, or just doing the wrong thing. Also, I find it difficult to find libraries. When I do find libraries they're often deprecated, or moribund. What's the easy way to find clojure libraries? On Monday, November 18, 2013 11:32:56 AM UTC-8, Chas Emerick wrote: Results of this year's survey are available here: http://cemerick.com/2013/11/18/results-of-the-2013-state-of-clojure-clojurescript-survey/ Thank you to all that participated! Best, - Chas -- -- 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. -- -- 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.
Re: 2013 State of Clojure ClojureScript survey results
On Mon, Nov 18, 2013 at 4:01 PM, Brian Craft craft.br...@gmail.com wrote: Also, I find it difficult to find libraries. When I do find libraries they're often deprecated, or moribund. What's the easy way to find clojure libraries? There's http://www.clojure-toolbox.com, but your mileage may vary. Viewing the commit log on GitHub shows that it's still being updated. https://github.com/weavejester/clojure-toolbox.com/commits/master -- -- 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.
Re: 2013 State of Clojure ClojureScript survey results
I will second http://clojure-toolbox.com and I also recently found: http://www.clojuresphere.com/ On Monday, November 18, 2013 4:01:27 PM UTC-5, Brian Craft wrote: Wow, this result is shocking to me: In short, Clojure libraries are easy to find, their maintainers are receptive to feedback and patches, they are technically of high quality, but they’re not always very well-documented. None of that is surprising or particularly different from last year. This could not be more starkly different than my experience. I'm not sure I've used a clojure library that doesn't have quirky bugs like hanging at exit, blowing the heap by holding the heads of seqs, or just doing the wrong thing. Also, I find it difficult to find libraries. When I do find libraries they're often deprecated, or moribund. What's the easy way to find clojure libraries? On Monday, November 18, 2013 11:32:56 AM UTC-8, Chas Emerick wrote: Results of this year's survey are available here: http://cemerick.com/2013/11/18/results-of-the-2013-state-of-clojure-clojurescript-survey/ Thank you to all that participated! Best, - Chas -- -- 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.
