Has Clojure development stalled?(offtopic.bestinclass.dk)
offtopic.bestinclass.dk
Has Clojure development stalled?
http://offtopic.bestinclass.dk/post/2532135003/has-clojure-development-stalled
10 comments
For the record I mostly agree with this; I think it's fully appropriate for Rich and co. to have time to let ideas brew, and there's nothing wrong with a lull in their coding output. My comments in TFA taken out of context seem to imply that his is some kind of crisis--it is not.
On the other hand, if core people are going to slow down for a time, they would be wise to delegate responsibility to those who do want to continue coding on it in the mean time; having simple patches linger for six months (http://www.assembla.com/spaces/clojure/tickets/315) chills the enthusiasm of contributors. Having every single patch need approval of a single person is a policy Clojure has outgrown; somehow I don't think Rich is going to find something wrong with this substring patch that a lesser mind wouldn't have caught. (http://dev.clojure.org/jira/browse/CLJ-688)
tl;dr: Clojure isn't dying; it's growing, and the patch submission process needs to be revised.
On the other hand, if core people are going to slow down for a time, they would be wise to delegate responsibility to those who do want to continue coding on it in the mean time; having simple patches linger for six months (http://www.assembla.com/spaces/clojure/tickets/315) chills the enthusiasm of contributors. Having every single patch need approval of a single person is a policy Clojure has outgrown; somehow I don't think Rich is going to find something wrong with this substring patch that a lesser mind wouldn't have caught. (http://dev.clojure.org/jira/browse/CLJ-688)
tl;dr: Clojure isn't dying; it's growing, and the patch submission process needs to be revised.
You are simply wrong about the patch process. It is no longer the case that I am the bottleneck. Many people have worked hard to put in place the organization and systems to make sure this is so. We have meetings on a regular basis, and many people dedicate their Fridays to Clojure tickets. There are several people who vet tickets, and a few who can screen them. Tickets are rarely waiting for my final approval, and rarely waiting long after that for application. And I frequently catch things while looking at them for final ok.
None of us appreciate having our ongoing effort characterized as 'stalled'. Everything in the commit log, Jira and Confluence activity streams belies that. More people are actively involved in improving Clojure than ever.
As for CLJ-688 - it's an enhancement request. Do you think every idea for an enhancement that anyone has should make it into Clojure? I don't - it would quickly become a huge mess. If not, then someone has to look at everything and decide.
Yes, there is a backlog from when it was just me, and it will take a while to whittle down. We have finite resources and have to prioritize. I can assure you we have more important things to concentrate on than your negative index substring enhancement, and are doing so. You'll just have to be patient. Or, if you insist, I'll just reject it now because a) IMO it's goofy, b) you can make your own function that works that way c) we don't get a free ride from j.l.String, d) it begs the question of negative indices elsewhere...
Want Clojure to be a free for all? - Sorry.
Can't cope with the necessity for prioritization given finite resources? - Sorry.
Want top priority? - Sorry.
tl;dr: This blog post is the idle chatter of people who are not involved in the Clojure development process in any significant way. Lau has never submitted a single patch. Apparently his free lunch isn't arriving fast enough.
None of us appreciate having our ongoing effort characterized as 'stalled'. Everything in the commit log, Jira and Confluence activity streams belies that. More people are actively involved in improving Clojure than ever.
As for CLJ-688 - it's an enhancement request. Do you think every idea for an enhancement that anyone has should make it into Clojure? I don't - it would quickly become a huge mess. If not, then someone has to look at everything and decide.
Yes, there is a backlog from when it was just me, and it will take a while to whittle down. We have finite resources and have to prioritize. I can assure you we have more important things to concentrate on than your negative index substring enhancement, and are doing so. You'll just have to be patient. Or, if you insist, I'll just reject it now because a) IMO it's goofy, b) you can make your own function that works that way c) we don't get a free ride from j.l.String, d) it begs the question of negative indices elsewhere...
Want Clojure to be a free for all? - Sorry.
Can't cope with the necessity for prioritization given finite resources? - Sorry.
Want top priority? - Sorry.
tl;dr: This blog post is the idle chatter of people who are not involved in the Clojure development process in any significant way. Lau has never submitted a single patch. Apparently his free lunch isn't arriving fast enough.
> None of us appreciate having our ongoing effort characterized as 'stalled'.
Well TBH I'm not to thrilled that a few lines from a private chat would get splattered over the HN front page without much context either.
> Can't cope with the necessity for prioritization given finite resources? - Sorry.
Said resources are a lot more finite than they could be. There are many capable folks in the community who would be willing to help. I brought this up last year and people seemed eager to help, but the official response was silence:
http://groups.google.com/group/clojure/browse_thread/thread/...
Anyway, keep up the good work; if you at any time decide you don't want to waste time with the boring stuff keep in mind that there are lots of people who can help ease the burden.
Well TBH I'm not to thrilled that a few lines from a private chat would get splattered over the HN front page without much context either.
> Can't cope with the necessity for prioritization given finite resources? - Sorry.
Said resources are a lot more finite than they could be. There are many capable folks in the community who would be willing to help. I brought this up last year and people seemed eager to help, but the official response was silence:
http://groups.google.com/group/clojure/browse_thread/thread/...
Anyway, keep up the good work; if you at any time decide you don't want to waste time with the boring stuff keep in mind that there are lots of people who can help ease the burden.
I think you are looking right past the people who are helping, who have stepped up, volunteered, and are doing something. The priority isn't on giving the community fast response times. That is not a goal in and of itself. It is on making Clojure better.
>Said resources are a lot more finite than they could be.
That is arguable. If hundreds of people came up and said they wanted to help there would be real challenges in managing their efforts. It is something we'd have to grow into, in any case. I still contend dropping all impediments to rapid, ill-curated contributions is a recipe for a complete mess. As it stands, the 30-day report here (http://dev.clojure.org/jira/browse/CLJ) says 14 issues created, 14 resolved. So, we are at least keeping up, and many times doing better than that. The best way for folks at large to get involved is to patch bugs. Defect issues with patches are our first priority. I don't see any reason why we won't soon approach the no-known-outstanding-bugs state I used to maintain by myself in the early days. Enhancements are low priority.
Helping out at a higher level is something you earn by participating. If someone I don't know says they've screened a patch from someone else I don't know, what am I supposed to do with that? There is an ever-growing circle of people I trust, and, to the extent they have time to work on Clojure, I am taking advantage of that.
>There are many capable folks in the community who would be willing to help.
Being willing to help and helping are two different things. Helping means doing what needs to be done, not just what one feels like doing. If I gave someone commit rights and they whipped through and applied all outstanding patches they wouldn't be helping me or Clojure, however good it might make the patch submitters feel.
I guess Clojure is just too conservatively managed for your taste. That's fine, but I think it is the appropriate route for a language, even if it means it is somewhat slower and more of a hassle to participate in than the latest github project du jour.
>Said resources are a lot more finite than they could be.
That is arguable. If hundreds of people came up and said they wanted to help there would be real challenges in managing their efforts. It is something we'd have to grow into, in any case. I still contend dropping all impediments to rapid, ill-curated contributions is a recipe for a complete mess. As it stands, the 30-day report here (http://dev.clojure.org/jira/browse/CLJ) says 14 issues created, 14 resolved. So, we are at least keeping up, and many times doing better than that. The best way for folks at large to get involved is to patch bugs. Defect issues with patches are our first priority. I don't see any reason why we won't soon approach the no-known-outstanding-bugs state I used to maintain by myself in the early days. Enhancements are low priority.
Helping out at a higher level is something you earn by participating. If someone I don't know says they've screened a patch from someone else I don't know, what am I supposed to do with that? There is an ever-growing circle of people I trust, and, to the extent they have time to work on Clojure, I am taking advantage of that.
>There are many capable folks in the community who would be willing to help.
Being willing to help and helping are two different things. Helping means doing what needs to be done, not just what one feels like doing. If I gave someone commit rights and they whipped through and applied all outstanding patches they wouldn't be helping me or Clojure, however good it might make the patch submitters feel.
I guess Clojure is just too conservatively managed for your taste. That's fine, but I think it is the appropriate route for a language, even if it means it is somewhat slower and more of a hassle to participate in than the latest github project du jour.
It surprises me that important contributors like technomancy would not have some additional priority or clout. Without leiningen I doubt we would see one tenth of the explosion of interesting activity going on in the community. That said, I don't think anyone would like the results of democracy.
I think any project growing at the tremendous rate that Clojure has done is going to need significant process issues in managing all of the stuff people want to add/fix/doc/integrate. I can't even keep up on the libraries people are creating around Clojure, much less the pressure the core must be under.
It's hard to do both new dev + maintenance on any big project, much less a language so many of us feel personally invested in. Looking back to this time last year, there is a lot more infrastructure in place and on the way that builds a base for managed growth. I'm hopeful that once process stuff gets smoother it will be easier to streamline and offload some of that work. If Linus can do it, Rich can do it too.
The patches I've contributed to core have gone in (or been bounced) appropriately in reasonable time frames. One bug I submitted even got a patch from a first time contributor! That's good stuff.
Chas and everyone else in the community, many thanks for the tremendous efforts this year - I can't wait to see where we go in 2011.
It's hard to do both new dev + maintenance on any big project, much less a language so many of us feel personally invested in. Looking back to this time last year, there is a lot more infrastructure in place and on the way that builds a base for managed growth. I'm hopeful that once process stuff gets smoother it will be easier to streamline and offload some of that work. If Linus can do it, Rich can do it too.
The patches I've contributed to core have gone in (or been bounced) appropriately in reasonable time frames. One bug I submitted even got a patch from a first time contributor! That's good stuff.
Chas and everyone else in the community, many thanks for the tremendous efforts this year - I can't wait to see where we go in 2011.
I agree, under what conceivable metric could the development of Clojure appear to be stalled?
I asked a similar question[1] of Arc many moons ago and received an interesting answer from pg[2] that I think applies:
[1]: http://blog.fogus.me/2009/02/06/yegge-clojure-arc-and-lolita...
[2]: http://news.ycombinator.com/item?id=470254
[3]: Hammock-driven development http://clojure.blip.tv/file/4457042/
A lot of people seem to feel that a language
isn't real unless the designer is talking to
them every day. But that's not the only way
languages happen. Nor possibly the best way.[3]
I feel like you get better ideas if you think
in units of occasional essays rather than a
stream of tweets. It seems likely the same
will be true with language design.
[1]: http://blog.fogus.me/2009/02/06/yegge-clojure-arc-and-lolita...
[2]: http://news.ycombinator.com/item?id=470254
[3]: Hammock-driven development http://clojure.blip.tv/file/4457042/
I think that's a bit apples and oranges. Arc is a long-term project that pg has said doesn't actually "have" to be useful to anyone anytime soon. Clojure, on the other hand, is under active, public development, as swannodette points out.
I think you might be missing fogus's point to a certain degree. His point is that active, public development for a language might not necessarily mean that the language designer is keeping contact every day. You might only receive periodic updates.
I don't see cookies being all that different from Arc in that respect. Cookies doesn't have to be useful anytime soon either because, well, it is useful already.
I don't see cookies being all that different from Arc in that respect. Cookies doesn't have to be useful anytime soon either because, well, it is useful already.
I think you are arguing a connection that is at best stretched.
Fogus' point is well-meaning, but it tars an active project with the brush of being some guy's (even pg's) hobby language, like Arc.
Fogus' point is well-meaning, but it tars an active project with the brush of being some guy's (even pg's) hobby language, like Arc.
[deleted]
A pg quote AND a pg styled references list? Really?
(Downvote freely)
(Downvote freely)
No. http://dev.clojure.org/jira/browse/CLJ
If anything Clojure development has been moving too quickly for the past year :) It's clear from the mailing list and the IRC channel that people are still trying to wrap their heads around all the new ideas in 1.2.0, I know I am.
That's not even taking into account newcomers to the language that need to digest the 1.0-1.1 feature set.
Even more importantly 1.3.0 alphas have been appearing regularly and they have significant changes that people need to account for, try out in existing code bases and tools (new rules for dynamic binding, new rules for arithmetic, primitive math support, unchecked math support).
If anything Clojure development has been moving too quickly for the past year :) It's clear from the mailing list and the IRC channel that people are still trying to wrap their heads around all the new ideas in 1.2.0, I know I am.
That's not even taking into account newcomers to the language that need to digest the 1.0-1.1 feature set.
Even more importantly 1.3.0 alphas have been appearing regularly and they have significant changes that people need to account for, try out in existing code bases and tools (new rules for dynamic binding, new rules for arithmetic, primitive math support, unchecked math support).
Best in class = Clojure linkbait
I've yet to see a 'best in class' (what a way to name your self best in class anyway) post that was both correct and interesting, if they're interesting they tend to be factually wrong and if they're factually right they are boring.
The titles do make you want to click though, that's the one thing they have in common.
I've yet to see a 'best in class' (what a way to name your self best in class anyway) post that was both correct and interesting, if they're interesting they tend to be factually wrong and if they're factually right they are boring.
The titles do make you want to click though, that's the one thing they have in common.
Has Clojure development stalled? Not at all!
Is Clojure core project management frustrating for small contributors? Definitely! I also think that would be the case for most similar projects.
We must not forget that Clojure is a very young language. The core team is still getting used to running a project of this nature while continuously improving it. Also the recent move from Assembla to JIRA clearly doesn't help for now, but I'm confident that things will get more streamlined in the ((hopefully) near) future. I've personally stopped trying to contribute to core/contrib because of the slow process and JIRA (which I've not spent time learning yet (not even sure I've got the right permissions)) so that I can concentrate on libraries. One thing that is really annoying tough is that the whole patch submission process must go through the centralized issue tracker, bypassing github which I think is much better for smaller changes (and even getting quite good for the whole process).
P.S.: One sure thing is that Lau is always good at driving traffic to his blog! ;-)
Is Clojure core project management frustrating for small contributors? Definitely! I also think that would be the case for most similar projects.
We must not forget that Clojure is a very young language. The core team is still getting used to running a project of this nature while continuously improving it. Also the recent move from Assembla to JIRA clearly doesn't help for now, but I'm confident that things will get more streamlined in the ((hopefully) near) future. I've personally stopped trying to contribute to core/contrib because of the slow process and JIRA (which I've not spent time learning yet (not even sure I've got the right permissions)) so that I can concentrate on libraries. One thing that is really annoying tough is that the whole patch submission process must go through the centralized issue tracker, bypassing github which I think is much better for smaller changes (and even getting quite good for the whole process).
P.S.: One sure thing is that Lau is always good at driving traffic to his blog! ;-)
Great. Now by having this headline fly by on HN, there is going to be yet another bit of FUD I have to fight through to use Clojure when it's appropriate to do so.
One thing I always wonder when I see stuff like this: is it because development is actually stalled, or is the project just finished? At some point, it can be useful for things to stop changing except to the extent that it is require to prevent bit rot.
There's a lot left to do. Huge upcoming projects:
* Pods
* Clojure-in-Clojure compiler
* High performance higher order operations
on persistent data structures filled with primitives
* Predicate dispatch
* Datalog (fast enough for the above)
* design for asynchronous code (think Microsoft's Rx Extension)
* network REPL
* unification library
* exception/conditions design
I still want nREPL support for emacs, but I haven't had a chance to look at actually doing it...
FWIW, there's lots of stuff to be done in nREPL proper as well. Anyone interested should definitely ping me. I'll hopefully get the outstanding issues into the new JIRA in the next couple of weeks, along with a migration of the various design notes that are scattered about.
Also:
* integrating fork-join!
Also:
* Scopes
* Better type inferencing
* letmacro
* The things in Rich's mind that are baking- CLR, android
- common parse/highlight backend for emacs, vim, eclipse etc
http://dev.clojure.org/display/design/Home
- common parse/highlight backend for emacs, vim, eclipse etc
http://dev.clojure.org/display/design/Home
Especially for a new language where it takes time to build a base - time that would be well spent bringing the toolset, libraries, and frameworks up to level.
Let us pretend for a moment that is has stalled. Who cares? Look at the ground that clojure has covered recently. It has time to stall.
It hasn't stalled of course but still... just pretend.
It hasn't stalled of course but still... just pretend.
I can imagine that the people that are and have been working hard on Clojure would be dismayed by this odd chunk of unfortunate FUD. As someone that does contribute a little bit of my time to Clojure and the community, I know I am.
This, after:
* three years of absolutely breakneck progress (dare I say innovations) on almost every possible front
* the fabulous success of the first-ever Clojure conference just two months ago (http://first.clojure-conj.org) where a variety of very significant chunks of work by a number of core contributors were first announced
* the "opening up" of the contrib library space (http://dev.clojure.org/display/design/Better+infrastructure+...), with three new separately-managed contrib libraries implementing finger trees, unification, and a common REPL library (https://github.com/clojure).
* the modernization of the project's infrastructure: moving to self-hosted JIRA+confluence, a big push on utilizing hudson maximally, and support for getting all project artifacts (from Clojure itself down into all contributed libraries in the Clojure organization) flowing into Maven central
……and surely more that I'm not aware of.
I can't speak to the cadence of patch application, as I'm not involved in that side of the house. Maybe volunteering to help vet patches would help, maybe not.
In any case, it's an open effort; if you want to see movement on a particular front, step up and do something. Otherwise, idly speculating on things being "stalled" (especially "publicly" vs. just in IRC) is, frankly, bullshit, and could be detrimental to further uptake of the language and enthusiasm of volunteers that are actively contributing.