[plt-dev] a common collection for utility modules

IMHO this is a good idea that can encourage code refactoring and reuse, but
it should be done with the understanding that the experimental code will
still be supported and will "eventually" become production code, otherwise
it might not achieve the desired effect.

Cheers,
yc

On Fri, Nov 6, 2009 at 9:34 PM, Ryan Culpepper <ryanc at ccs.neu.edu> wrote:

> Eli Barzilay wrote:
>
>> On Nov  6, Carl Eastlund wrote:
>> [...]
>>
>>  I see, mostly, the reduction in stuff that needs to be tidied up and
>>> removed, because there are more eyes on this code, more people
>>> picking it up and using it, more people who might keep it in good
>>> shape.  Any that stays in bad shape, well, would have anyway.
>>>
>>
>> Why does it have to be this way?  This is like claiming that most of
>> the tree is closed source.  What's preventing you from going over
>> other people's code and fixing things?  Or pointing out things that
>> should be shared?  Or telling them that something is so useful that if
>> they just generalize that one bit and put it in a more general
>> library, you'll volunteer to document, write tests, and maintain it?
>> This lack of shared workload is something that exist now, and
>> `unstable' is just putting a new label on it.
>>
>>
>>  The fact of the matter is, we each currently treat our internal code
>>> as our personal code.  And this is not realistic.
>>>
>>
>> Yes -- fix that!  And it can be fixed regardless of a new toplevel
>> label and a new kind of a "not really organized collection of code"
>> tool.
>>
>
> The fact is, we tend not to interfere in other people's collections much.
> I've been talking about this phenomenon with various people around the
> Northeastern lab for years. After many discussions, I still don't have a
> good idea of how to fix it. So I'm attacking a related problem with a
> different approach.
>
> Rather than encouraging developers to wander around in other people's
> territory, I'm encouraging them to put more of their work into a common
> space. Why should you go hunting through my code for useful bits when I have
> a much better idea of what is generally useful and what is specific to my
> particular needs? And a collection is a very useful label to hang on the
> common space, one that interacts well with other needs such as
> documentation.
>
> (Infamous Ryan-Analogy: There are two ways to increase social interaction.
> Encourage people to barge into others' personal spaces, or encourage
> everyone to spend more time in public spaces. I'm going for the latter.)
>
> If you want to fix the other problem, go for it. But shouting "Be it so!"
> doesn't seem to work.
>
>
>
>  On Nov  6, Ryan Culpepper wrote:
>>
>>> Eli Barzilay wrote:
>>>
>>>> (Leaving beind an unstable library that I'm using, and nobody
>>>> owns.  A major point that I failed to make initially is that such
>>>> code should never, IMO, become permanent.)
>>>>
>>> If you're using an unstable library and nobody owns it... you own
>>> it.  Unless you can foist it off on someone else. If no one else
>>> owns it you can, of course, start assimilating the parts you want
>>> and junking the rest.
>>>
>>
>> See above.  What needs fixing is for people to start looking beyond
>> their collections -- regardless of a new collection.  (And you can
>> summarize my above concern as: if this is not fixed, then we haven't
>> done anything besides shuffle some code around -- so now people still
>> don't care, and the code is messier.)
>>
>
> Shuffling code around, when done carefully, is called *organizing*. I think
> people are more likely to care once the code becomes better organized.
>
> I'll volunteer to watch over the unstable collection to make sure it
> doesn't degenerate into long-term chaos. (I make no promises about
> short-term chaos.)
>
>
>
>  If no one depends on it and no one owns it or wants to, it can be
>>> junked immediately. And yes, we should periodically review the
>>> unstable collection and eliminate dead libraries. We should probably
>>> do the same for all collections, but there's a higher risk of
>>> breaking code in planet or in some other project when we do that.
>>>
>>
>> So why not do that??  Everyone's jumping up and down about adding new
>> stuff, but when it comes to improving existing code then we get these
>> "should probably"s.
>>
>
> Just because there's work to be done in maintaining existing collections
> doesn't mean that it isn't worth adding another one. The movement of code
> might even indirectly help the existing collections.
>
> Ryan
>
>
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20091106/7874833b/attachment.html>