Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Should I leave behind beautiful code or readable code?

by MaxKlokan (Monk)
on Mar 28, 2007 at 08:13 UTC ( #606931=perlmeditation: print w/ replies, xml ) Need Help??

Dear monks,

I wrote for my current client some code that looks like this:
sub MySub { ...some stuff... return map split(/ /,$_,2), map uc, @somearray; }
I like it a lot (I know, I could even leave out the "return"). However, in a few months I'll be off to new challenges and I will have to leave this code to be maintained by somebody else.
Should I let my pride prevail and leave the code as it is, our should I be merciful to the maintainer and refactor it to something more readable to the non-initiated?

Max

Comment on Should I leave behind beautiful code or readable code?
Download Code
Re: Should I leave behind beautiful code or readable code?
by parv (Priest) on Mar 28, 2007 at 08:42 UTC

    The return statement is perfectly understandable from my point of view. There is nothing tricky|useless thing there if, as presented, most often the result is assigned to an array (or, list variables). If the end result will be assigned to a hash, presence of a fat comma in the left most map may give a hint (to the "non-initiated").

    (A few minutes later: Let's try to find out the extent of my ability to write about the usage of fat comma as obliquely as possible.)

Re: Should I leave behind beautiful code or readable code?
by syphilis (Canon) on Mar 28, 2007 at 08:59 UTC
    Show no mercy !!
    Get rid of the "return", too :-)

    Cheers,
    Rob
Re: Should I leave behind beautiful code or readable code?
by jwkrahn (Monsignor) on Mar 28, 2007 at 09:02 UTC
    I have two questions that would concern me as a maintainer:

    1.   When you use split(/ /) are you saying that you know that the data will always be separated by exactly one space character or did you really mean to use split(/ +/) or split(/\s+/) or preferably split(' ') instead?

    2.   Why are you using map twice when you only need to use it once?   For example:

    return map split( / /, uc, 2 ), @somearray;

Re: Should I leave behind beautiful code or readable code?
by grinder (Bishop) on Mar 28, 2007 at 09:44 UTC

    I beg to differ, but I find that neither beautiful nor readable. At the expense of sounding like an old fart, I would privilege readability over beauty, which is, of course, in the eye of the beholder anyway.

    Especially for code you write for clients, I would shun dropping braces of maps (the speed optimisation is negligable) and implicit uses of $_. Spell it out:

    return map {split( ' ', uc($_), 2)} @somearray;

    This makes it pretty obvious that some sort of transform is being applied to @somearray, and that is what is being returned.

    I used to omit return until the day I tried to return an anonymous hash reference...

    • another intruder with the mooring in the heart of the Perl

      The very fact that you are using map says outright that some sort of transform is being applied to @somearray irregardless of how many parenetheses or braces you apply or whether $_ is explicitly used.

Re: Should I leave behind beautiful code or readable code?
by DrHyde (Prior) on Mar 28, 2007 at 10:01 UTC
    I downvoted this node. Even considering leaving behind code that you admit is hard to read is grossly unprofessional when you have the opportunity to fix it.

        So where does DrHyde say it was a dumb question? He simply pointed out that entertaining the idea of leaving some code of dubious merit when you could fix it anyway was grossly unprofessional. I tend to agree with that.

        At $work, I have to deal with crappy legacy code written by people who don't know any better, but if one has to ask the question in the first place then there's probably something wrong.

        • another intruder with the mooring in the heart of the Perl

Re: Should I leave behind beautiful code or readable code?
by ferreira (Chaplain) on Mar 28, 2007 at 10:57 UTC
    "Beauty is in the eye of the beholder." For those who live as professional programmers, beauty as a consuming passion that disappears in a few days and leave nothing but a sense of emptyness is not a top priority, I think. Beauty needs a more pragmatic approach, something that makes it more close to code that works and that can be changed without hair-pulling. It is not that fugacity that dazzles, it is more like that brightness that stands. In this case, pride should be on getting things permanent and not in such a way that gives other people headache.

    After all, maybe you should try something like this

    sub MySub { ...some stuff... return map { split(/ /,$_,2) } map { uc } @somearray; }
    Not that big deal, but more everlasting as a good memory.
Re: Should I leave behind beautiful code or readable code?
by BrowserUk (Pope) on Mar 28, 2007 at 11:25 UTC

    For counterpoint. One wonders how many of those who are advocating dumbing down this simple code, actually had any trouble understanding it? There is a common theme here where people tend to say: I understand it now, but a maintenance programmer (or you) 6 months from now may not. Even though they have just encountered the code for the first time and so are in exactly the same position as the mythical maintenance programmer will be in 6 months from now.

    With the exception of the possible abiguity of the use of / / as the parameter to split--which in the light of knowledge of the code, may not be ambiguous at all--anyone not immediately able to understand this code, should probably not be maintaining Perl code anyway.

    What is the point of using a Very High Level Language (VHLL), if you mandate not using it's high level facilities? If these people ever opt to use Perl 6, they will only ever use 50% of it facilities, because they will reject the rest on the basis that it is too complex.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      You took the words right out of my mouth. Not that I'd have used the orignal snippet as an example of beautiful code...

      It's time we snap out of this. If a maintainer can't understand code as simple as this, it's time for him to get educated. People should stop wasting time writing verbose code, and learn more elegant ways to do the same things. It's time they start to learn to recognize the typical Perl idioms, and stop trying to write a shadow of C in Perl.

      Who in his right mind would dare to call lines like

      for($i = 0; $i<$max; $i++) { ... }
      "simple" and understandable? It's verbose, it's ugly, it's impossible to read, and the only reason why people think it's readable is because they have learned to read it. And to be honest, it probably took them a relative long of time to learn it.

      It's time to learn something else.

        Isn't this the point of comments? I mean, so you can write code, which ... well is almost by definition not natural language, to do something, and then put a comment by it to explain how and why it does it?

        I don't care what a line of code does. I do care, that someone's taken the time and effort to document or comment what that bit does, if there's _any question at all_ about whether it's easy to understand or not.

      BrowserUk++ 'ere 'ere.

      I never really thought how patronizing my attitude towards my maintenance programmer is. I'm sure he's good at perl, otherwise he wouldn't have my job ;)

      @_=qw; ask f00li5h to appear and remain for a moment of pretend better than a lifetime;;s;;@_[map hex,split'',B204316D8C2A4516DE];;y/05/os/&print;

      Update Spelling does not work that way.

      Is cramming everything on one line really a "high level facility"?

      The OP asked this question because he thinks it could be easier to understand. True, it's not all that hard now, but why on Earth would you argue against possibly making your successors job easier?

      The positives of reformatting it: The next guy might be able to spend a few seconds less figuring out what it does.

      The negatives: Will you really cry yourself to sleep at night knowing someone is using some of your code that isn't "beautiful"?

Re: Should I leave behind beautiful code or readable code?
by roboticus (Canon) on Mar 28, 2007 at 12:02 UTC
    MaxKlokan:

    Please pardon this disjoint response. I've been gnashing my gears looking for a clear way to make my points, but I can't seem to tie it all together. Rather than giving up, I'll just break out the major bullet points I was working on:

  • The aphorism "Beauty is in the eye of the beholder" (most recently espoused by grinder) is particularly apropos. Keep in mind who your audience is. The computer, certainly, doesn't care a whit about how cool/clever/beautiful/readable the code is. Thus, your primary audience is (a) the maintainer, who is often (b) yourself, a year from now.
  • Too many people confuse 'clever' with 'beautiful'. While clever code has a certain attraction, it also requires good comments. These comments, however, are another thing to maintain. Also, having to study comments to decipher a 'cool/clever' technique in a production outage is a great way to foster contempt from your fellows, except whilst golfing.
  • Tension between 'beauty' and 'readability' fades with experience. When a programmer starts, 'beauty' often means fancy formatting and "cool/surprising" code. With enough experience you come to despise surprise. Later, beauty seems to become synonymous with clear and simple.
  • Readability doesn't require you to dumb-down your code and skip standard perl idiom. Just a little helpful formatting to show the structure (as shown by ferreira's example) will make things more beautiful/readable to many. Advanced programmers will read it with no difficulty, and the visual structure will help guide the less-advanced programmers to the appropriate perldoc pages to read first.

    --roboticus

    I'm not very happy with this node yet. Any suggestions for improvement would be extremely welcome.

    Update: Fixed link. (Thanks for catching that, Joost!)

Re: Should I leave behind beautiful code or readable code?
by MaxKlokan (Monk) on Mar 28, 2007 at 12:45 UTC
    Ok, I got the point that the code is not as beautiful as I thought at first, given all those references to "Beauty is in the eye of the beholder." :-)
    If somebody else had written my post, I myself would have probably replied along the lines of grinder's post. I also perfectly agree with BrowserUk. After all, I am supposed to write Perl code and use Perl's features and not to write C code in Perl.
    I think I will slightly refactor the code as follows:
    return map(split(' ',uc,2),@somearray);
    Thanks jwkrahn for the hints.
    Thanks everybody for your replies.
    I love posting my meditations. Reading what others think is enlightening!

    Max
      That's actually harder to read than the original.
        "Surely you're joking, Mr. perrin!" ;)

        But since it looked like you might be serious, I have to wonder: in what sense could two chained "map" operators be easier to grok than a single "map"? (Like other replies in this thread, I'll admit I had to pause and think more than I would have liked in order to understand the snippet in the OP.)

        One other point that I haven't seen raised yet: if there is a concern about "readability for the sake of maintainability", one should perhaps consider how well the code plays with the perl debugger. I've seen a few threads here at PM where people have remarked on how certain constructs are difficult to debug, because there's no way to break at a reasonable point, or even to step through a section of code effectively.

        For the particular code snippet in the OP, some unexpected input -- e.g. in some random element of @somearray, all the whitespace turns out to be "\xA0" (&nbsp;) instead of "\x20" (space) -- might make for a tough problem to diagnose in the code as written, and I, as a maintainer, would be inclined to change it (e.g. assign results of first map to an array, assign results of second map to an array, then return that array) in order to look at intermediate results and have some hope of figuring out what's going wrong.

        Okay, that's not such a big deal. Go ahead and be compact, and in that regard, "simpler" (avoiding unnecessary looping operations) is better.

Re: Should I leave behind beautiful code or readable code?
by perrin (Chancellor) on Mar 28, 2007 at 13:37 UTC
    To me, beautiful code is code that is so simple and so clear that it's obviously correct. This code took me too long to understand (realize it has to be read right to left, remember that uc defaults to $_, mentally pass the array from one map to the other...). I'd change it.
      I agree with what I believe is the spirit of this post.

      Even if I'm not an expert in a language, the code should be written clearly enough that when it says

      $x = function($a, $b);
      a reasonably intelligent person can correctly understand that 'function' is acting on $a and $b to produce result $x, for example. Then go find out what 'function' does.

      If a reasonably intelligent person can't even get that from the code without knowledge of all sorts of arcane idiosyncracies of the language, then we mustn't be surprised when IT managers reject Perl with that tired old refrain about it being unreadable

      Perl's 'beauty' may just be it's own downfall.




      Forget that fear of gravity,
      Get a little savagery in your life.
Re: Should I leave behind beautiful code or readable code?
by jcoxen (Deacon) on Mar 28, 2007 at 15:01 UTC
    If you're that worried about your replacement not being able to understand your code, either change the code or comment the bejesus out of it. Or more accurately, change the code or not as you see fit AND comment the bejesus out of it.

    My own preference is toward simpler to understand rather than 'elegant' code - mostly because I'm only a casual programmer. Still, with sufficient comments (and a couple of reference books) I've always been able to understand what's going on in a piece of code. You can be as elegant / beautiful / complex / obtuse as you want to be IF you have sufficient comments in your code to make clear what you're doing.

    Jack

      Comments are good. Do not avoid commenting. BUT... as another reply pointed out, comments have to be maintained as well. I like putting in javadoc-style comments, but I've encountered loads of places where it looks like someone has copied and pasted a function and somehow the comment block at the top describes something totally different from the actual procedure. And I will admit that I just left the erroneous comments as they were in most cases. The goal then is for code that is self-documenting and as far as possible only commenting on data structures, on side effects and any assumptions made about incoming data. In the OP's case, I didn't think the example was too bad and I think splitting it up too much could make it look more complicated and scary than it is.

      How can you feel when you're made of steel? I am made of steel. I am the Robot Tourist.
      Robot Tourist, by Ten Benson

Re: Should I leave behind beautiful code or readable code?
by talexb (Canon) on Mar 28, 2007 at 15:36 UTC
      I like it a lot (I know, I could even leave out the "return").

    My background as a C programmer requires that I always include the 'return' at the end of a subroutine. It's a visual reminder that explicitly states that a value is going back to the caller.

      However, in a few months I'll be off to new challenges and I will have to leave this code to be maintained by somebody else.

    Should your legacy be "Great code, but it took hours to figure out." or "Great code."? You may be working with these people or their bosses again -- you have no idea how small the world is until you've been working for a few years.

      Should I let my pride prevail and leave the code as it is, our should I be merciful to the maintainer and refactor it to something more readable to the non-initiated?

    I've heard that "Pride goeth before a fall". :)

    I highly recommend a) a comment explaining this cute piece of code, b) the addition of a few (unnecessary, I agree) braces to make the syntax more obvious, and c) leaving the 'return' in.

    Other replies notwithstanding, it took me a little while to read through that and figure out what it did. If we assume that the person who is going to maintain this is not as skilled at Perl, they'll probably be stumped. And if they're stumped, you'll probably get the call to interpret the code. At least if you've left something that's understandable, the explanation will be brief. If it's halfway to an obfuscation, that's not going to help anyone.

    The only reason I can think of for writing something clever, but difficult to read, is speed. Assembler hacks come to mind, an area of software development that is brutally honest. This isn't such a case. Swallow your pride and leave behind a readable, if somewhat less beautiful, piece of code.

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Re: Should I leave behind beautiful code or readable code?
by dragonchild (Archbishop) on Mar 28, 2007 at 17:32 UTC
    It all depends on who the maintainer is. In my consulting career, I consistently wrote code that would avoid map, grep, and other such "complex" constructs, save where I heavily commented it. In my last couple jobs, working with people who understood such code (like stvn and mst of DBIC/Catalyst), I use map/grep almost exclusively over for-loops, save where a for-loop is more appropriate from a coding perspective. Why? Because the map/grep code is more readable to us.

    Readability is the sole definition of beautiful. There is just a question about what's readable for whom.


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
Re: Should I leave behind beautiful code or readable code?
by gloryhack (Deacon) on Mar 28, 2007 at 17:44 UTC
    I have relatively recently decided that I'm not going to dumb things down any more. While I'm definitely not of the mindset that code that is hard to write should be hard to read, I believe that there's nothing to gain by assuming that the maintenance programmer is a dolt, and much to lose by encouraging the underqualified to futz around in working code.

    I've one client in particular who drove this decision. They want to be more or less self maintainers, so I made everything as simple as I could for them. The result is that after several years many things are in terrible disarray, still working but not well. Revision control? Forget it. I find out about changes either when they don't work and have to be corrected at a moment's notice, or when new projects intersect with damaged code and much of the damage has to be undone to restore carefully planned interoperability.

    So, my vote is for writing the best code even if it's beyond the neophyte and maybe stretches the limits of the moderately skilled. If the owner wants to turn the kid next door loose on it, fine -- either the kid next door or the owner will learn a valuable lesson, depending upon how well it works out.

    I think there may be easier ways to populate hashes than your cool map/split...

Re: Should I leave behind beautiful code or readable code?
by chromatic (Archbishop) on Mar 28, 2007 at 17:55 UTC

    Any company that hires inexperienced neophytes to maintain code has a bigger problem than code readability--namely that, in a million years, they might get a snippet of Shakespeare.

Re: Should I leave behind beautiful code or readable code?
by rir (Vicar) on Mar 29, 2007 at 02:11 UTC
    I'd write that as:
    return map { split / /, uc($_), 2 } @somearray;
    If your construct was necessary, I'd use the the block form of map and I'd make explicit the $_ argument to uc. The implicit arg to uc distracts me most. These are just personal preferences.

    The short and quick answer to your question is be merciful. For me, that you saw the need to ask predetermines the response.

    Were I sitting in your place considering simplifying and expanding code, I would be considering the size, complexity and stability of my_sub[not sic]. If my_sub is stable, which is to say well defined, well implemented and well tested, then the issue is less significant; noone is apt to need to read the function body--an ideal toward which to strive. If the function is large, readability may be helped by the shorter version. If the function is complex, making it easy to read becomes more beneficial to a maintainer.

    When I run into functions with which I am unfamiliar, I try to look them up; Perl's builtins are easy to look up so I'd likely just keep the map.

    The Perl constructs which I think are more worth avoiding for readability's sake are those based on punctuation. I don't mean the variables found in perlvar, rather things like a dereferencing a hashref slice; I don't see that as so complex just difficult for the unacquainted to look up.

    Be well,
    rir

Re: Should I leave behind beautiful code or readable code?
by colporteur (Initiate) on Mar 29, 2007 at 02:15 UTC
    As someone who is trying to fit Perl between all the other tools system administrators have to develop and maintain using aging synapses, I can use the help. Asking the question indicates you have a lesson to learn. Read the first chapter in Damian Conway's book Perl Best Practices. I think you will find the answer enlighting. I liked ferriera's approach. Maybe with a small comment. To quote Conway: "optimize for comprehensibility:easy-to-read and easy-to-understand are necessaryily the same thing." Good luck on your quest.
Re: Should I leave behind beautiful code or readable code?
by greenFox (Vicar) on Mar 29, 2007 at 02:48 UTC

    To misquote Buckminster Fuller "If the code is not readable it is not beautiful". You can have both readable and beautiful code and that's what I believe we should all aim for- the single map version of your code given by a couple of earlier posters would match my criteria but depending on the context a comment *may* be helpful too.

    "When I am working on a problem I never think about beauty. I only think about how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." - Buckminster Fuller

    --
    Do not seek to follow in the footsteps of the wise. Seek what they sought. -Basho

Re: Should I leave behind beautiful code or readable code?
by rob_au (Abbot) on Mar 29, 2007 at 02:49 UTC
    I would add to the other responses to this thread with the simple observation (based on having had to pick up and work on other people's otherwise erratic, uncommented and non-functional code mid-project in the past) that "readable code is beautiful code"

     

    perl -le "print unpack'N', pack'B32', '00000000000000000000001000000000'"

Re: Should I leave behind beautiful code or readable code?
by graff (Chancellor) on Mar 29, 2007 at 05:17 UTC
    Something about the OP comments (probably the remark about letting "pride prevail") reminded me of one of the earliest PM Meditations that I ever replied to (On Hubris -- my own reply was admittedly somewhat off the mark, but the thread as a whole was delightful). The main point raised there by the venerable belg4mit is quite relevant here, I think.

    A programmer (that is, any programmer who derives any amount of personal satisfaction from his or her work) may be naturally inclined to feel that the some piece of code s/he has just written is really good code. But that sense of "what qualifies as really good code" is prone to evolve over time, and stuff you wrote a year (or even a few months) ago may not measure up quite as well when held against your current standards. If viewed again another year from now, well...

    And of course, the direction of that evolution is bound to be influenced by your environment. Different (possibly mutually exclusive) things may seem more important (cross-platform robustness, rapid development, modularity, etc) depending on your recent, current and anticipated situations.

    Your sense of what is "readable" and what is "beautiful" will change with age. As others have intimated, you may reach that truly enlightened state where "readable" is "beautiful" and vice-versa.

    So for now, put aside the more emotional judgments, just do what you think is "right", and hope for the best.

      Amen, brother!

      I recently got pulled back to working on perl I wrote 4 years ago. I was doing cute stuff back then, that I thought was Great Code (tm) that I'd be embarrassed to post here. Thank (deity) that I left boatloads of comments in there, or I'd have been hours figuring it out again.

      Some pieces of code *are* great, but it may be useless to posterity if someone doesn't have the time (and the comments) to understand it.

Re: Should I leave behind beautiful code or readable code?
by mreece (Friar) on Mar 29, 2007 at 15:18 UTC
    i know what it does, but i don't know why. one problem with complex return values is that you have avoided giving a name to the structure you have created, forcing me to make one up. maybe the subroutine itself names the structure, but it is hard to tell with MySub.

    what is the significance of the first two columns of strings in @somearray? are you creating a hash or a list? what are you offering up as the "readable" alternative?

    without changing the expression itself, any of these would be clearer, depending:

    my %aliases_for_things = map split(/ /,$_,2), map uc, @somearray; return %aliases_for_things;
    return map split(/ /,$_,2), map uc, @somearray; # FIRST and LAST names
    my @labels_and_values = map split(/ /,$_,2), map uc, @somearray; return @labels_and_values;
    this naming is something you would have to do anyway were you to avoid the maps with the usual foreach...push alternative:
    my @flattened_pairs; foreach my $thing (@somearray) { my $upper_thing = uc $thing; my @pair = split / /, $upper_thing, 2; push @flattened_pairs, @pair; } return @flattened_pairs;
    as i read something like that, i'm mentally transforming it back to maps so i can personally understand it better anyway. the real gain here is not in the refactoring, but in giving a name to the structure you are returning.
Re: Should I leave behind beautiful code or readable code?
by halley (Prior) on Mar 29, 2007 at 17:43 UTC
    I agree with the comments about the redundant map. As for readability, I'm a big fan of judicious placement of carriage returns. When it comes to Perl's pipeline idioms, each map or grep is another step in the pipeline. That produces code like the following. I've left the redundant map in to highlight the effect.
    return map { split(/ /, $_, 2) } map { uc($_) } @somearray
    Sure, if the reader is very new to Perl, they don't understand pipeline idioms at all. However, if the idiom is formatted as consistently as possible, they can absorb it just as quickly as the chaining-return idioms of other languages, like joe = foo().bar().baz().

    --
    [ e d @ h a l l e y . c c ]

Re: Should I leave behind beautiful code or readable code?
by misterwhipple (Monk) on Mar 30, 2007 at 01:10 UTC

    "Rejoice, Mechanic!"
    the well tuned engine sings.
    Beauty is Useful.

    cat >~/.sig </dev/interesting
Re: Should I leave behind beautiful code or readable code?
by shmem (Canon) on Mar 31, 2007 at 23:17 UTC
    Leave beautiful code, which is readable code. If it weren't, how could you see its beauty?

    --shmem

    _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                                  /\_¯/(q    /
    ----------------------------  \__(m.====·.(_("always off the crowd"))."·
    ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
      I agree with you, but few monks in this thread seems to have noticed that in my OP I wrote "readable to the non-initiated" assuming that for a moderately experienced Perl programmer the code would be readable as such.
        Kernighan comes to mind - "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

        As a rule of thumb and corollary to that I'd say: Leave behind code that you understand at a glance, even were you looking at it some time from writing it. Others may still have to gnaw a bit - but the uninitiated will learn something, right?

        "Readable to the non-initiated" is malleable - initiated to what level? Acolyte, Friar, Hermit? :-)

        --shmem

        _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                                      /\_¯/(q    /
        ----------------------------  \__(m.====·.(_("always off the crowd"))."·
        ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
Re: Should I leave behind beautiful code or readable code?
by wfsp (Abbot) on Apr 01, 2007 at 09:44 UTC
    It's no good, I can't resist.

    Why doesn't anyones code look like mine?

    sub MySub { ...some stuff... #print scalar @somearray; my @jiggered = map{uc $_} @somearray; #print Dumper \@jiggered; my %hash = map {split(/ /, $_, 2)}, @jiggered; #print Dumper \%hash; #{ # my $file = 'tmp/hash_dump.txt' # # open my $fh, '>', $file # or die "can't open $file to write: $!"; # print $fh Dumper \%hash; #} #email_home('hey, we got to here!'); return %hash; }
    :-)

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (9)
As of 2014-07-29 02:02 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (211 votes), past polls