Results of the 2013 State of Clojure and ClojureScript survey
cemerick.com
cemerick.com
My biggest wish is for the ClojureScript compiler to be less accepting of stupid code. I've made all kinds of moronic mistakes[2] that would ideally yield a warning or even a straight-up error, right at the source, but they don't and I just end up finding data structures full of nils at runtime. I've also hit a few traps with lein-cljsbuild[3][4]. This is all definitely improving though.
I've now started my first real Clojure project, a web app built on Luminus[5]. Luminus kind of strikes me as training wheels for Clojure. It's easy to get started with, and minimizes the sense of foreign-ness coming from a Python web development background. But I doubt I'll still use it once I have more experience, as opposed to simply putting its component libraries (Compojure, Ring, lib-noir, etc.) into a project directly. Which is fine; it fills a valuable role in the ecosystem anyway.
1. https://github.com/graue/dumbbell
2. Example: http://dev.clojure.org/jira/browse/CLJS-639
3. https://github.com/emezeske/lein-cljsbuild/issues/239
Then I did a bit of work with ClojureScript and core.async. WOW! The difference is night-and-day. Even with ECMAScript 6 generators, vanilla JS will have a hard time competing with the CLJS/core.async combo.
Of course, CLJS is very young (somewhere between pre-alpha and beta), and core.async even more so. For that reason, I don't think it's that unexpected that there aren't many people using CLJS exclusively...but I would not be surprised at all if this changes in the coming years.
It still doesn't read as nicely, but it's interesting to see how it could work.
-It had been abandoned by its creator in favor of a newer framework.
-The functions used in the tutorial had been deprecated.
These are definitely just growing pains and not something intrinsically bad about Clojure. However, I hope that the next year or two bring more stability and more ease of learning.
One thing that I wish was better tutorialized is LightTable. I understand Chris Granger is a one man IDE developer and that LT is still in development. However, if we could get more tutorials from users like the one that was posted earlier today, that would be fantastic.
Eventually I ran into pedestal.io. Those guys have a great framework. It covers front and back end, and involves Functional Reactive Programming, something I'd never seen before. They have an excellent tutorial that they update in sync with the framework. It's a bit overkill for my personal (mostly static) website, but after taking the time to learn it I feel like I came away with a real new skill.
One last thing that struck me about the Clojure community is how many workhorses there are. Guys like cemerick, technomancy and Chris Granger (the guy behind LightTable) have been working fast to build TONS of stuff, and a lot of it works really well. In particular, Leiningen is awesome and I imagine (I've never not used it) that it makes the process of getting started that much easier.
Yeah, while you can use pedestal-services to create normal websites, it seems Luminus (or one of the others) would be better suited. Pedestal really shines when you build single page applications.
(If you're curious why Clojure in clojure is important, in the recent Cognicast episode with Ambrose Bonnaire-Sergeant he give's a perfect example of how these tools make it possible to add a type system to Clojure.)
As these are Clojure-Core libraries, I'm fairly certain you'd need to submit a CA before you can submit a pull request (details here: http://clojure.org/contributing). Probably the biggest help you could provide in the near-term, though, would be to find interesting uses for these libraries.
I'm profoundly surprised by this, and would have expected the opposite -- frustrated Clojure programmers wishing for opportunities to use the language in their day job. Is there a market failure here and can we fix it?
When I was starting, I ended up just learning to read the function source because of the lacking documentation. It's a skill that has paid off in the end, but i'm not sure it was the best way.
IMO it's this and discoverability of libraries for non-core functionality. The books for learning Clojure are all very good, but reading a book is a lot different than working down a tutorial.
Another thing is if getclojure could get some pruning and discussion of corner/edge cases for each core function/macro/special forms (i.e. get some of the discussion from IRC of how/when to use the functions and maybe make it more hoogle-like)
Documenting function inputs and outputs could use core.typed's annotations to enhance the docs.
Documenting expected behavior leans towards adding content and examples, where the examples can be manually curated or pulled from available opensource code. (Similar to getclojure.org, but bigger.)
Solving bad discovery could be approached by improving the search/organization/unification of the clojure.github.io, the cheatsheet, clojuredocs.org, clojure-toolbox.org and clojure-doc.org.
So, what did they want exactly?
There are actually many, many documentation resources right now (seemingly enough for anyone to get started), so the question is really whether actual docs are lacking or just the right place(s) to start for specific kinds of docs.
More than half of respondents are using Clojure at work, which is a big jump compared to the last two years, when only a third of respondents were so lucky. This is nothing but good.
People using Clojure in their work environment is a great thing.
For those who haven't seen it, Nightcode is a new, open-source Clojure and Java IDE written by the person I'm replying to. Has project templates, paredit mode, REPL and CLJS build integration. I only played around with it for 5 minutes and went back to Vim, so I can't really endorse it but it looks cool.