Agreed. I'll add though that the problems with Clojure are soft ones. Here's my summation:

* it's business- and Java-friendly. Enterprise-focused.

* it's quite beautiful, though steeped in Java-isms

* its license is GPL-incompatible

* it's not a community-focused language and project; it's Cognitect's [edit: Rich's] project which they're graciously sharing with us.

That last one (IMO, the last two items) is a problem. For example:

* docstrings. Real improvements from the community?

* Lein? The clear winner, and yet for the longest time there was no mention of it in the getting-started guide on clojure.org, and then Boot was created. And then clj. NIH?

* It took ages until they began accepting PR's for their docs.

* I don't know the status of improving error messages. They've been complained about for years.

Clojure is Cognitect's [edit: Rich's] industrial-strength enterprise-ready Java-replacement and they sell consulting services for that. That's what Clojure is for and it's very good at that. It's also a seductively beautiful language, but if you're expecting a community-driven project with grassroots adoption and support, you're going to be disappointed.

docstrings - we apply many docstring fixes in every release.

NIH - are we literally never supposed to try to make anything new? Doesn't this non-argument apply to literally the creation of every language, library, and tool? This is silly. clj has different (quite clear) goals than Lein or Boot and both doesn't do things they do (like builds) and does things they do not (like git deps).

We have been accepting PRs for docs on the site for 3 years. Who cares how long it took before we started doing that if we're doing it now? Wouldn't it be more productive to praise for what you like than crap on how someone used to do something you didn't like?

Isn't it a good thing that Clojure is such as productive tool that it can support a consulting company that can afford to pay decent salaries so the core team can continue working full time on Clojure making it even better? This is a good thing. I suppose we can also ignore the hundreds of tickets, patches, and contributors to the language, many of whom have nothing to do with Cognitect or their consulting, as that's more convenient for this line of reasoning.

Do you think Clojure would be in a better place today if it did not have this support from a company willing to champion it? How often has that been a successful strategy for languages?

My apologies; I don't mean to insult. Thanks for the reply. My point is that it says something about what the core team thinks is important. Glad to hear that the team has been accepting doc PR's for years now.

> Isn't it a good thing that Clojure is such as productive tool that it can support a consulting company that can afford to pay decent salaries so the core team can continue working full time on Clojure making it even better?

I think we're arguing at cross-purposes. Certainly Clojure is a productive environment. But I'm interested in community-focused projects. These projects often have less corporate adoption than projects like Clojure. I was disappointed with Clojure, but not because it lacked a company championing it (it has one), not because it lacked corporate adoption (it doesn't), and not because there's anything in particular wrong with the language (I think it's an excellent language) -- by those metrics Clojure is certainly successful.

I'm amazed when people complain that they can't get their boss on board with introducing Clojure into their enterprise Java project. That appears to me to be exactly the market Clojure is targeting and succeeding in, when employed there.

I get it. Clojure is Rich's gift to the world and he will do with it as he see's fit. That's all well and good but make that clear so that people thinking about checking out Clojure know it up front.

http://insideclojure.org now has weekly journals detailing everything we're doing in Clojure dev if you're interested.

I think the build tool is the part of the tool chain where you most want a single project to rally behind. You want everyone building artifacts and expressing dependencies the same way.

Unless they all work the same at that level?

Trying to understand what you mean here. I write a lot of ClojureScript as well as Clojure and I'm not seeing Java influences in there at all.

Could you expand upon your comment a little more?

I really disagree here. My first job out of college was at a Clojure shop and it has been the easiest language I've ever learned. There is a small hurdle of switching to lisp syntax when all you've ever used is C style languages, but that's about it. I also find frameworks more effort to learn than pulling in a small library that does the one thing I need.

I suspect much of that time was spent "unlearning" habits from procedural languages.

I know Carnegie Mellon now teaches functional programming as the introductory course, and only introduces advanced topics like "mutability" later. I think that sequence makes it easier for beginners to reason about what their program is going to do and experience less frustration.

For example, consider how a beginner can write Ruby and Python in notepad.exe while a lisp would be insufferable (and a common, awful first experience for that reason). Also, some of its best features, like cider/nrepl and Paredit, are hidden behind yet more tooling and keyboard shortcuts.

It's certainly a filter.

Absence of that filter is the reason almost all of the programming crowd today is locked into advanced beginner mode all life.

Now that you've gotten everything setup, let's write a program! Open up your favorite text editor and type in the following:

puts 1+2 Save your program (yes, that's a program!) as calc.rb (the .rb is what we usually put at the end of programs written in Ruby). Now run your program by typing ruby calc.rb into your command line. It should have put a 3 on your screen. See, programming isn't so hard, now is it?

It's this sort of thing that probably drives the likes of Alan Kay crazy when even learning a language isn't interactive by default.

   (println (+ 1 2))

    clojure calc.clj