> On 10/02/2011 05:20 PM, Stuart Halloway wrote:
>> I was referring to the aggregate contrib, not a curated subset (which I
>> agree is a good idea). Maybe we should call the aggregated thing the
>> Libraries Formerly Known as Contrib (LFKAC).
> Here's how I envision the distribution structure:
>
On 10/02/2011 05:20 PM, Stuart Halloway wrote:
I was referring to the aggregate contrib, not a curated
subset (which I agree is a good idea). Maybe we should call the
aggregated thing the Libraries Formerly Known as Contrib
(LFKAC).
Here's
>> Contrarily, it seems that effort is being put into cleaning up the core and
>> jettisoning anything merely suspected of being superfluous.
> That certainly isn't an objective. Can you list some examples of things that
> in your opinion were casually jettisoned?
>
> I didn't use the word "casu
On Sunday, October 2, 2011 4:30:51 PM UTC-5, stuart@gmail.com wrote:
>
> Modularity helps, not hurts, in achieving this.
>
I can see that now. Thanks to everyone who provided clarifications about the
new contrib organization!
> Contrarily, it seems that effort is being put into cleaning up
> Stu's comment actually worries me in this respect: the fact that each contrib
> has its own version may make it easier to evaluate them separately, but it
> would appear to me as a defeatist goal for Clojure moving forward.
Things that are simple can be composited. Things that are compounds ty
On Sat, Oct 1, 2011 at 11:24 PM, Tal Liron wrote:
> You're right, it sounds in line with my hopes!
Great!
> Would it be possible to think of a better name for this sister project than
> "new contrib"? Something that implies its tight relationship with Clojure? I
> suggest "Clojure Core".
Given
On 10/02/2011 01:05 AM, Sean Corfield wrote:
Actually I think you're in a better position now. The
"new contrib"
libraries are all actively maintained and are expected to be
compatible with both Clojure 1.2.x and 1.3.0. I'm also hearing a
possibility that a "r
On Sat, Oct 1, 2011 at 10:16 PM, Tal Liron wrote:
> And the issue for me now is concern about what will happen to all
> these contribs in the future if a core language feature changes, such as the
> dynamic Var issue in 1.3. If these contribs are not being built and shipped
> as part of Clojure, i
On 10/01/2011 11:49 PM, Sean Corfield wrote:
I'm curious, what parts of contrib are you relying on that haven't
found active maintainers? Perhaps we can figure out how to address
that, to reduce your pain?
It's not that they weren't maintained. Well, I actually don't
On Sat, Oct 1, 2011 at 8:10 PM, Tal Liron wrote:
> I did realize pretty early on that the contribs were not all of prime
> quality, but what other choice did I have? Fall back to standard JVM API?
I'm curious, what parts of contrib are you relying on that haven't
found active maintainers? Perhaps
Let's talk about another context here, we have been in prod since Jan. 2009.
With a pre V1.0 version of Clojure and we used contrib in the state it was in
these early days.
Staying away from contrib in production was never a concern to us.
We just made the commitment to live with it and wait for
On Saturday, October 1, 2011 9:34:46 PM UTC-5, David Nolen wrote:
>
> To give some context:
>
I appreciate the context, David, and I agree that the change needed to
happen. It's likely my fault for not being enough in the loop to realize
what the 1.3 change would mean for me. I expected some b
On Sat, Oct 1, 2011 at 9:49 PM, Tal Liron wrote:
> On Saturday, October 1, 2011 8:25:21 PM UTC-5, Andy Fingerhut wrote:
>>
>> Tal, did you consider the possibility of staying with Clojure 1.2.1 and
>> its libraries? Or was that not under consideration for some reason?
>>
>
> It was a considerati
> Staying with 1.2 meant not only staying with the Clojure core, which worked
> fine, but also losing any progress on any of the contribs, which was frankly
> more important to me than core language changes. Perhaps part of the really
> big issue here is not Clojure per se, but the contribs. In
On Saturday, October 1, 2011 8:25:21 PM UTC-5, Andy Fingerhut wrote:
>
> Tal, did you consider the possibility of staying with Clojure 1.2.1 and its
> libraries? Or was that not under consideration for some reason?
>
It was a consideration, but the cons seemed to outweigh the pros.
Staying with
Tal, did you consider the possibility of staying with Clojure 1.2.1 and its
libraries? Or was that not under consideration for some reason?
Andy
On Sat, Oct 1, 2011 at 6:03 PM, Tal Liron wrote:
> On Tuesday, September 27, 2011 1:57:03 PM UTC-5, Arthur Edelstein wrote:
>>
>> So my request for C
On Tuesday, September 27, 2011 1:57:03 PM UTC-5, Arthur Edelstein wrote:
>
> So my request for Clojure's future development, is that backwards
> compatibility not be broken. This means that Clojure code needs a way
> of designating what Clojure version it is targeted for.
>
I'm with you, Arthur.
> So what's the plan for the future? Are there plans to make clojure
> stable at some point so that backward compatibility can be expected?
> Otherwise I am going to have difficulty continuing to advocate clojure
> to my colleagues. In other words, when will the library ecosystem be
> considered im
I think that backward compatibilities problem do hurt. Some people
will not invest in an "unstable" language by default and some will be
tempted to give up after experimenting too many problem with it.
We don't choose a language,we choose a full echosystem that include
libraries, IDE tooling, docu
On Sep 28, 2011, at 7:20 PM, Arthur Edelstein wrote:
> So what's the plan for the future? Are there plans to make clojure
> stable at some point so that backward compatibility can be expected?
> Otherwise I am going to have difficulty continuing to advocate clojure
> to my colleagues. In other wor
Improve as much as possible , performances and memory management !!
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient
> I think that clojure/core team is doing its best to ensure backward
> compatibility and break it only when there are prevalent reasons to do
> it.
So what's the plan for the future? Are there plans to make clojure
stable at some point so that backward compatibility can be expected?
Otherwise I a
I agree with Nicolas, clojure should, at this point, focus on improving the
language instead of maintain compatibility, and as most features of other
languages can be implemented as macros I think clojure is ahead of the
competition.
--
You received this message because you are subscribed to t
On Sep 28, 1:30 pm, Gary Poster wrote:
> On Sep 28, 2011, at 1:26 AM, Sean Corfield wrote:
>
> Perhaps Java has been different, but the languages I use and follow have not,
> with the exception of JavaScript. I perceive it to be a mildly unfortunate
> fact of life at this point.
>
> Gary
Java
On Wed, Sep 28, 2011 at 5:00 PM, Gary Poster wrote:
> Perhaps Java has been different, but the languages I use and follow have not,
> with the exception of JavaScript. I perceive it to be a mildly unfortunate
> fact of life at this point.
JavaScript's case might seem different because people a
On Sep 28, 2011, at 1:26 AM, Sean Corfield wrote:
> On Wed, Sep 28, 2011 at 12:03 AM, Arthur Edelstein
> wrote:
>> You may think
>> I'm doing it wrong, but I don't think I'm alone at all.
>
> I don't think you're doing anything wrong - and I'm sure many people
> only do minimal research on tool
On Wed, Sep 28, 2011 at 12:03 AM, Arthur Edelstein
wrote:
> You may think
> I'm doing it wrong, but I don't think I'm alone at all.
I don't think you're doing anything wrong - and I'm sure many people
only do minimal research on tools they use. I just think your
expectations of Clojure the langua
> When you're selecting a library to solve a particular problem, you
> normally have to do some research and evaluate more than one library
> so, for me, the activity of the project and software versions
> supported are part of that necessary research. I can't imagine "just
> using" some random lib
On Tue, Sep 27, 2011 at 7:33 PM, Arthur Edelstein
wrote:
> I hope so, too, but very often this doesn't happen in practice. Much
> useful code is not maintained.
My position on free open source software is that if it's that useful
to someone, then that someone has at least some obligation to
contr
> I hope so, too, but very often this doesn't happen in practice. Much
> useful code is not maintained.
>
> If I add a dependency from Clojars or maven central to my project.clj
> file, I don't want to pay the tax of deciding what Clojure version it
> is and whether it is actively maintained,
Clo
On Sep 27, 4:43 pm, Sean Corfield wrote:
> On Tue, Sep 27, 2011 at 4:28 PM, Brian Marick wrote:
> > I think "is it actively maintained?" is not a particularly interesting
> > question for a community. The question is: "is this a useful library?"
> > Then: "is the original author maintaining it?
On Tue, Sep 27, 2011 at 4:43 PM, Sean Corfield wrote:
> The pain of migrating from Contrib 1.2.0 (or earlier) to the New
> Contrib Libraries (whether you stay on Clojure 1.2.x or move to
> Clojure 1.3.0) is a one-time "tax" for early adopters and, as
> unpleasant as that may be, I expect future mi
On Tue, Sep 27, 2011 at 4:28 PM, Brian Marick wrote:
> I think "is it actively maintained?" is not a particularly interesting
> question for a community. The question is: "is this a useful library?" Then:
> "is the original author maintaining it?" And then, if not: "who will pick it
> up?"
Wel
On Sep 27, 2011, at 5:18 PM, Sean Corfield wrote:
> Are therein lies the problem: if they are not actively maintained,
> you're not going to get bug fixes even on Clojure 1.2.
I think "is it actively maintained?" is not a particularly interesting question
for a community. The question is: "is
On Tue, Sep 27, 2011 at 11:57 AM, Arthur Edelstein
wrote:
> raises the question of what happens to all of the many existing
> Clojure 1.2-based libraries in Clojars and on github. Many of these
> are very useful, but not necessarily actively maintained. A lot of
Are therein lies the problem: if t
I'm with Phil on that one. Legacy support slows or even hinders innovation.
On Sep 28, 2011 6:06 AM, "Phil Hagelberg" wrote:
> On Tue, Sep 27, 2011 at 11:57 AM, Arthur Edelstein
> wrote:
>> So my request for Clojure's future development, is that backwards
>> compatibility not be broken. This mean
On Tue, Sep 27, 2011 at 11:57 AM, Arthur Edelstein
wrote:
> So my request for Clojure's future development, is that backwards
> compatibility not be broken. This means that Clojure code needs a way
> of designating what Clojure version it is targeted for. Then, for
> example, the Clojure 1.4 jar s
Dear Everyone,
I would like to make a suggestion for the future of Clojure, and
hopefully prompt a discussion. My comment comes as a result of my
experience trying to port code to 1.3. I have run into numerous
problems, most of which come from 1.3's incompatibilities with my 1.2-
targeted code and
38 matches
Mail list logo
