

Results of the 2012 State of Clojure survey - mattdeboard
http://cemerick.com/2012/08/06/results-of-the-2012-state-of-clojure-survey/

======
raju
_There’s no data from previous years to compare this to, but whatever the
curve of growth of Leiningen, technomancy & co. deserve a ton of credit for
shaving the yaks and herding the cats to build it up into what it has become
today. People’s everyday Clojure experience is greatly enhanced by the get-
out-of-the-way approach taken by Leiningen, and I think we’re all better off
for it._

Yes, yes, a thousand times yes! Phil Hagelberg (a.k.a technomancy and a fellow
HN'er) has done (along with many others) has done a great job of providing a
great stack to start working with Clojure. From emacs-starter-kit to clojure-
mode to smooth integration with leiningen, all Clojure enthusiasts and
developers alike save so much in yak-shaving.

Someday perhaps I will get a chance to say thank you in person, but allow me
to start here - Great job guys, and thank you!

~~~
mej10
I just want to second this. Especially with Leiningen, swank-clojure and
clojure-mode, getting everything set up with emacs was extremely easy. It was
exactly how it should be.

Leiningen has "just-worked" for me from day one. Everything I have wanted to
do has not only been possible, but very straightforward.

------
ibdknox
My hope is that we can do some really good things to help two of the biggest
complaints here: Tooling and Documentation.

On the tooling side, the next version of the Light Table Playground will be
even more friendly than the previous one and seeks to make it a one click
experience to go from nothing to a complete Clojure env. It's also getting
tutorial content and a few other things that should make it far easier for
people just starting out.

In terms of the documentation and discovery problem, I think we just need to
push documentation into the community's culture and I imagine the best way to
do that would be to make tools that make beautiful documentation easy. We have
codox for the generation of API docs, but nothing for longer form
documentation and I haven't seen an environment that really embraces both the
consumption and creation of docs - this is a problem I really want to see
tackled in Light Table and I think there are some very cool potential
solutions.

~~~
cldwalker
Isn't marginalia, <https://github.com/fogus/marginalia>, one attempt at longer
form docs?

As for pushing documentation into the clojure culture, having on-demand online
docs for any clojar or github repository would go a long way. We don't even
have to reinvent the wheel as it's already been done in ruby,
<http://rubydoc.info/> (source - <https://github.com/lsegal/rubydoc.info>).

~~~
technomancy
> having on-demand online docs for any clojar or github repository would go a
> long way.

How so? Isn't GitHub already its own on-demand online docs service?

<https://github.com/technomancy/leiningen/tree/master/doc>

[https://github.com/technomancy/clojure-
mode/blob/master/doc/...](https://github.com/technomancy/clojure-
mode/blob/master/doc/index.md)

~~~
cldwalker
By linking to rubydoc.info, I was referring to online docs that index
functions/namespaces/classes/files and make them searchable which is different
than reading formatted markdown.

On second thought, I'm not sure if any of this would go a long way as I don't
know clojure's culture too well yet. I just know I've found indexed docs to be
valuable in ruby when linking to and discussing a library's API.

~~~
technomancy
Yeah, the main difference is that Clojure docstrings are available at runtime,
so it's easiest just to query a running instance; you don't need to switch to
a browser to do that kind of thing.

There's a place for API reference pages, but considering that most tools to
generate it require evaling the code in question, a third-party hosting
service would have to implement some fancy sandboxing and wouldn't really
offer much over GitHub Pages since it's just static HTML.

But I don't think when people complain about documentation that they're
complaining about API reference. I suspect people want accessible tutorial-
style prose and introductions. But maybe next year's survey could distinguish
between the two.

------
mtrn
Interestingly, Rob Pike mentioned in a recent talk, that most people come to
Go from Ruby and Python ([http://commandcenter.blogspot.de/2012/06/less-is-
exponential...](http://commandcenter.blogspot.de/2012/06/less-is-
exponentially-more.html)) and it seems to be a similar case with Clojure.

And Python and Ruby are sure languages, people _like to program in_.

~~~
elarkin
I suspect that Ruby and Python programmers are likely in a better position to
switch than are programmers in other languages.

For example, if you're in the CLR or the JVM already, there's a lot of reason
not to move. Ruby and Python's relative obscurity might work to their benefit.

~~~
mtrn
>For example, if you're in the CLR or the JVM already, there's a lot of reason
not to move.

Yes, it seems economic. After investing time in the larger and more
enterprise-focused ecosystems, you'll probably have less incentives to try or
move to something else.

That's not implying, that Python and Ruby don't have great ecosystems
themselves.

------
saurik
> What language did you use just prior to adopting Clojure — or, if Clojure is
> not your primary language now, what is that primary language?

This is just a silly question: almost every single day I am using all of bash,
HTML, Python, Objective-C++, Java, C, C++, JavaScript, and SQL. This is
required because I do work on a mobile application targeting iOS, Android, and
"the browser" that has a server part and native components on the clients
(using a mix of custom and off-the-shelf open-source codebases).

So, what is my "primary language"? I'd simply argue I don't have one, and I
haven't had one for a decade. The idea of having a primary language honestly
comes off to me as a sign that the developer hasn't spent much time
programming yet: the real world has so many languages in it, and many times
the practical choice is constrained by that of the platform or existing code
to interoperate with.

The question about what language I used just prior to adopting Clojure is also
not going to work very well: it was probably bash, as I used that language to
download and setup Clojure. It may have been something like Haskell, as I
might have been in an experimenting mood that day. It could have been any of
the above "used" set (as I probably just had "learn Clojure" on my todo list
right after something else random). The result of that version of the question
doesn't really have meaning.

A much better question might be, "for the tasks that you find yourself now
using Clojure, what language do you now feel you are most using less often?"
(although spending some more time on the poor "most/less" phrasing that I left
in that might cause problems with non-English speakers). This question better
handles people who are long past the idea that they primarily code in some
specific language.

It also lets you answer the question more precisely: a person even working in
only two languages, JavaScript (client, 70%) and Python (server, 30%) who
started using Clojure on the server as a replacement for his current usage of
Python is a different kind of user than the person who started using
ClojureScript on the client as a replacement for his current usage of
JavaScript.

~~~
aphyr
_The idea of having a primary language honestly comes off to me as a sign that
the developer hasn't spent much time programming yet: the real world has so
many languages in it, and many times the practical choice is constrained by
that of the platform or existing code to interoperate with._

I've been writing code for ~18 years, ~10 professionally. I've programmed in
(chronological order here) Modula-2, C, Basic, the HTML constellation, Perl,
XSLT, Ruby, PHP, Java, Mathematica, Prolog, C++, Python, ML, Erlang, Haskell,
Clojure, and Scala. I can state unambiguously that Clojure is my primary
language: it is the most powerful, the most fun, and has the fewest tradeoffs.

Like Haskell, I view Clojure as an apex language: the best confluence of
software ideas towards a unified goal. Where Haskell excels at lazy, pure,
strongly typed problems, Clojure is my first choice for dynamic, general-
purpose programming. I wish it were faster, that it had a smarter compiler,
that it had CPAN's breadth, that its error messages were less malevolent, that
it had a strong type system for some problems. But for all this, you gain a
fantastically expressive, concise, rich language built out of strikingly few
ideas which lock together beautifully. It gives you a modern build system, a
REPL, hot code reloading, hierarchies, parametric polymorphism, protocols,
namespaces, immediate, lazy, logical, object-oriented, and functional modes,
rich primitives, expressive syntax, immutable and mutable containers, many
kinds of concurrency, thoughtful Java integration, hygenic and anaphoric
macros, and homoiconicity.

Were Clojure to cease, I would immediately endeavor to replicate its strengths
in another language. That's a primary language to me. ;-)

~~~
runT1ME
It seems to me that Clojure exists on the idealogical extreme opposite of
Haskell (standing next to it's little buddy Scala).

How did you go from one extreme to the other and pick it as your 'primary'
language.

Isn't it like saying "I really like President Obama, but my _favorite_
politician is Rick Santorum".

~~~
aphyr
Different techniques are useful for different problems. Sometimes you _really
want_ a powerful type system: it makes invariants for safety, concision, and
speed available that you can't get any other way. Other times you want a more
dynamic type system: especially where you don't really _know_ the full shape
of the problem yet. This is a choice you have to make, as a language: where on
the type continuum do you fall? It's partly technical, partly cultural. When
done well, it _pervades_ the language offering tremendous power--but it is a
_choice_.

In many other respects, Haskell and Clojure are ideologically similar. Both
emphasize immutability, referential transparency, higher-order functional
programming, and laziness. Clojure chooses to layer this on top of a mutable
core; Haskell uses monadic combinators. Again, there's a difference of
perspective. Haskell's _technical_ emphasis on purity makes powerful
invariants available to the compiler, but requires some serious type
acrobatics for concurrent stateful operations. Clojure gains the ability to
drop to mutability in a simpler way, but places the burden on the programmer
to keep track of side effects: relying on _culture_ to maintain sane
guarantees.

------
MaxGabriel
I wish Clojure could make itself more accessible to new programmers. For
example, installing Leiningen:

1\. Download the lein script 2\. Place it on your $PATH (eg. ~/bin) 3\. Set it
to be executable. (chmod a+x ~/bin/lein)

Step number one takes you text you need to copy and paste into a text editor,
but what do you save the file as? A new programmer doesn't know what his/her
$PATH is, and you can't simply cd ~/bin. And for the last step, you need to
save the file as lein, which you might not have done.

~~~
ibdknox
The goal is that with the next couple releases of the Light Table playground,
you'll get the "I just double click this" kind of experience. You won't _have_
to know what lein is, it'll be somewhat of an implementation detail.

------
Toshio
Are there equivalent surveys for Haskell / Erlang / other functional
languages?

Why is Clojure the only community that does this?

~~~
nandemo
State of Haskell, 2011:

[http://blog.johantibell.com/2011/08/results-from-state-of-
ha...](http://blog.johantibell.com/2011/08/results-from-state-of-
haskell-2011.html)

