2012 State of Clojure survey
cemerick.com
cemerick.com
InfoQ.com also increasingly added Clojure presentations/articles lately.
It's all good, a little bit of competition between languages is healthy. Having said that, I believe it is hard for Clojure community to convert/invite people with what you guys have done so far because there has been no killer apps/tools so far.
Is this largely because of the LISP is such a weird language that it is a lot harder to convince people to use it? Like it's almost "you need to use it for a few years to know the power of it" (otherwise it'll be like a weird version of Rails or some MVC framework).
Here's a few examples that, in my mind, are not strong enough to convince people to use Clojure:
http://www.infoq.com/presentations/Clojure-in-the-Clouds
http://www.infoq.com/presentations/Clojure-powered-Startups
When people look at Rails demos, they immediately have a feeling of how easy it is to develop web-application supported by _good practices_ (test automation, migration, MVC, etc).
When people look at VB.NET/C# WinForms demo, they know it's super easy to write GUI apps.
When people look at Python... well they knew Python was one of the best languages to write scripts/tools in UNIX/Linux environment, and to some degree, GUI apps in *NIX.
Clojure? only people who dreamed of using LISP (and know LISP already).
No offense to Clojure people, but it's just not convincing enough...
The results from the last two years of the survey (e.g. 2011's are here: http://cemerick.com/2011/07/11/results-of-the-2011-state-of-...) might be illuminating for you.
Clojure has a ton of compelling use cases, but it's stubbornly not going to fit into the shoebox of a single domain. Thus, it's going to be hard to say, "Clojure is great because it allows me to address narrow problem X". It's a general-purpose language, and increasingly, a multiplatform/multienvironment one as well.
Also, only ~7% of the respondents to last year's survey came from a Lisp. Most come from Java, Ruby, or Python. Make of that what you will re: Clojure's "weirdness".
I'm not saying that Clojure should address a narrow problem but if we look back at the history of Java, it offers a few "real" improvement over C++ such as garbage collection, nice standard library, and the promise of WORA (albeit lots of hiccups here and there). By real I mean something that people can see and immediately take advantage of.
I'm sure there are always going to be alpha-nerds who love to try new programming languages out there (especially the hip ones) but when these people are to write Clojure code or to build Clojure tools, they tend to bring their old habit from the previous language, which in turns make their code look like the previous language as opposed to something totally new, probably refreshing, or even have the potential to blow people's mind.
Perhaps the problem is that it's hard to explain referential transparency, or that the problems caused by the lack of referential transparency are less obvious than those caused by the lack of GC. I mean, I've never heard of someone reading through "Out of the Tarpit" and then saying, "why bother with something like Clojure?"
Riffing on what technomancy said nearby, a lot of the issues that Clojure addresses are so taken for granted in most of the broader software development world, that it can be challenging to wrap up its benefits into a tasty, easily digestable nugget comparable to "Java gets rid of malloc and pointers" (sorta). Some have taken some whacks at doing just this, including Paul DeGrandis' talk you linked to already, as well as "Neal Ford's master plan for Clojure enterprise mindshare domination": http://blip.tv/clojure/neal-ford-neal-s-master-plan-for-cloj...
That said, the benefits of immutability and pure functions are generally obvious to any reasonably-capable programmer (my personal bias shone forth) given 10 minutes in front of a whiteboard. Can we get the, say, 10 million Java developers to sit still long enough for that? No, probably not. Maybe a tenth of them eventually, maybe. And, if a bunch of them head over to Scala because they like the look of {{{}}} instead of ((())), so be it.
A more interesting question to me lately is, what is the objective of language evangelism? Let's set aside any notion that Clojure will be "the next Java", or even achieve the same penetration as Python or Ruby. For those of us that use the language, none of those goals are particularly important. "How many developers use language X" used to be a critical question when the language you used largely delimited the reach of your eventual application/system/whatever; that is hardly the case anymore. I can write my server side in literally anything, and transpiling to JavaScript or C for client side as necessary is either within reach, or a solved problem depending on your preferred language.
So, what should be the objective? Having a large enough pool of talent to meet business objectives is the only thing I can think of that is an actual potential blocker. I know lots of people that know Clojure that would like to work in Clojure, and there are more people like that every day. Seems like the vector is trending positive; we only need to make sure it stays that way.
(This leaves out the enterprise guys to a certain degree, but that's largely due only to their [and their managers'] self-inflicted risk profile.)
Finally, I leave you with this:
http://www.indeed.com/jobanalytics/jobtrends?q=clojure%2Chas...
Note that those are absolute trendlines, not growth. You can very reasonably say that Clojure is the most in-demand functional programming language. (…for some definition of 'functional programming language' ;-)
http://www.indeed.com/jobtrends?q=java%2Cclojure%2Chaskell%2...
Having any "most in-demand functional programming language" seems to be a bit silly. In the larger view, there simply isn't any demand.
I REALLY want this to change. I think if Clojure can make some inroads to the enterprise, there will be trickle-down effect that will help increase opportunities to work in Clojure. I think increasing working opportunities is what language evangelism is for.
As a hacker who loves the repl, functional programming, weird languages, and was at the first Clojure/conj, it is not clear to me at all that immutability and pure functions are wins in general - lots of excellent working systems are out there that don't bother using this stuff at all (no silver bullet is kind of what I am driving at). I might instead argue that in the hands of good-to-great hackers, that immutability and pure functions offer some benefits that are hard to quantify when you normalize across raw hacker abilities.
PS - Thanks so much for the book. A large part of Clojure's success is directly attributable to the high quality and number of books that have popped up so soon in its life as a programming language.
Some additional perspective: http://www.indeed.com/jobtrends?q=java%2Cruby%2Cpython%2C%22...
The Java market is massive. Nearly everything else is essentially background noise compared to it. I'm skeptical that any single language will ever have the same reach as it.
Runtimes, on the other hand, are a different story. The JVM, standardized JavaScript engines, even the CLR/Mono to some extent: polyglot sandboxes where you have the leverage to use whatever language will get the job done. That's a huge win for, as you put it, good-to-great hackers, trying to find the edge of what's next.
'course, that's a wash to a loss (i.e. increased risk) for those with the enterprise mindset. Thus, Java 8 with its closures may very well consolidate its position in such environments.
Glad you enjoyed the book, BTW. :-)
http://www.indeed.com/jobtrends?q=sql%2Cjava&l=
I had not thought deeply about runtimes in relation to this question. It's certainly true that one reason I can hack around in Clojure and count on that code running on our production servers is that the JVM is ubiquitous there. Quite a different story than when I was doing some stuff in SBCL and had to compile it in my user space.
Unnecessary (if slight) nastiness directed towards (developers choosing) Scala. Unworthy of you (imo). There are significant differences between Scala and Clojure (other than {} vs ()) and trivializing a valid choice of one over another by ascribing it to fear of parantheses (or whatever) isn't a particularly compelling argument.
I've never really noticed Scala devs (leave alone book authors!) throwing darts at Clojure, but have seen the reverse (and at Haskell, on the Clojure mailing list but Rich Hickey shut that down hard and fast, good for him). Sad, and unnecessary (imo).
Scala and Clojure are both awesome and (totally imo) evangelizers of both languages should realize we are all on the same side (again totally imo, feel free to ignore).
Yes there are trolls in all language communities, but I think the expectations about the top developers in each community are (and should be) much higher.
Otherwise, solid comment. And hey, your book is awesome.
I guess some of us are start over all the time. But at least this time I've read through a half of Clojure in Action and going through 4clojure exercises to "finally get started".
This time using instarepl by Chris instead of LaClojure or Emacs/Slime (where just a tiny subset works for me).
And it's fun! If only errors were not such a drag. I guess complains from 2011 will repeat on those...
To some extent, I don't think any "killer app" is going to change that, although it certainly wouldn't hurt. The concurrency features are pretty compelling in that space already.
Clojure's primary appeal is not, and cannot be, that it's easy for most programmers out there right now. The appeal is that once you learn it, it's a better general purpose programming language that runs on the JVM.
Maybe that's the power of Clojure?
I really think that it will take a few years before a select few (persistent users, not alpha-geeks) from the Clojure community can come up with some sort of breakthrough that replaces today's best practices, whether it is the replacement of the whole OOP/*DD-movement or the way testing is done, or something else, I don't know. But I do believe that this is what needed.
Unfortunately, most people judge difficulty in terms of familiarity, so the strangeness is off-putting even if it wouldn't be that hard for them to learn.
Would be nice if the apps show internationalization and some way to handle Time and Money.
Would there be any other way to represent them in Clojure? (i.e.: the more Clojure-way as opposed to use JDK classes?)
If you can imagine the same benefits of working with stable values applied across the board to all your built-in data structures, that might help.
Hey, I checked your website just for fun and it says there you can speak Indonesian, awesome :).
The only thing you miss out on is that Java methods can't be used as higher-order functions.
My Indonesian is pretty rusty; I should probably update it to say that I understand it rather than speak it. =)
I'm GLAD that there is currently no killer app for Clojure, like how Rails became the killer app for Ruby. IMO Rails killed Ruby. Ruby started out in the right direction but once Rails became popular there was an influx of so-so programmers who started polluting the language with inefficient concepts, constantly reinventing the wheel poorly because they did not know enough computer science to know that a better solution had already been invented. Now the system has been bogged down by so much cruft, it is difficult to see if it still serves the purpose it was originally designed for (a language the people can enjoy programming in).
Clojure is not ready yet. The core team is still working on refining the fundamentals for what maybe can become the 100 year language [http://paulgraham.com/hundred.html] -- look at reducers in 1.4. Right now Clojure doesn't need more people. It needs more smart people. If you are not smart enough to understand why it is worth switching to it, maybe you should wait a bit and let the design mature more. The killer apps will come. Clojure's ability to scale complexity will eventually overcome its current drawbacks, as the tools and the ecosystem matures.
With OO, you have to keep track of the state of each object and how each method affects that state. With Clojure, you don't need to be concerned with the guts of a function, just the inputs and outputs. This keeps your mental stack from building up and makes programs easier to understand and debug.
Complexity covers so much, its definition so sprawling, that the phrase has no meaning.
I'd rather focus on the language's real strength, fast, concurrenty, portable computation in very well tooled managed environment with a large number of quality libraries.
I don't want to get into a situation where people think that clojure is the universally 'best' language, which is were certain people in the community are.
That POV horribly damaged ruby's popularity after Rails' rise, and I'd hate to see it happen again to another language.
I'd say python has a more even distribution in terms of use in varied fields for instance.
You're right, though, the definition is sprawling, so I think it makes sense to use smaller more precise words. The good news is we have some of these: Referential transparency, pure functions, immutability, and neologisms such as "complection". These are very useful, meaningful terms.
Software projects are becoming increasingly complex, and multicore concurrency is becoming increasingly important. Immutability and referential transparency are key ingredients in Clojure concurrency so I think the slogan is apt.
There's a big PR problem with environments that have this as a core strength: it's very hard to demonstrate this without a lot of involvement. It's very hard to demonstrate this with a "hello world." sized experience.
Request -> App Server -> Processing -> Response -> End, no state lingering around...
I do understand what you're saying but I believe the era of complex OO with states is declining, at least at web-development level...
seriously. that's how i am describing it to co-workers: a better python. that should have been scheme, i guess, but it lacked the lazy sequences to get over the "ewww parens" hill. if you're a python user that's starting to appreciate the power of generators you owe it to yourself to look at clojure.
the one thing that drives me crazy is the state of libraries: finding the right library for the right version, and then finding where the pom is. i wish that could be clearer (less confusion about versions and more direct pointers to poms/repos/IDs).
[not sure if it's relevant, but python never had a killer app. i guess it is an "unconvincing" language too...]
Once you gain paren blindness, Clojure code starts to look a lot like Python. Macros, immutability, real concurrency, destructuring all make for a much nicer experience.
That being said, Clojure just feels like a nicer Python and for me and others, Python is just fine, so why change? Concurrency is one of the promised gains in CLJ but beyond software STM, Clojure doesn't gain you much. You're still using cumbersome threads so why bother. In fact I've moved on from Clojure and started writing Erlang for highly concurrent applications. It is much more appropriate for building concurrent, robust applications. I still write a fair amount of Python for web development.