Yes Chas, you're definitely no stranger in the Clojure community :) (I watched your O'reilly webcast btw).
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.
> if we look back at the history of Java, it offers a few "real" improvement over C++ such as garbage collection
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.)
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' ;-)
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.
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.
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.
"if a bunch of them head over to Scala because they like the look of {{{}}} instead of ((())), so be it"
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'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.