Comment by garamond97 | Hacker News Reader

Comment by garamond97 | Hacker News Reader

Parent Full thread

> Clojure is settled. It found its niche: a small/medium group of experienced professionals who like its practicality and power.

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.

Just a clarification, Clojure copyrights etc are owned by Rich Hickey, not Cognitect. Cognitect pays for all of the core development team salary, infrastructure, etc.

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?

> 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?

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.

From inside the core team, I feel entirely community-focused. I spent a good chunk of last year working on improving many aspects of error messages, the top community complaint in surveys. Currently I'm spending time working on spec and trying to guide external (community!) work on clj for Windows, also two things highly mentioned in the survey. I spent all day today answering dozens of questions in HN, reddit, slack, mailing lists, jira issues, github issues, etc. Not even sure how it's possible to be more focused on the community than I am.

Clojure on the JVM with Clojure libraries is one thing. Clojure with Java interop is quite another. Though a fine Lisp in itself, Clojure's identity is somewhat schizophrenic, hosted as it is on a platform designed for mutable OOP. This is the main reason most Java shops would never touch Clojure.

I personally believe that it is this sort of attitude that is driving some people away from Clojure. You could have easily structured your comment to be constructive instead of being defensive. The issue is not so much that people don't like how Clojure is managed, it is more so the lack of transparency and the (rather unprofessional) way that Cognitect (Rich) handles criticism and input from the community.

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.

I don't get how you go from my comment to that. I literally talk to people all day long, every day, about what we should be doing in Clojure. The idea that this is "Rich's gift" and we're not taking input from others is just wrong.

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

"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)."

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?

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

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?

Reply on news.ycombinator.com