|
Re: On collaboration between projects
by tirwhan (Abbot) on Feb 19, 2009 at 09:16 UTC
|
To paraphrase the leader of a well-known open source software project: "Software is evolution, not intelligent design". The existence of several similar solutions to the same problem is not necessarily bad, it allows for in-depth exploration of a problem-space and means that users can use a solution that's most to their liking. I know I've personally (for what I considered to be good reasons) chosen Template::Toolkit over HTML::Mason and vice versa for different projects. And just look how many attempts (some by very well-respected authors) there were to devise a better object system for Perl 5 until one finally emerged that seems to be best-fit for most people.
This is not to say that your goal of collaboration is not a laudable one! Of course the (free software|Perl)? world would be a better place if more people put their ego aside and tried to work together rather than being king of their own castle. I just wanted to point out that TIMTOWDI is a good thing in it's own right.
<pet rant>The one thing that does occasionally bug me about CPAN is the fact that module namespace is equivalent to functionality. Thus, if I'm the first person to think of writing Foo::Frobnicate I will always remain the author of the authoritative module on the subject. Even if the frobnicator incarnate later comes along to write his own (much better) module, he'll have to call it Foo::Frobnicate::Better or something equally stupid. I hope the Perl 6 people manage to better separate this (even though I haste to admit that I have absolutely no bloody idea what a "better" way could be).</pr>
| [reply]
[d/l] |
|
|
| [reply] |
|
|
This is rather abstract to discuss without a concrete example, but you need to have breadth and depth both, don't you? Having x modules all do the same task with different interfaces will shake out the "most preferred" over time or it will result in multiple interfaces existing to suit different types of people.
Again, collaboration is good, and for these modules to eventually use the same "engine" under the hood could be a good thing. Even though that model of development (create differing solutions and then try to cobble them together) appears to be ass-backwards and more work, it seems to work pretty well.
| [reply]
[d/l] |
|
|
| [reply] |
|
|
Which just serves to emphasise my point, it is a good thing that multiple solutions exist :-). From what I've seen, many people looking for a "more modern" Perl OO system seem to settle on Moose these days, and it seems to be getting to the stage where s/many/most/. But if you think there's a better alternative out there (out of interest, which would that be, btw?), then clearly it is a good thing that these alternatives exist.
| [reply]
[d/l] |
|
|
| [reply] |
|
|
Considering I've yet to encounter some non-CPAN code (that is, code that actually runs solving some companies problem instead of just having the potential of doing so) that actually uses Moose, I'm not quite convinced about the "best-fit for most people" part.
I am the author of Moose so obviously I will be biased, but we have about 7-8 major production systems at $work that use Moose extensively to solve real world problems for some very large companies. Best Practical (RT, SVK, etc) uses Moose/Mouse in there new SD project and some of the Hiveminder API modules. Shadowcat Systems (of Catalyst/DBIx::Class fame) has deployed systems using Moose. I know that Moose is being used at ValueClick, IMDB, Yahoo! and Symatec to name a few. In short, just cause you haven't encountered it does not mean that it is not out there, because in fact it is very much out there. This is not to say that it is the "best fit for most people", even I won't agree with that statement.
What I do know is that Moose will get out of fashion and will be replaced by another system.
s/Moose/$anything_technical/g
In case you haven't noticed we work in a very "fashion" driven industry, this is just how it works. If you asked yourself that question before making all your technology choices (and weighted it heavily) then you would still be writing code with assembler on wire wrapped boards.
| [reply]
[d/l] |
|
|
|
|
. <-- data point without Moose
Moose is used in the project at work (BBC).
And, I just came back from a London.pm tech meet where the topic of the talks was... Moose.
So statistically, Moose is used in 2/3 of all data points in this post. That should tell you something (what exactly is unclear though).
/J
| [reply] |
|
|
|
|
Re: On collaboration between projects
by Your Mother (Archbishop) on Feb 20, 2009 at 02:29 UTC
|
Like some alluded to above, I *like* competing packages. So I don't think too many projects should be mooshed together at all, but that wasn't your real point. This was-
So here is my idea, istead of trying to steer each other's project into our goals let's try to find some sub projects of common goals to collaborate on.
That's a really good idea and it's interesting to note that the jQuery kit just did exactly this. They broke out their selector engine as a separate piece--called sizzle--for any and all to use or improve.
Now finding ways to break out Perl projects the same way... That's a trick. I have felt that parts of Cat's engines, like HTTP::Body, should really be folded back into the HTTP::Request space. Hmmmmm....
| [reply] |
Re: On collaboration between projects
by sundialsvc4 (Abbot) on Feb 21, 2009 at 06:06 UTC
|
The presence of multiple solutions and approaches isn't competition. It is a good and necessary thing.
As much as we might dream of finding “it” and then perfecting it ... the target is constantly changing. Think about it: what's in your pocket? Is it still a world of web-pages? Not really... and for that matter, neither is the web. Only this process has a ghost of a chance (and a track-record ...) of keeping up.
| [reply] |
|
|
| [reply] |
