Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

The Core

by PhiRatE (Monk)
on Jul 19, 2003 at 13:45 UTC ( #275865=note: print w/replies, xml ) Need Help??

in reply to Re: Re: Tried and True CPAN Modules
in thread Tried and True CPAN Modules

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? :)

Replies are listed 'Best First'.
Re: The Core
by BrowserUk (Patriarch) on Jul 19, 2003 at 15:56 UTC

    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

Re: The Core
by tilly (Archbishop) on Jul 19, 2003 at 18:17 UTC
    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.

      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
      That's true - but it does not mean that you can't give advices based on small parts of the code. Those advices would be helpfull or not - the author would decide eventually if they fit into the whole picture, but they can lead him into new ways of thinking. This schema can work since the cost of reading an advice is not that big.

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (1)
As of 2023-06-04 21:48 GMT
Find Nodes?
    Voting Booth?
    How often do you go to conferences?

    Results (22 votes). Check out past polls.