I recently had the experience of introducing Clojure to three coworkers for a little project we tackled (migrating our integration tests from node.js to clj). They were very open about the language (even some of the pain points), but what I’ve found it was pretty hard for them to consider switching to another editor
they would even prefer to lose clojure specific functionality (say parinfer or a good working repl) to having to change to another editor
for example, a couple of them use vs code, weren’t very happy with the parinfer integration and even after acknowledging that the sublime version worked better they chose to stick with vs code and do manual paren formatting (which seems crazy to me)
related to this is that repl integration doesn’t seem very smooth for those editors, so it’s kind of hard to introduce the idea of repl oriented dev, thus they pay jvm startup penalty a lot. They’re still happy with the language, but I fell like there are a couple of barriers preventing them to get the most out of it
my 2c hope it adds something to the discussion 🙂
I mostly think the atom solution would make a good intro environment for CLJS. Not sure if it's the best for CLJ too. That's a good anecdote in favor of providing docs and better integrations for all major editors. 👍
But I agree with @daveliepmann that many of those basic "get setup with this IDE" tutorials should live on http://clojurescript.org
Editor-wise I think the only answer is three-pronged: provide excellent up-to-date step-by-step documentation for the editor they may be using, provide excellent up-to-date step-by-step documentation for the editor you think they should be using, and proselytize superior workflows.
and proselytize superior workflows.
I think this is key, after a year of doing clojure if saw a thousand places counting repl oriented dev as one of the best aspects of clojure, but still there aren’t many resources showing how to do it
specially not aimed for newcomers
I mean most books and tutorials would show examples assuming the repl, but maybe something else can be done to stress the point that you’re not really doing it right until you do interactive development (and this is how you start doing it)
If anyone is interested in reading some complaints (some valid, some...strange) from one of the originators of this week's discourse, here's his "brain dump" in response to my query: https://www.reddit.com/r/Clojure/comments/6d0zw6/simple_aint_easy_but_hard_aint_simple_leaving/di2mblr/
"that's what you're getting for now" lol
You gotta kinda feel sorry for the guy. But he keeps on digging in. Ay caramba
At least he finally explained the specific paper cuts that he found offensive
And I think most of us would agree those paper cuts really do suck
"oh, what, lein clean didn't work? try rm -Rf ./target" blah blah
It's just not that big a deal
I spent longer then it warranted reading through the Clojure community discussions generated by that blog. In particular on the subject of “how to structure large Apps”. Which i think its not only language agnostic but problem agnostic. Reduced , it simple becomes “How do i do the thing i want to do”. Which is a matter of learning. That the project didn’t go as he had hopped an indication that the tools he used lacked something?? idk. He says Ring is confusing. As a newbie, i’m a bit confused that he was talking in terms of Ring and not something like ReFrame, it makes me unclear if he leveraged the same set of tools i would have picked up for the task he described. Rails is great for Structring large apps as those apps functionality conforms to the Rails way. Of course the tools we use shape the problems we tackle, so its easy to create a feedback loop where you become optimized for a particular task.