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:
Clojure
On Sat, Oct 1, 2011 at 10:16 PM, Tal Liron tal.li...@gmail.com 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
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
On Sat, Oct 1, 2011 at 11:24 PM, Tal Liron tal.li...@gmail.com 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
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
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
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 casually.
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).
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.
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 tal.li...@gmail.com wrote:
On Tuesday, September 27, 2011 1:57:03 PM UTC-5, Arthur Edelstein wrote:
So
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
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 one
On Sat, Oct 1, 2011 at 9:49 PM, Tal Liron tal.li...@gmail.com 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
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
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
On Sat, Oct 1, 2011 at 8:10 PM, Tal Liron tal.li...@gmail.com 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
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
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,
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
On Sep 28, 2011, at 1:26 AM, Sean Corfield wrote:
On Wed, Sep 28, 2011 at 12:03 AM, Arthur Edelstein
arthuredelst...@gmail.com 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
On Wed, Sep 28, 2011 at 5:00 PM, Gary Poster gary.pos...@gmail.com 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
On Sep 28, 1:30 pm, Gary Poster gary.pos...@gmail.com 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
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
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 am
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
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 words,
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
On Tue, Sep 27, 2011 at 11:57 AM, Arthur Edelstein
arthuredelst...@gmail.com 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,
I'm with Phil on that one. Legacy support slows or even hinders innovation.
On Sep 28, 2011 6:06 AM, Phil Hagelberg p...@hagelb.org wrote:
On Tue, Sep 27, 2011 at 11:57 AM, Arthur Edelstein
arthuredelst...@gmail.com wrote:
So my request for Clojure's future development, is that backwards
On Tue, Sep 27, 2011 at 11:57 AM, Arthur Edelstein
arthuredelst...@gmail.com 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
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 this
On Tue, Sep 27, 2011 at 4:28 PM, Brian Marick mar...@exampler.com 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
On Tue, Sep 27, 2011 at 4:43 PM, Sean Corfield seancorfi...@gmail.com 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
On Sep 27, 4:43 pm, Sean Corfield seancorfi...@gmail.com wrote:
On Tue, Sep 27, 2011 at 4:28 PM, Brian Marick mar...@exampler.com 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
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,
Clojars
On Tue, Sep 27, 2011 at 7:33 PM, Arthur Edelstein
arthuredelst...@gmail.com 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
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 library
On Wed, Sep 28, 2011 at 12:03 AM, Arthur Edelstein
arthuredelst...@gmail.com 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
38 matches
Mail list logo
