Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Handy dandy CPAN pollution

by Juerd (Abbot)
on Dec 26, 2002 at 01:29 UTC ( [id://222259]=perlmeditation: print w/replies, xml ) Need Help??

It's Christmas. We're supposed to be nice to eachother now. Warning: this is not a nice post. If you want a happy Christmas, read it later :)

Every day I check http://search.cpan.org/recent to check if my favourite modules have newer versions, and to find out about interesting new ones. I forgot to check yesterday, but a module named Handy::Dandy was released just that day. I clicked the link to find out exactly how handy this module is.

FLAME ON

Well, it was rather disappointing. No, I didn't contact the author first. If you release something on CPAN, you should communicate beforehand. I seriously doubt Tommy Butler did.

I must admit that I didn't test or even let perl interpret the code. That's because I'm not installing this one; I don't want code like this on my system. Sorry, mister Butler.

Naming

The author introduced a new root namespace: Handy::. This is a big mistake. All modules are supposed to be handy, so why announce that your module is handy? Clearly he doesn't understand CPAN. Exactly the same mistake was made with Dandy. Especially since this module is not handy, and not dandy.

Version numbering

Version numbers are important for many things. The distribution is version 1.306.2, but the actual $VERSION is 1.30_6. The $VERSION did not change since the previous release.

Changes

I always like to know what has changed since the previous release. But this Changes file only lists the initial version. Too bad.

Object orientation

Well, that's what the author seems to think. He used OOorNo, which he also wrote himself. A useless module that gives you your arguments without the first one if that's a class or object. This has nothing to do with object orientation, it's just some very strange and useless syntactic sugar: you can now use Package->function and $object->funtion instead of Package::function. Yay?

Documentation

Yeah, good question. Where is it? There is some pod in the module, but it tells you nothing more than the code does. It lists @ISA, @EXPORT, @EXPORT_OK, %EXPORT_TAGS and the available functions ("methods"). The functions are not documented. There's not even a hint about what arguments they expect. Or about what they return. If you want to use any of these "simple, reusable code routines", you will have to read the module's source.

So I did. It's horrifying. I'm more or less documenting the module now.

use_once

This function does nothing. Maybe it should have been called use_not. An empty block. What's the use?

isnum

This is shorthand for the combination of the next two functions. It passes @_ entirely (explicitly), but since isint and isfloat need a single argument, this one does too.

isint

This function takes one argument, and returns that argument if it matches ^\d*\z, undef if not (or not defined). This means a false value is being returned if you give it 0. I thought 0 was an integer.

I think the regex I used was too simple or something. Mister Butler tries to impress the reader with a nice tr, but he doesn't understand how it works.

$check !~ tr/0123456789/0123456789/cd ? $check : undef
As you can see, there's a double negation: !~ and /c. Useless obfuscation. And /d is being used to delete found but unreplaced characters. But since the explicitly written 0-9 is repeated in the RHS, nothing actually is deleted. Not that any deletion is needed: the variable is thrown away.

There's 5 lines of explanation comments about why underscore is not handled at all. Nothing is said about periods. I can live with 3.0 being an integer and it being not an integer, as long as the reason is documented.

There are some regexes in perlfaq4 to handle this kind of stuff, but I guess Tommy Butler never read the perlfaqs.

I'd probably use a simple int $foo == $foo.

isfloat

The first argument is used, all others are discarded. The function returns undef when it thinks the value you give it is not a floating point number, or the number itself when it thinks it is. This function too is loaded with tr vagueness.

If the stringified version of the value to check does not contain a dot, it's not a float. This means isfloat(1.0) returns undef, while isfloat("1.0") returns 1.0.

Any string ending in a dot, or having more than one dot is not a float. This means 1. is neither an integer nor a float, according this module. That also means it's not a number. Perl can handle this format, though.

Again, perlfaq4 has a much better solution.

Oh, I almost forgot to mention that because isint returns the number for integers, and because isnum uses a truth check for what isint returns, and because isfloat rejects strings without a period, this module doesn't regard zero as a valid number.

html_escape

(I'm disregarding unicode here.)

The author chose to split the string passed it into separate characters, and then iterate over that array to implement s/([\x21-\x2F\x3A-\x64\x91-\x60\x7B-\xFF])/'&#' . ord($1) . ';'/ge;.

That's right: non-printing characters are left alone. Note that of the 33 ASCII characters that this function substitutes for entities, only four actually need to be: &, <, > and ".

&# is written as \046\043, ; is written as \073. I guess this is just to impress people, to show off his l33tness.

HTML::Entities is a much better module for this, even though something as simple as s/([^\x20-\x7E])/'&#' . ord($1) . ';'/ge works fine.

isin

A temporary hash is used to see if the first argument is equivalent to any of the other arguments. The hash values are equal to the keys, what a waste of space. Besides, the entire list is copied a few times. All of this just to be able to write isin($foo, @bar) where grep $_ eq $foo, @bar would probably have sufficed.

If the first argument is false, this function returns undef. This means you cannot check if the list contains undef, an empty string or zero (string or number).

String comparison is used, because hash keys can only be strings. isin(5.0, @foo) will find 5 in @foo, but not 5.0. There's no way to get this function to use numeric comparison.

convert_size

This is used as convert_size($foo, 'bytes to megabytes'). It only supports bytes (/^by/), kilobytes (/^ki/) and megabytes (/^meg/), and cannot handle extra whitespace. The second word of the second argument is ignored.

This function made me extremely sad. Dear Tommy, a kilobyte is not 1000 bytes, it is 2**10 == 1024 bytes. A megabyte is not 1000000 bytes, it is 1024 * 1024 == 1048576 bytes. All computer users, but especially coders should know this!

utf8

I'm skipping this, because I know nothing about utf8. I assume the function is broken, but lack clue to prove it. Update - It has nothing to do with utf8. At all. This function is just a miserable attempt to re-implement what URI::Escape does best.

html_encode

This does what html_escape does, but with all characters. This function too splits, iterates and joins where a very simple regex would also have functioned (and have been much faster).

So...

Do not use this module.

To Tommy Butler

You are a fool, but you probably realised that by now. You put your broken code on CPAN, violating lots of written and unwritten rules.

Please remove your broken modules from CPAN immediately. People must not use this, as it will very probably break their programs, giving them a bad impression of Perl.

Please learn some Perl before uploading another module to CPAN. Make sure you understand what you write completely. If you do not understand something, ask for help. The Perl community is a friendly and helpful one (although this review is not at all nice). When you know Perl, you probably would not even think about creating a module like this.

Read what the CPAN guides say about communication. Post your module somewhere and request comments.

To PerlMonks readers

Downvote me if you want to. I see no reason to be nice to this author. He polluted CPAN, and didn't read perlfaqs, didn't read http://pause.perl.org/pause/query?ACTION=pause_04about. People like Butler give Perl and CPAN a very bad name.

If you're learning Perl, a good exercise is to read http://search.cpan.org/src/TOMMY/Handy-Dandy-1.306.2/Dandy.pm and find out where the bugs are. There are plenty and I expect even beginners to be able to find some.

Sorry if this ruined your Christmas.

Flame off.

Replies are listed 'Best First'.
Re: Handy dandy CPAN pollution
by boo_radley (Parson) on Dec 26, 2002 at 03:06 UTC
    • Observation on documentation gripes: you probably have a lot of work to do.
    • The entire body of Mr. Butler's work appears to be 3 days old (as of today, 25DEC2002); perhaps he's following the mantra of release early, release often? If this is the case, I'd take issue with a potential beta release being number 1.anything, but perhaps you're seeing a rough draft of what's to come.
    • It would have been nicer to see you review a module you found useful.
    • Will you be sending your list of complaints to him?

      Nice to see a constructive reply :)

      One more I'd add to the list is the module is free, Juerd didn't pay anything for it, he doesn't have to use it if he doesn't want to. A slight "namespace pollution" really doesn't hurt anything.

        Being "free" doesn't cut it. Samoneala, Maleria and the common cold are all free, but we do our best to not perpetuate them.

        Utilising the storage and system management facilities of CPAN is not free, nor is the time spent a analysing each module before using it, or for those poor souls that make the mistake of utilising badly broken modules, the cost of the errors that result or the clean up that would be required.


        Examine what is said, not who speaks.

    A reply falls below the community's threshold of quality. You may see it by logging in.
•Re: Handy dandy CPAN pollution
by merlyn (Sage) on Dec 26, 2002 at 04:37 UTC

      Really, anyone who hasn't seen the glory/horror that is Meta needs to experience it at least once. And don't just gape at the 400+ files in the distribution; look at the source too, and witness such marvels such as this, this, and more!

        I saw this today also: Bundle::Schwern - a bundle of modules that Michael Schwern likes...

        Mike does a lot of great work for the Perl community but this is right along the same lines in terms of lacking description and direction... but then again, CPAN is quite non-judgemental and that has its good points.

        Carter's compass: I know I'm on the right track when by deleting something, I'm adding functionality

      Nice one.. though the following meme is pretty cute: #!/bin/echo This is a perl module and should not be run

      Makeshifts last the longest.

        Interesting. Takes advantage of a recent change to hash-bang. In the original hash-bang implementation, you'd see only "This {filename}", because hash-bang took only one argument, then put the filename after it.

        So there are definitely places where this hack will not work. Do not consider it portable to all places that support hash-bang, let alone those that don't!

        -- Randal L. Schwartz, Perl hacker
        Be sure to read my standard disclaimer if this is a reply.

Re: Handy dandy CPAN pollution
by princepawn (Parson) on Dec 26, 2002 at 02:10 UTC
    Every day I check http://search.cpan.org/recent to check if my favourite modules have newer versions,
    If you want to get your updates via email then subscribe here

    Carter's compass: I know I'm on the right track when by deleting something, I'm adding functionality

Re: Handy dandy CPAN pollution
by tachyon (Chancellor) on Dec 26, 2002 at 02:29 UTC

    The bit about the $VERSION not being changed interests me. It is stated on PAUSE that you can't upload a module with the same $VERSION number twice. If this has occurred you should let the PAUSE team know as it is a bug with their unwrapping code.

    cheers

    tachyon

    s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

      The bit about the $VERSION not being changed interests me. It is stated on PAUSE that you can't upload a module with the same $VERSION number twice. If this has occurred you should let the PAUSE team know as it is a bug with their unwrapping code.

      You can't upload a file with the same filename as any previous upload. If you don't update $VERSION, that means you can upload the same version twice, as long as the distribution filename is different.

      - Yes, I reinvent wheels.
      - Spam: Visit eurotraQ.
      

        You can't upload a file with the same filename as any previous upload.
        That's not a rule I've ever seen anywhere, nor is it enforced, nor practical.

        I upload a new index.html file about every two months. Always the same name.

        -- Randal L. Schwartz, Perl hacker
        Be sure to read my standard disclaimer if this is a reply.

        Ah, should have RTFM more closely. I would think that is not what you want though. $VERSION 0.01 should be fixed in time and place. If it needs updating that should be $VERSION != 0.01

        cheers

        tachyon

        s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

Re: Handy dandy CPAN pollution
by Tommy (Chaplain) on Dec 26, 2002 at 19:56 UTC
    
    >The author introduced a new root namespace: Handy::. This is a big
    >mistake.
    

    This isn't permanent. It is being changed, and rightly so. It was never meant to remain under that namespace. The bulk of the code present isn't going to remain in the module. The module isn't needed by File::Util anymore and won't remain among it's prerequisites -I just hadn't handled that yet. Further, the module isn't to remain on the CPAN when File::Util is updated (very soon) so that it doesn't use Handy::Dandy.

    
    >He used OOorNo, which he also wrote himself. A useless module that gives you
    >your arguments without the first one if that's a class or object.
    

    Refer to CGI::self_or_default( )
    How useful you find this routine is a matter of situational basis and opinion.

    
    >This has nothing to do with object orientation,
    

    That depends. It is named OOorNo is it not? This code is not to remain under it's current namespace either, and the module removed from CPAN.

    
    >it's just some very strange and useless syntactic sugar: you can now use
    >Package->function and $object->funtion instead of Package::function. Yay?
    
    
    use Foo qw( bar baz );
    
    Foo->bar(woot);
    

    I don't think so.

    
    >Documentation
    >
    >Yeah, good question. Where is it?
    

    There's not much documentation since the module isn't going to stay there more than the few days it would be present to provide needed support for File::Util. I don't want to argue about whether this practice of code provision and retraction is correct. It's not. It won't happen again by me. I appologize.

    
    >I see no reason to be nice to this author.  He polluted CPAN
    

    I'm sorry. I'll clean up my mess.

    
    >and didn't read perlfaqs, didn't read
    >http://pause.perl.org/pause/query?ACTION=pause_04about
    

    That's presumptuous.

    "When you're done with all your preparations, considerations, and investigations, visit the PAUSE and fill in the form for a new module namespace. Take your time filling in the rationale of the module proposal. Consider, your form will be posted to modules@perl.org too, so other developers will probably stumble over this description many years later. The better the decription, the better the chances that your module will actually be used."
    "You need not wait for approval. You can upload anytime, even before you fill in the form. Uploading and registering are only loosely coupled." -taken from http://pause.perl.org/pause/query?ACTION=pause_04about.

    I don't know all the "unwritten" rules I guess. I'll keep my ears perked up and my eyes open for these.

      I don't know all the "unwritten" rules I guess.

      Several are actually in the PAUSE documentation you quoted:

      • Consult other people about your module before you upload.
      • Avoid cutesy names.
      • Add to existing modules instead of writing your own.
      • Check $VERSION.

      As well, it's always handy to read perlmodlib.

      Hi TOMMY rough day eh? ;-)

      Personally I think Juerd is pretty on the ball with his comments. He expressed them in a pretty hard way but... *shrug* (btw, ive been on the receiving end of his comments before. youll survive ;-)

      Im mostly writing about this OOorNo module. Id like to see you explain what your intentions are with this module. Ive reviewed the implementation, and CGI->self_or_default() that you mention but I still dont grok the purpose of this module, and I in fact think that its broken and dangerous. (A feeling that is compounded as I dont understand its intended use as the documentation is skimpy to say the least.)

      It seems to be intended to be used for subs that are either called as methods or as subs. Problem is that the approach is particularly crude. Notice that the routines for this purpose in CGI bend over backwards to make sure the first argument is the right type before it overlooks it. Your code makes no such effort. If the first argument is an object, _irrelevent_ of its type, then it is ignored. So for instance if I used OOorNo as the basis for a CGI style tag generation routines i would have problems if I used blessed hashes for the tag attributes.

      Some other holes are things like:

      return(undef) unless ($mamma && ref($mamma) eq 'ARRAY');
      This is _horrible_. If I provide a blessed array your code breaks.

      To me both of these modules remind me of some of my own earliest Perl efforts. The thing is that most of it can be done by using other modules in better and more robust ways. I know the temptation of writing your own utility modules. You know exactly what and why the routines do everything that they do. And for your own limited use then that may be ok. But for public use you need to make sure your code is much more robust and much better documented.

      Persoanlly i think you would make far better use of your time by reading the modules on CPAN, and not writing modules to go up there. After all, most of the code in these two modules is either in a perlfaq in a more robust form or in a module in a more robust form, or not done at all for very good reasons. (Personally I think that Lincoln Stein, as wonderful as he is should _never_ have written self_or_default or self_or_CGI. The code in these two routines _barely_ works, and should not be copied. For instance what happens if I pass an object of type CGIOPTIONS as the first arg to a sub that uses this routine? OVID one time wrote an analysis of all the rules that Lincoln broke in CGI. Suffice it to say that generally speaking this module is not one to copy.

      Good luck, hang out read the many many nodes about the things that you are obviously interested in, bounce ideas off the monks, and refrain from CPAN'ing until you have a crowd of people here saying "I wanna get me some o dat!"

      :-)

      --- demerphq
      my friends call me, usually because I'm late....

        "This is _horrible_. If I provide a blessed array your code breaks."

        Thanks, I can't believe I didn't see that. I should have used
        UNIVERSAL::isa( )
        It's strange that I posted something to CPLM a little while back that talked about this. Merlyn chimed in too, explaining why using this technique rather than using CORE::ref( ) was the scalable, portable, correct WTDI. (tmtowtdi).

        I've poured over CGI myself. Basically, that module is a horrible mess. That's ok for someone who wants to use it, as it's not only one of the few messes that work, but one of the even fewer than work well in practice. It's very robust at what it's supposed to do, ie providing all the information a CGI script needs about its surroundings. But internally it's such a thorough mudball that I'm trying to switch to CGI::Simple wherever I have the opportunity (especially as I never use the HTML generator functions of CGI.pm). Ideally, it would get as much use as CGI and we could just as (more, even) confidently recommend it to people who write CGI scripts than we do for CGI today.

        Makeshifts last the longest.

        demerphq said,

        Personally I think that Lincoln Stein, as wonderful as he is should _never_ have written self_or_default or self_or_CGI. The code in these two routines _barely_ works, and should not be copied.

        My personal opinion of CGI.pm is that it is great! I couldn't care less if Lincoln made things harder for people to inherit from his module, because it offers a good deal of original ideas. I like the idea of allowing both OO and non-OO, especially when updating a module to a more object orriented architecture. You then allow for an object which can hold its own options, or an a module global variable, which must be parsed before another one. It allows me to do this:
        # Set variables for the next group of operations. MyMod->opt(1 => 1, 2 => 1); for ( 1..10 ) { MyMod->set( $_ ); MyMod->do_op(); }
        or set options for each object if the object require differant options. Just document the inflexibility of the code, and that people shouldn't try to emulate the code unless they know what they're doing and I think it's pretty fair.
          A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Handy dandy CPAN pollution
by John M. Dlugosz (Monsignor) on Dec 26, 2002 at 04:14 UTC
    I'm sure there's a lot of junk, and perhaps we need a peer-review value as well as the existing categories for alhpa/beta/release and whatnot. In this case, the fact that we can't tell what it does without reading the code means that nobody will use it for other than amusement purposes. I have a bigger issue with one that claims to do what I'm looking for but is really junk.

    As for the meaning of kilo and mega, actually he's right, and our usage within the computer industry is a non-standard appropreation of those prefixes, and it bugs scientists in other disciplines. See Prefixes for Binary Multiples. Unless manufacturers start using it on product packaging, nobody knows what I mean by "Ki" or "Mi", so I like to write a subscript 2 instead, K2, which means "base 2" and is more obvious.

    —John

Re: Handy dandy CPAN pollution
by shotgunefx (Parson) on Dec 26, 2002 at 23:27 UTC
    I'm not disagreeing with your assessment of the module, but I think your approach could have been more tactful to say the least.

    You've written an extremely harsh and personally aimed review of his work (and intelligence), posted it at a community he is not part of, and invited him to be mocked. Real f**cking nice.

    You could have accomplished the same goals without making the author feel like a d**k.

    • You could have written the author with the critiques and given him a chance to respond or patch. I'm sure most active CPAN authors would respond. While the are obvious huge problems in execution, the author was trying to make a contribution to the community and you single him out and attack him. What good is that? Perhaps he just won't contribute anymore. Maybe that's a good thing, maybe it's not. I think not. Perhaps this code is just a reflection of his stage of learning Perl. Let's say a year from now he is a much better programmer with something of value to contribute to the community, will he? Will others?
    • You could have written this as a review and just posted it here. That would have accomplished the same thing, just without the personal attacks ("You are a fool, but you probably realised that by now. ","but I guess Tommy Butler never read the perlfaqs") .
    So what did your personal attack accomplish that the preceding two items wouldn't have? You made the author feel like an ass and less likely to contribute to the community. That's the only difference.

    You remind me of Mr Garrison on South Park. "Remember, there are no stupids question, just stupid people." This type of personal attack, to me, runs against the grain of "the community" as I know it and is probably as harmful to the community in the long run as fubar modules.

    -Lee

    "To be civilized is to deny one's nature."
    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Handy dandy CPAN pollution
by dws (Chancellor) on Dec 27, 2002 at 05:02 UTC
    Let's get this straight. You find a module on CPAN that probably shouldn't be there, you flame the author publicly in a forum he doesn't hang out in, call him names, accuse him of incompetence, say that you "see no reason to be nice" to him, but then also invite him to ask for help, saying "The Perl community is a friendly and helpful one".

    Do you not see that there's something terribly incongruent here?

    If you want to do outreach, do outreach. If you want to flame, flame. But don't do them together. They are not an effective combination, even if you're only tacking on a bit of outreach to soften the flame. You'll make more friends with outreach.

    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Handy dandy CPAN pollution
by Tommy (Chaplain) on Dec 26, 2002 at 07:33 UTC
    I think I'm going to Hell because of this. I'll consider responding after I get some Zzz.

    "You can't hurt Christmas..." - Lou Who

      The introduction you got to PerlMonks wasn't exactly a gentle one, so personally I'd like to congratulate you on joining it nevertheless. Many wouldn't want to have anything to do with it after an incident like this so courage and integrity was needed on your part.

      PerlMonks is a nice and useful community with a lot of very devoted members. Juerd is one of them but you'll meet many others. Each has his own style of communicating and that's something we all have to expect and (to a certain extent at least ;-) accept.

      I hope you'll have a lot of opportunities to learn as well as to teach, since IMHO each of us, whatever level we've reached in the PerlMonks hierarchy still has a lot to learn (not necessarily just about Perl). In that sense we're all just initiates whatever the number of XPs we've obtained over time.

      So I'd like to welcome you to the monastry and I hope to see a lot of interesting contributions from you. Fixing Handy::Dandy might be a good start ;-p

      Two more things to add:

      1. I'm speaking only for myself, not in anyone else's name.
      2. I strongly believe that people are more important than Perl or CPAN.

      Just my 2 cents, -gjb-

      I think I'm going to Hell because of this.

      No, you're not.

      However, there is a lot to be improved. And I think you really should improve before putting anything else on CPAN.

      Welcome to the community, I hope you learn a lot. Sorry for the flaming introduction.

      - Yes, I reinvent wheels.
      - Spam: Visit eurotraQ.
      

    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Handy dandy CPAN pollution
by PodMaster (Abbot) on Dec 26, 2002 at 12:08 UTC
    I'm just writing to say nice job, I wish more people would seriously review the stuff that gets released on CPAN.

    I have personally written some bad code(File::DumbLock, fairly recent too), and was flamed for it over at DON'T USE THIS CODE, so I just wanna reassure TOMMY he'll live ;)

    I have always maintained any/and all code I write and release should be scrutinized, like all the code that gets released on CPAN should be, but sadly lots and lots and lots of code that gets released clearly does not.


    MJD says you can't just make shit up and expect the computer to know what you mean, retardo!
    ** The Third rule of perl club is a statement of fact: pod is sexy.

      I have personally written some bad code(File::DumbLock),

      At least that is not on CPAN. And you posted it on a public forum and realised the importance of a good name.

      - Yes, I reinvent wheels.
      - Spam: Visit eurotraQ.
      

Re: Handy dandy CPAN pollution
by sauoq (Abbot) on Dec 26, 2002 at 19:23 UTC

    Juerd,

    I upvoted almost every node of yours in this thread including the original post. Reviews of modules uploaded to CPAN are useful. They are helpful when the module in question is a good one and they should be considered necessary when the module is a bad one.

    You provided an educated and thorough review of Handy::Dandy as a service to the community and I, for one, am grateful.

    Frankly, I don't feel that there was anything out of line about your tone throughout the majority of your review, however, I do disagree with you on one point. You said of yourself in some node in this thread that you couldn't read this module's code and stay friendly. I believe you could have. The only part of your review which seemed to be an unnecessary judgement of the coder rather than an experienced judgement of the code was when you called the author a "fool." Had you avoided that one simple insult and not warned us that you were going to be flaming, your review would have been nothing more than a well-deserved "thumbs down" from a capable critic.

    My suggestion for the next time you review a poorly written module would be to wait half an hour or so and then go back and remove personal insults and apologies for being negative before clicking submit. In short, don't get personal about it and don't work on the assumption that others will.

    -sauoq
    "My two cents aren't worth a dime.";
    
Re: Handy dandy CPAN pollution
by Juerd (Abbot) on Dec 26, 2002 at 10:52 UTC

    There are some "the module is free, you have no right to complain" replies. I disagree.

    TOMMY wrote several modules. But while in principle this is laudable, many things are wrong with them. If nobody complains, problems are never fixed, people use his code, things break and Perl gets blamed for it.

    I did complain. In a harsh way, but I felt like doing that when I read Handy::Dandy's source. I love Perl, and can't stand it when someone damages its reputation. (You could argue I'm not really giving the Perl *community* a good name here. I hope my other posts compensate for that.)

    Via the chatterbox, I got some private messages saying that Tommy probably meant well. He probably did, but he should have communicated, to give the community a chance to respond before bad things would happen. He did not. We can only react *after* the incident. And post-facto response is never as friendly.

    Had no one said anything, then Tommy would probably not even realise his mistakes and submit more broken modules to CPAN. People *will* use his code as long as it is available (see also the infamous scripts by Matt Wright), so it should be taken offline before it causes real damage (if not already).

    My way of talking about this module may not be how you would have.

    Would you have reviewed this differently? It's not too late to do so. Let's see if you can stay friendly while reading this module's code. I couldn't, sorry. I hope you can.

    - Yes, I reinvent wheels.
    - Spam: Visit eurotraQ.
    

      > the module is free, you have no right to complain

      I too would disagree with that. Totally and without reserve.

      > If nobody complains, problems are never fixed, people use his code, things break and Perl gets blamed for it.

      Ahh been there too. Though I have Matts Script Formmail to blame for that. And no, I didn't install it.

      > My way of talking about this module may not be how you would have.

      I'm afraid I would have to agree totally with that. I wasn't going to reply to you as I thought the others had done so (both for and against) quite well. If nothing else, the strength of your initial review was enough to bring out quite an interesting debate on a few different topics. Well, more like drawing lines in the sand but you get what I mean.

      The question I have is would you have reviewed this differently if it had not been on CPAN but had been posted here first? Would you have done differently if in a work context and the code was being used for some tool or other such app?

      You were clearly quite angered and frustrated by the chance of more bad code proliferating around the net and this shows (which is fair enough). I do, however, have to ask how you would try to turn situations like these around?

      How would you try to nip it in the bud? I don't have the answer (I wish I did) but as you have such a strong opinion on this I was hoping you would at least subject it to some thought. Maybe even post a meditation on the matter.

      Sadly we can't use NMS for everything :P

        The question I have is would you have reviewed this differently if it had not been on CPAN but had been posted here first?

        I certainly would have.

        - Yes, I reinvent wheels.
        - Spam: Visit eurotraQ.
        

Re: Handy dandy CPAN pollution
by BrowserUk (Patriarch) on Dec 26, 2002 at 11:23 UTC

    Maybe it's time to implement a PM style voting system on CPAN. If a particular module falls below a certain negative value for appreciation, it falls into oblivion?

    Or perhaps a (moderated) mechanism for attaching reviews.

    It's not just the obviously flawed modules that could benefit. Some of the oft-recommended modules I've pulled down contain some dubious elements.


    Examine what is said, not who speaks.

      Maybe it's time to implement a PM style voting system on CPAN. If a particular module falls below a certain negative value for appreciation, it falls into oblivion?

      I don't like this idea. It is just too capricious for the treatment of serious work.

      Or perhaps a (moderated) mechanism for attaching reviews.

      This has more appeal.

      Perhaps a few lists created by the exalted placed prominently on CPAN. This is suggesting a cabal or dictatorial editorial board that places what they wish in this review.

      First a list of the well used modules: modules that by being in long and wide use prove some level of usefulness . DBI, CGI, and a couple of the Test::* modules would certainly be on this list. For those in the know this would be relatively easy to create.

      Second a list of reviewed code deemed to be good. Naturally some CPAN core would extend trust to others' reviews as they see fit. I would expect that if I submitted a review, it would not be seen as publishable unless the subject inspired one of the exalted to vet my work.

      Third a list of new items that seem to be heading for the first list.

      These things would be real nice on CPAN, would be nice on PM.

      For those who'd like to see this kind of stuff, there is the thread Essential Perl Modules

        Whilst I agree that simple anonymous voting would be to capricious, I think getting a list of the great and the good whom would be charged with the responsibility of reviewing modules could be equally so. Not to mention that the people on that list would most likely be too busy to devote time to such endevours.

        Perhaps a mechanism whereby anyone could attach their experiences of a module to that module, with a consideration mechanism to exclude obvious trolling and an anonymous voting mechanism on reviews posted that would provide peer review of the reviews, with obviously discordant ones (large negatives) disappearing.

        Now it starts to look complicated. I guess it's likely to remain "Caveat downloader" for the forceable future.

        It seems a shame that there isn't a simple way by which the seeker of the module can gain from the experiences of those that have gone before in their attempts to choose any given module or type of module.

        Examine what is said, not who speaks.

Re: Handy dandy CPAN pollution
by SpaceAce (Beadle) on Dec 27, 2002 at 08:35 UTC
    This is the first time I have ever been really disappointed with a post on Perlmonks.

    This post is the most useless kind of flaming and invective. You "see no reason to be nice to this author". How about because he's human? He has done nothing to you. Your life is not inextricably linked with the quality of CPAN modules. He wrote some code and shared it. You don't like it. It's buggy and broken. So what? No one is asking you to use it.

    You could easily say "This code is broken, here's why" and written the same article without the childish namecalling and superior attitude. You even went so far as to call this person a "fool". I suppose that your code contains no imperfections. You've never written a buggy or broken function and God knows, you've certainly never released any code that wasn't 100% bug-free and useful in all ways to all people.

    Even if his code is an "F-", what is the point of this post? To show us that you know what is good for everyone? Are you the CPAN police force?

    You don't want good code, you just want to flame. You told us you didn't contact the author. Your reasoning: "If you're going to release something on CPAN, you should communicate beforehand". I wasn't aware that submitting code to you for approval was one of the necessary steps to getting modules on CPAN. If you were truly concerned with the quality of CPAN code, you would have contacted the author. Instead, you insult and denigrate. Apparently this person isn't worthy of common courtesy or respect, but he IS worthy of a multi-page flame on a forum he very likely does not visit and cannot defend himself in.

    Next time, why don't you try posting a useful and constructive critique? Show the author (and us) where he went wrong and how to fix it. That can be done without all the schoolyard antics, you know. I don't know about the rest of the monks, but I come here to learn and share with people with whom have a common interest. If I wanted to see posts like this, I would spend my time on public message boards and newsgroups.

    SpaceAce
    s>>sp>;s>..|>\u$&ace>g;print;

Re: Handy dandy CPAN pollution
by gmpassos (Priest) on Dec 27, 2002 at 13:44 UTC
    What is your objective with this node?! Tell that Tommy doens't code very well?! Tell that you code better?! Or make CPAN better?!

    I'm saying that because we need to think about the consequences of what we do! I don't think that your node will make something better for Tommy, or any one! Is a good discussion, but I think that exist better ways! Why not use your time and energy saying to Tommy some tips about CPAN or coding, before flame it!

    Is obvious that you are a better programmer than Tommy, but every one, some day, was a child, a lammer!

    I think that the objective of PerlMonks is trade knowledge! And not to create a group that only say what is the better, the right, the wrong! We don't have this right man! And don't forget, the bases of Perl is the freedom!

    The only thing that you make is to discourage Tommy to make something for the others! Imagine if the Perl community in the begin works like you?! No one will spend time coding to listen peoples like you, and CPAN will doesn't exist!

    I don't blame you to chose this way, and Tommy to make something that doesn't work very well! Do you know why?! Because every body are humans, and humans make mistakes! But humans learn, very well, with mistakes! Learn with the mistakes of the life is what we call experience, don't forget this!

    Next time, when you see someone inferior in something that you are good! Don't be angry with what it doesn't know! It just need to learn yet! And help it to learn! Be a teacher, not a dictator!

    Graciliano M. P.
    "The creativity is the expression of the liberty".

Re: Handy dandy CPAN pollution
by suburbanantihero (Initiate) on Dec 28, 2002 at 01:42 UTC
    I don't disagree with your observations of the module being buggy. You posted your review of it both here and to CPAN's bug tracker, great.

    It is possible to offer constructive helpful criticism without being so inflammatory. Instead of helping to facilitate progress, your comments will more likely cause separation and conflict.

    Perhaps he wrote a buggy module. Perhaps it works great on his system in the circumstances in which he uses it.

    Perhaps his code is not as efficient as you could write it, but the beauty of Perl has always been that there is more than one way to do it. If you want to help the advancement of Perl and CPAN, offer him constructive examples of how something may be written more efficiently.

    Where the name is concerned: open source project have all kinds of screwy names. How about Perl, Apache, PHP Nuke, Jakarta, Tomcat and Ant. Heck, just look on freshmeat.net any given day for bizarre names.

    It is up to the PAUSE moderators to approve or disapprove name spaces. When I first submitted the module registration DBIx::Loop, Tim Bunce kicked me right and left until we ended up with DBIx::FetchLoop.

    In the comments here, you were quite full of righteousness over the level you've reached here. Pride is not constructive and it will not benefit you in the long run. I implore you to stop and think about the best possible solution for an issue and figure out how to reach it without causing conflict.

      If you want to help the advancement of Perl and CPAN, offer him constructive examples of how something may be written more efficiently.

      I did. By pointing to other, much better modules, and by rewriting his code as regexes that are much more efficient than the original code. Doesn't matter much, though. This module simply does not belong on CPAN.

      Where the name is concerned: open source project have all kinds of screwy names.

      Bizarre names are good. Bizarre namespaces in Perl modules are not (even HandyDandy would have been better than Handy::Dandy.)

      It is up to the PAUSE moderators to approve or disapprove name spaces.

      PAUSE apparently is not moderated. I have yet to see any sign of that. I'd like strict moderation of CPAN, and I'd like to see my modules in the (still manually maintained) module list, but anyone can upload anything, and module registrations seem to be ignored.

      In the comments here, you were quite full of righteousness over the level you've reached here.

      Excuse me? The level I have reached on PerlMonks has no meaning at all, anyone can be a saint. That I released a few modules to CPAN also means nothing, anyone can upload modules (as once again made clear). Where do you see me being proud? I'm only proud to not have put my Handy::Dandy-like modules on CPAN. (Yes, of course I wrote code like that too when I began learning Perl. But I never had the guts to release it. That's a good thing, I know now.)

      I implore you to stop and think about the best possible solution for an issue and figure out how to reach it without causing conflict.

      I already thought about solutions, and asked TOMMY to remove the module from CPAN. It is the best (and in my opinion only) solution to the problem that is Handy::Dandy. I'm not trying to cause any conflict, but it appears the word 'fool' does have that impact.

      - Yes, I reinvent wheels.
      - Spam: Visit eurotraQ.
      

        I already thought about solutions

        Well, here's your chance to apply them. I assume you'll be more than willing to help him fix it right? You wouldn't just blast someone and then walk away when they request assistance, would you?

        I'm not trying to cause any conflict,

        Read your root post again. If that's not trying to cause conflict (a very bad kind of conflict IMHO) I don't know what is.

        anyone can be a saint.

        Yes, I think you've proven that.

        I'd like strict moderation of CPAN,

        Who's going to do that? How will disputes be resolved? What gives one person the right to prevent another from sharing their code in an open forum like CPAN? If people can't be bothered to do QA on a module before using it, they deserve the consequences.

        I don't buy the "Gives perl a bad name" argument either. What's next? Trying to prevent them from using established protocols to distribute their code?

Re: Handy dandy CPAN pollution
by Mr_Person (Hermit) on Dec 27, 2002 at 15:41 UTC
    Well, actually Megabytes really are 1000000 bytes. According to NIST, it's Mebibytes that are 2^20. Although I also prefer Megabytes meaning 2^20, it looks like NIST disagrees and that's the standard so we'll have to live with it. :-)
      Maybe for you but my old digital electronics lecturer hammered into us that it was 1024*1024 (as in a million is 1000*1000 by similar means).

      He even put a trick question on it in our exam :). Its a shame this was before 1998 when this new standard came out. I too initially believed it to be wrong :). To quote the referenced page:
      The result is that today "everybody" does not "know" what a megabyte i +s.
      That makes me laugh so much :P. However, I think the arguments for it are valid (read the bottom half of the page) so I guess I'll have to shift my opinions somewhat.

      Sorry for the off topic reply but I thought it might be a nice distraction on an otherwise ugly node.
Re: Handy dandy CPAN pollution
by Juerd (Abbot) on Dec 27, 2002 at 19:48 UTC

    Argh. There are a lot of replies asking why I wrote the post. I did explain already, but here I will again. (Not that it helps, 'cause most of you reply immediately after reading the root node, and don't read the replies until you have responded yourselves)

    I want awareness. I want to tell this module is bad and should not be used. I want to explain why it is.

    I want TOMMY to know he did something wrong. I want to let all of you know that I consider modules like Handy::Dandy abuse.

    As for why I'm so harsh, and why I insult people: you should read the guidelines and discuss *before* putting code on CPAN (I must admit I haven't always discussed: Crypt::Caesar was put online without any premeditation). You should think about what name space you use. And code you upload should work (bugs are inevitable, but code should be a whole lot better than Handy::Dandy to be put on CPAN). Anyone who puts broken code under wrong namespaces on CPAN without discussing it publicly first, is a fool. That is *my* opinion. You're not required to have the same opinion.

    I think TOMMY is a beginner. That's not the issue. I don't mind beginners. Actually, there should be many more. You cannot code at top level when you just learned Perl, I understand that. It took me four years to get at my current level, and couldn't have reached it without the help of this monastery (the past 12 months and 12 days).

    I do dislike beginners that upload their broken code to CPAN.
    TOMMY, if you want to share your code, please post it on this site. Here, we can review it easily, test it, and let you know what we think about it. If anyone says "hey, maybe this is CPAN material", only THEN consider uploading it to PAUSE.
    If you want to upload to CPAN, either because you want to let the world show how good you are, or because you really think your code could help other people, also post it on PerlMonks first. Ask for suggestions, ask if the module's package name is sane.


    I'm expecting a lot of downvotes again. I'm beginning to like this. Can we end this discussion before I turn into the troll some people think I am?
    A reply falls below the community's threshold of quality. You may see it by logging in.
A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://222259]
Approved by diotalevi
Front-paged by PodMaster
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chanting in the Monastery: (6)
As of 2024-03-28 20:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found