Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re^4: Convert undef to empty string in a hash

by Anonymous Monk
on Jan 17, 2015 at 09:28 UTC ( #1113584=note: print w/replies, xml ) Need Help??


in reply to Re^3: Convert undef to empty string in a hash
in thread Convert undef to empty string in a hash

I'm a little bit saddened by the firm dismissal of (another) anonymonk. Quoted wikipedia interpretation is so broad it's borderline meaningless. But when a more specific definition is put forth, it is rejected.

The book you refer to ("97 Things Every Programmer Should Know") draws on many programmers' meditations. Quoted from the preface:

The contributions do not dovetail like modular parts, and there is no intent that they should—if anything, the opposite is true. The value of each contribution comes from its distinctiveness. The value of the collection lies in how the contributions complement, confirm, and even contradict one another.
Eyepops, your appeal to authority is bogus. There is no one best way here.

Long variable names themselves may induce cognitive load. The second suggested construct that uses values, might also increase cognitive load—for a perl novice—as it involves the concept of aliasing.

Replies are listed 'Best First'.
Re^5: Convert undef to empty string in a hash
by eyepopslikeamosquito (Bishop) on Jan 18, 2015 at 00:30 UTC

    I'm a little bit saddened by the firm dismissal of (another) anonymonk

    The firm dismissal was warranted in my view because he was trolling. Most of what he said was deliberate nonsense -- and he knew it was nonsense -- designed to provoke an emotional response. He even owned up to that here.

    I'm a little bit saddened I fell for it though, with the thread quickly degenerating into emotion, not reason. I started with "Of GrandFather's two solutions, from the perspective of DRY, this one is better". I did not claim it as an absolute best solution. As you say, which solution is "better" depends on context and taste.

    I wish it had stopped there, but I was baited and responded emotionally. He had me going until he made the fatal mistake of mentioning sundialsvc4, which shocked me into realizing I had been sucked in. So I broke it off immediately. BTW, if you are really him, kudos on successfully baiting me again. :)

    Long variable names themselves may induce cognitive load
    Nowhere did I endorse long variable names. I assumed it self-evident that long variable names that differ in just one character (such as my example number_of_immortal_perl_monks vs number_of_immoral_perl_monks) show appalling taste and were used only to illustrate a point, while adding a bit of humour.

    The second suggested construct that uses values, might also increase cognitive load—for a perl novice—as it involves the concept of aliasing
    Of course, like writing style, programming style depends on the audience, the reader. Code read and maintained by Perl experts should be written in a different style to code maintained by Perl novices.

      > I wish it had stopped there

      It's never too late ... ;D

      Cheers Rolf

      PS: Je suis Charlie!

      The firm dismissal was warranted in my view because he was trolling. Most of what he said was deliberate nonsense -- and he knew it was nonsense -- designed to provoke an emotional response. He even owned up to that here.

      I owned up to no such thing.

      I owned up to comparing you to the that guy because you used his exact words -- as soon as I recognized the words, I went ugh -- but I had to point it out because its a real weak argument -- but that got you to stop posting on the actual topic

      looks wrong? DRY isn't about looks

      Not all ideas put forth are accurate, and exploring them isn't trolling -- resorting to ad-hominem doesn't explain anything

      I'll try to pick it up , the Don't repeat yourself page links to interview with authors of the book Orthogonality and the DRY Principle

      Dave Thomas: Most people take DRY to mean you shouldn't duplicate code. That's not its intention.

      DRY says that every piece of system knowledge should have one authoritative, unambiguous representation. Every piece of knowledge in the development of something should have a single representation. A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation.

      Saying one version is shorter, more perlish, more clear -- that all makes sense

      Saying its more DRY doesn't make sense

      Saying the maintenance programmer goes ... thats a great topic if the exploration goes beyond "because I said so, you're a noob"

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (8)
As of 2021-05-07 13:03 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Perl 7 will be out ...





    Results (91 votes). Check out past polls.

    Notices?