

Has Clojure development stalled? - mcav
http://offtopic.bestinclass.dk/post/2532135003/has-clojure-development-stalled

======
cemerick
This post pissed me off a bit. My comment here, for those that only read
comments on HN:

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+...](http://dev.clojure.org/display/design/Better+infrastructure+for+contributed+libs)), 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.

~~~
technomancy
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.

~~~
richhickey
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.

~~~
technomancy
> 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/...](http://groups.google.com/group/clojure/browse_thread/thread/85a56203788e1283/f5f79245c41ba83c)

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.

~~~
richhickey
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.

------
fogus
I asked a similar question[1] of Arc many moons ago and received an
interesting answer from pg[2] that I think applies:

    
    
        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.
    

Rich and Stuart Halloway have indeed been silent in the public forums
recently, but I seriously doubt that they have stalled one iota.

[1]: [http://blog.fogus.me/2009/02/06/yegge-clojure-arc-and-
lolita...](http://blog.fogus.me/2009/02/06/yegge-clojure-arc-and-lolita-or-
days-of-future-past/)

[2]: <http://news.ycombinator.com/item?id=470254>

[3]: Hammock-driven development <http://clojure.blip.tv/file/4457042/>

~~~
Semiapies
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.

~~~
j_baker
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.

~~~
Semiapies
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.

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

------
jacquesm
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.

------
budu
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! ;-)

------
gfodor
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.

------
jamesaguilar
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.

~~~
swannodette
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
    

Projects that have been talked about but no-one's helmed:

    
    
      * Predicate dispatch
      * Datalog (fast enough for the above)
    

Community projects in development:

    
    
      * design for asynchronous code (think Microsoft's Rx Extension)
      * network REPL
      * unification library
      * exception/conditions design
    

I could go on, but you get the idea.

~~~
puredanger
Also: * integrating fork-join!

~~~
fogus
Also:

    
    
      * Scopes
      * Better type inferencing
      * letmacro
      * The things in Rich's mind that are baking

------
spooneybarger
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.

