Results of the 2012 State of Clojure survey(cemerick.com)
cemerick.com
Results of the 2012 State of Clojure survey
http://cemerick.com/2012/08/06/results-of-the-2012-state-of-clojure-survey/
6 comments
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.
Leiningen has "just-worked" for me from day one. Everything I have wanted to do has not only been possible, but very straightforward.
It's also incredibly impressive that cake and lein were competing, and decided to join forces to bring the advantages of both to lein. We're not on lein2 yet, but it looks pretty compelling.
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.
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.
> the best way to do that would be to make tools that make beautiful documentation easy.
Really? I find it hard to believe that the problem is caused by a lack of tools. Clojure already has five or six tools for spitting out a programmatically-generated HTML overview of the shape a given project.
Instead I think it's clear the reason this doesn't happen is that good documentation is really difficult to write and people don't want to put the necessary effort into it. Putting aside the obvious problem that good English prose is really difficult to write, you have to overcome the fact that the people qualified to write the documentation don't much benefit from it. On top of that, it's very difficult for an experienced user to put himself in the mindset of a beginner.
In fact, I'd go so far as to say that the existence of all this existing documentation tooling only goes to reinforce the harmful notion you can just run something like marginalia over your codebase and publish the HTML output somewhere and consider your project documented. Sure, API overviews are valuable as a reference, but they're mostly just a distraction to someone starting out who just wants to figure out whether the project is a good fit for their needs. Long-form prose documentation is crucial at that stage, and it's awfully hard to come by.
http://jacobian.org/writing/great-documentation/what-to-writ...
Anyway the tooling is trivial--getting an overview of the API and docstrings has been done over and over, and rendering a pile of prose in markdown files is hardly rocket science. The real problem is cultural.
Really? I find it hard to believe that the problem is caused by a lack of tools. Clojure already has five or six tools for spitting out a programmatically-generated HTML overview of the shape a given project.
Instead I think it's clear the reason this doesn't happen is that good documentation is really difficult to write and people don't want to put the necessary effort into it. Putting aside the obvious problem that good English prose is really difficult to write, you have to overcome the fact that the people qualified to write the documentation don't much benefit from it. On top of that, it's very difficult for an experienced user to put himself in the mindset of a beginner.
In fact, I'd go so far as to say that the existence of all this existing documentation tooling only goes to reinforce the harmful notion you can just run something like marginalia over your codebase and publish the HTML output somewhere and consider your project documented. Sure, API overviews are valuable as a reference, but they're mostly just a distraction to someone starting out who just wants to figure out whether the project is a good fit for their needs. Long-form prose documentation is crucial at that stage, and it's awfully hard to come by.
http://jacobian.org/writing/great-documentation/what-to-writ...
Anyway the tooling is trivial--getting an overview of the API and docstrings has been done over and over, and rendering a pile of prose in markdown files is hardly rocket science. The real problem is cultural.
We don't actually disagree - I said just before that that we need to push it into the culture :) The way to do that is to make beautiful docs the norm, which is what I tried to add to Noir and Korma. And you're right, it is really hard, but we need to at least convince people to try. While not solved purely at a tooling level, I think tooling can go a long way here by creating interesting and obvious ways to document things in a more meaningful manner than simple API docs. If the cannonical tools for the language are all encouraging you to write long form docs, I have a hard time believing that everyone will simply ignore that.
In the end, however, it comes down to us; the people using the language and writing the libraries now to do exactly this. It's why I spent so long writing stuff for Noir and it's something we as a community that already exists need to do better.
In the end, however, it comes down to us; the people using the language and writing the libraries now to do exactly this. It's why I spent so long writing stuff for Noir and it's something we as a community that already exists need to do better.
Maybe. I'll withhold my judgment till I actually see such a tool, but I suspect tooling and design function more as distractions when it comes to documentation; in my eyes the only thing that matters is content.
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).
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).
> Isn't marginalia
Marginalia was never intended as a system for writing longer form docs... but truth be told I don't know what "longer form doc" means. User manuals?
In any case, Marginalia is trying to fill the "code-reading" space rather than the API and user-manual nitches. For the latter case, I've been experimenting with another tool.[1]
[1]: http://www.github.com/fogus/trout
Marginalia was never intended as a system for writing longer form docs... but truth be told I don't know what "longer form doc" means. User manuals?
In any case, Marginalia is trying to fill the "code-reading" space rather than the API and user-manual nitches. For the latter case, I've been experimenting with another tool.[1]
[1]: http://www.github.com/fogus/trout
> 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/...
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/...
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.
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.
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.
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.
I'm happy to hear that. I already made light table my main IDE for tinkering and solving 4clojure assignments. For the most part I've dumped emacs/SLIME for everything but lazy seq stuff which is problematic to run in light table - and for saving and managing project files.
Good documentation with examples, especially integrated R/W documentation is absolutely essential. Integrated clojuredocs etc.
I don't think PHP would be still around if the docs were more like docs in other langs. People can give additional examples there, describe bugs, differences in various versions, even small programs demonstrating the intended use or a workaround. It could be a lot better technically but it's very clear that it is super useful and a great time saver.
Good documentation with examples, especially integrated R/W documentation is absolutely essential. Integrated clojuredocs etc.
I don't think PHP would be still around if the docs were more like docs in other langs. People can give additional examples there, describe bugs, differences in various versions, even small programs demonstrating the intended use or a workaround. It could be a lot better technically but it's very clear that it is super useful and a great time saver.
> I think we just need to push documentation into the community's culture
Yes.
> and I imagine the best way to do that would be to make tools that make beautiful documentation easy.
Well, we've already got "built-in" tools that make handsome docs (maybe not beautiful, but certainly nice enough :) ). That is to say, almost all Clojure projects are on github and github automatically renders .md files into lovely html. With syntax highlighting too, if you label your blocks like so:
> In terms of the {snip} discovery problem
I'm hoping [this](https://github.com/uvtc/clojure-dining-car) might help address that, if it gets some more community traction.
Yes.
> and I imagine the best way to do that would be to make tools that make beautiful documentation easy.
Well, we've already got "built-in" tools that make handsome docs (maybe not beautiful, but certainly nice enough :) ). That is to say, almost all Clojure projects are on github and github automatically renders .md files into lovely html. With syntax highlighting too, if you label your blocks like so:
```clojure
(some :clojure "code")
```
> In terms of the {snip} discovery problem
I'm hoping [this](https://github.com/uvtc/clojure-dining-car) might help address that, if it gets some more community traction.
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...) and it seems to be a similar case with Clojure.
And Python and Ruby are sure languages, people like to program in.
And Python and Ruby are sure languages, people like to program in.
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.
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.
>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.
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.
I guess you could also somewhat argue, that programmers who have already potentially jumped (or diversified) from something that was more mainstream (PHP, Java, C# etc.) to Python/Ruby - are more prone to jump or at least try out new languages.
Or more cynically they have a higher potential of being language hipsters :)
Or more cynically they have a higher potential of being language hipsters :)
Ruby and Python programmers HAVE to be able to switch, otherwise they're unemployable. I can't think of any pure-python (or ruby) stack, and if you can't maintain your stack, you're going to have problems.
Python and Ruby devs will probably continue to move to Clojure and Go for the concurrency models. The multicore reality is only going to become more relevant, and right now Clojure and Go have the most compelling concurrency stories.
> 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.
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.
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. ;-)
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. ;-)
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".
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".
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.
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.
They have both have immutable data structures and i realized just now, that is after GC the second most important feature i want in a high level language.
Ok. and what answer did you leave for this survey, given that "Clojure" is not valid? ;P
Prior to Clojure, my primary languages were Ruby and Erlang. Where Clojure or Java libraries are available, Clojure is typically a functional superset of Ruby. Blocks are used as weak macros, that sort of thing. Erlang/OTP is pretty unique in my experience; while actor models are common in various languages, nothing comes close to OTP's treatment of failure modes, upgrades, and distribution. I also miss Erlang's pattern matching, though Clojure's destructuring bind is sufficient for many cases.
... so... you agree with me, that having to choose a single primary language doesn't work. The question was both worded quite explicitly to force you to choose a single language, and if you add up all of the percentages you can tell that the original form actually required only a single answer. My feedback was "people often don't have a single answer to this question", and after you spent multiple paragraphs attempting to claim I was wrong, when I asked you to actually tell me how you'd have answered the question, you came back with two answers. The question either needs to be reworded to allow for multiple answers or it needs to be reworded (in the way I attempted to provide an actual example of, putting in actual effort on my part to help future implementations of this survey) to help the person answering choose a single one.
Choosing a single primary language does work because it's an informal web survey about a programming language. It's not a contract or a test of loyalty/zealotry. Your position here seems like getting upset when asked what your favorite sandwich is.
I am someone who is interested in Clojure trying to learn something from a survey that was posted, and I'm providing constructive feedback (explicitly constructive, as I went out of my way to carefully come up with an improved wording that could be used for one of the questions) to further that goal. To help demonstrate that the question was confusing, I asked someone here to answer it, and he came up with multiple answers to the question, which was the very way I claimed that the question failed, as the question only allowed a single answer. I don't care about "contracts" or "loyalty/zealotry": I care about trying to come up with an improved survey that has answers that mean something. I'm "sorry" that no one else does, and that they would rather type long replies about how much they love Clojure than discuss issues in question design on a survey... whatever.
I answered "Ruby" on the survey without question: in my case, it has significantly broader applicability than Erlang.
In more general terms: no, I don't see this as a critical methodological error. Could it be "Pick your top n"? Sure, might be useful. Yet, I've never met a programmer who had trouble with "What's your [primary|favorite] language?", and the survey made it clear what to do in cases where more than one option applied: pick one, and don't worry too much. Survey design is always a balance between specificity and nuance, and I think in this case he made an OK call.
In more general terms: no, I don't see this as a critical methodological error. Could it be "Pick your top n"? Sure, might be useful. Yet, I've never met a programmer who had trouble with "What's your [primary|favorite] language?", and the survey made it clear what to do in cases where more than one option applied: pick one, and don't worry too much. Survey design is always a balance between specificity and nuance, and I think in this case he made an OK call.
[deleted]
As I said somewhere in the post, I am not a survey or polling professional. So, I'm sure mistakes have been made.
But: I don't think many people have the same trouble with this question as you do. A particular type of discussion recurs with programmers, whatever their background, around which languages one has used over the years. Inevitably, people characterize their usage into a serialized narrative. For example, mine is: BASIC (C-64) -> assembler (again, C-64) -> BASIC (Amiga this time) -> C -> RealBasic -> C++ -> Java -> Python -> Scala -> Clojure.
Of course there are overlaps and dozens, hundreds of "secondary" or otherwise concurrently-used languages splattered about, but that doesn't prevent most people from being able to construct that narrative. The question simply aims to find out what other people slot into the last position in their progression (or, second-to-last, if they already consider themselves to be 'Clojure programmers').
And, if there is any internal indecision about what one's primary language is, the fact that only one answer could be given forces the issue through the lens of personal identification and affinity, which is far more valuable than defining "primary" as "language spent the most time with". e.g. Even if, through some sordid turn of events, I were to spend 70% of my time programming in JavaScript, I'd still report myself as a Clojure programmer if I could only name one language.
But: I don't think many people have the same trouble with this question as you do. A particular type of discussion recurs with programmers, whatever their background, around which languages one has used over the years. Inevitably, people characterize their usage into a serialized narrative. For example, mine is: BASIC (C-64) -> assembler (again, C-64) -> BASIC (Amiga this time) -> C -> RealBasic -> C++ -> Java -> Python -> Scala -> Clojure.
Of course there are overlaps and dozens, hundreds of "secondary" or otherwise concurrently-used languages splattered about, but that doesn't prevent most people from being able to construct that narrative. The question simply aims to find out what other people slot into the last position in their progression (or, second-to-last, if they already consider themselves to be 'Clojure programmers').
And, if there is any internal indecision about what one's primary language is, the fact that only one answer could be given forces the issue through the lens of personal identification and affinity, which is far more valuable than defining "primary" as "language spent the most time with". e.g. Even if, through some sordid turn of events, I were to spend 70% of my time programming in JavaScript, I'd still report myself as a Clojure programmer if I could only name one language.
So, in my 70/30 example, the goal was to demonstrate that there were two reasonable paths for someone in that situation to start using Clojure, and that if this question were worded differently it would be possible to get useful information out of it: you could tell whether Clojure's "main in-mind competitor" was Python or JavaScript; this could be done in a way that even removed the mental biases of how a developer self-associates himself, because the question could be made resilient to such.
After all, there is a goal to the question other than to just ask people "what're all y'r favorite languages out there in ClojureLand!", right? If not, then sure: the question as answered might be somewhat vaguely reasonable, in that it is more "free association in the mind of the person answering the question"; but if you have some actual purpose to asking, maybe to provide better "how to move from language X to Clojure" documentation, or to know on what forums and in what magazines outreach efforts should be coordinated, or to get a feel for the kinds of language and library features that people may be missing, the question as stated isn't really going to help, and may as well be replaced with the much simpler "what is your favorite non-Clojure language".
Again: the developer might actually consider himself a JavaScript developer, consider JavaScript even to be the one true language that binds all other languages together and by which all other languages should be understood, and thereby is his "primary language", and yet in his world he just replaced every single moment he used to use Python with Clojure. The answer "JavaScript" is then of some vague interest, but honestly he wasn't even using JavaScript for these tasks before even though he theoretically could have been: for some reason the kind of task he is now using Clojure for was dominated before by Python in his mind, and that's what it is going to be compared to and what it is going to be replacing.
After all, there is a goal to the question other than to just ask people "what're all y'r favorite languages out there in ClojureLand!", right? If not, then sure: the question as answered might be somewhat vaguely reasonable, in that it is more "free association in the mind of the person answering the question"; but if you have some actual purpose to asking, maybe to provide better "how to move from language X to Clojure" documentation, or to know on what forums and in what magazines outreach efforts should be coordinated, or to get a feel for the kinds of language and library features that people may be missing, the question as stated isn't really going to help, and may as well be replaced with the much simpler "what is your favorite non-Clojure language".
Again: the developer might actually consider himself a JavaScript developer, consider JavaScript even to be the one true language that binds all other languages together and by which all other languages should be understood, and thereby is his "primary language", and yet in his world he just replaced every single moment he used to use Python with Clojure. The answer "JavaScript" is then of some vague interest, but honestly he wasn't even using JavaScript for these tasks before even though he theoretically could have been: for some reason the kind of task he is now using Clojure for was dominated before by Python in his mind, and that's what it is going to be compared to and what it is going to be replacing.
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.
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.
Are there equivalent surveys for Haskell / Erlang / other functional languages?
Why is Clojure the only community that does this?
Why is Clojure the only community that does this?
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-ha...
Because Chas is awesome? :)
Haskell community surveys and reports have been going on since the early 00s
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!