Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Re: Tried and True CPAN Modules

by lachoy (Parson)
on Jul 18, 2003 at 01:56 UTC ( #275476=note: print w/replies, xml ) Need Help??


in reply to Tried and True CPAN Modules

First: some folks are putting their money where their mouth is and providing a place to talk about CPAN modules. Gavin Estey recently created a wiki site for people to comment on CPAN modules. Check it out.

Second: it really does seem counterproductive to have so many modules, many of which duplicate one another. At least until you think about the CPAN and the community using it as a marketplace of ideas. Just like a normal marketplace there's lots of competition and seemingly little differentiation in areas where many people congregate (e.g., templating, web applications, accessing databases) and that have a fairly low barrier to entry. There's not as much competition in more esoteric problemspaces (largescale number crunching, biological analysis, etc.).

And just like a marketplace certain products win not just by being the best (however that's defined) but by attracting other people to support and discuss it by other means (good documentation, professional website, excellent support, charismatic leader, strong forum presence, etc.). Arbitrarily weeding modules out (even bad ones, which I bitched about recently) is unnecessary -- the bad ones will fall by the wayside, never updated and never discussed. It can be tough to distinguish these but time, and articles written by an expert (like Perrin) are IMO the best solutions.

Anyway, my point is that having all these modules and the interplay among them is the best way for the cream to rise to the top. Maybe in a year I'll get tired of supporting SPOPS and contribute to Class::DBI or Alzabo. Or maybe someone will pick up the ball. Or maybe something new will come along trumping us all. Who can predict the future? All I know is it's an awful lot of fun being in the marketplace, as chaotic and messy as it can be.

Chris
M-x auto-bs-mode

Replies are listed 'Best First'.
Re: Re: Tried and True CPAN Modules
by smalhotra (Scribe) on Jul 18, 2003 at 12:38 UTC
    I think Gavin Estrey's site is a GREAT idea. I was just going to suggest if we could have a central place where we could dicuss specific CPAN modules. Many of the larger projects have mailing lists and/or sourceforge projects.

    I author a smaller module (Finance::YahooProfile) that is used by at least 20 people that I know of. I feel too lazy to maintain a website, discussion board, and a mailing list for this. I would like it if there were an auto-generated sourceforge-like site for CPAN modules.

    For now, I like the CPAN wiki and will start using it extensively. Especially given the open-source nature of CPAN people other than the author will discover bugs or new ways to use the module. A wiki allows everyone to add to the documentation.

    $will->code for @food or $$;

      Better yet, a central place to WORK on *any* CPAN module. Imagine the wiki idea, but with code + comments rather than just comments. Imagine that you could click your way through the code for say, Date::Manip, cheerfully categorising algorithms (finite state machine here), doing tiny cleanups on code (doesn't handle corner case X), suggesting and branching new areas to work on larger refactorings, add tests to the test suite, and have that all linked into a system that automatically builds stable and beta branches, runs the test suites, and indicates their status, and permits CVS/Subversion checkouts of any given tree by ID or a gzip'd download of same for the purposes of testing on your local system.

      Imagine running into a bug in a CPAN module and not having to file a bug report, simply hopping onto the site and branching in a fix with a comment, and adding a test case.

      Imagine running a class for programming students, and being able to assign homework as walking through certain CPAN modules categorising algorithms or patterns.

      Imagine having 20 minutes without anything to do, hopping onto the site and refactoring a tiny mess in a single function in a random module into something clean and elegant.

      Imagine a site where sections of code have been voted especially clean, or especially messy and deserving of attention, so that rather than avoid using them or reimplementing from scratch, they can be bit-by-bit cleaned up and refactored.

      Imagine a site where common code across many modules is regularly identified and abstracted into a common module, slowly building up a pool of best-of-breed module support code created and reviewed by many, used in many modules. No more hackish reimplementations, just a slowly expanding core of solid code.

      Imagine contributing a module and watching it grow and stabilise every day as people from across the world spend a little bit of their time commenting and cleaning and refactoring.

      Wouldn't it be cool? :)

        You don't hail from Liverpool by any chance do you? :)

        On a more serious note, I think the concept you expressed here in somewhat utopian terms, is actually a pretty good vision of not just what would be nice in the future, but what will have to become reality in order for software development to make it's next (I could almost say first) tentative step to moving from a craft to a form of engineering.

        Imagine that your version control/development collaboration system didn't just detect and record changes to the files posted into it, but went a few steps further.

        • detected and recorded the changes.
        • automatically recompiled the affect parts of the project.
        • ran the affected parts of the unit, integration and regression suits. and produced statistics.
        • profiled the code and generated comparisons of raw performance, memory usage, etc,
        • performed a static analysis of the code looking for deprecated usage;
        • flagged dubious practices;
        • compared function and method signatures against previous versions loking for API changes;
        • looked for changes in assertions;
        • collated variable names and detected possible typos by flagging new variable names with low usage counts and/or a high degree of correlation with a similarly named existing variable ( @indexes .v. @indices ).
        • detected the possibility of out-of-synch comments by noting that the code for a function, method or block had changed but the associated comments hadn't.

        I don't think individually, any of these things are beyond the capabilities of existing programming techniques, languages or programmers. In fact I would go as far as to say that I think that I have seen most of the algorithms and coding techniques required to do this, be asked for and answered here at PM over the last year. The only grey area I see is that using perl to parse perl is notoriously difficult, but for other, simpler, more clearly defined languages, perl probably has the power required to do all of this now. The only things missing are the desire, agreement and funds and/or commitment.

        I don't suggest that the availability of such a system would suddenly and dramatically improve the productivity or precision of software development, but I do believe it could produce the metrics that would highlight both the need for improvements and the directions that need to be driven to achieve them.

        It's been my long held belief that the most significant factor holding back both software quality and productivity is the absence of meaningful metrics. When a mechanical engineer makes a change to the design of a component, he can pretty much just pick up a micrometer, a set of scales or put the component in a wind tunnel and get an instant measure of the effects of the change in some meaningful manner. It doesn't always tell the whole story. There have been several car designs over the years that measured really well on the scales of Cd (coefficient of drag) which translated into either better performance or better fuel economy, that where simply so ugly that the general public eshwed them.

        Given the performance of modern processors, the time a programmer spends barely utilising the power of their cpu whilst typing into an editor or just sitting starring at the screen waiting for inspiration, should be being used to generate some metrics about the effectiveness of what s/he doing. Not for the sake of managerial purposes like the old kloc/week type stuff, but to give the programmer feedback. Peer level code reviews can be very effective, but anyone who's worked in an environment that uses them will know that as often as not, they can end up becoming religious wars or simply ego-fests. Interminable discussions about the benefits or otherwise of one technique, style or practice over another, with both proponents and opponents basing their arguments upon scant information gleaned from one benchmark, error or bug fix, in one previous situation that may or may not be applicable to the current situtation. Even if the legendary "programmer's ego" problem can be dismissed, we all tend to base or opinions upon our experiences and we each have a different set of experiences, so our opinions differ. Without a set of realistic and relevant metrics to act as a deciding factor, it becomes a free for all of argument about who's set of experiences are the more relevant, who's debating skills are the greater, and finally, whos has the greater (managerial) seniority.

        Sorry to hijack your vision and bend into one of my windmills:)


        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller

        Cool, but utterly impossible.

        It is intrinsic to the nature of the programming task that you cannot do it without having a large number of things in your head at once. OK, there are programming-related tasks that can be done getting into the specifics less - otherwise sites like this could not happen. But estimates that I have seen is that about a third of the work of a professional programmer is work that you cannot begin to be productive at unless you have already had 15-20 minutes getting a good "mental flow" going.

        In other words the same principles that make interruptions such a productivity killer also make it impossible to produce useful software out of a million programmer's "wasted interrupt time".

        Book recommend: if you haven't read Peopleware, do.

        UPDATE: I think of this place as being somewhere you go to get the kind of advice you can give based on small pieces of code which zby commented on below. He might have a different vision though.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://275476]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (3)
As of 2022-05-17 18:40 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Do you prefer to work remotely?



    Results (68 votes). Check out past polls.

    Notices?