Re^4: 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.

Comment on Re^4: Convert undef to empty string in a hash Download Code

Replies are listed 'Best First'.
Re^5: Convert undef to empty string in a hash by eyepopslikeamosquito (Archbishop) 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.	[reply] [d/l] [select]
Re^6: Convert undef to empty string in a hash by LanX (Saint) on Jan 18, 2015 at 00:49 UTC
> I wish it had stopped there It's never too late ... ;D Cheers Rolf PS: Je suis Charlie!	[reply]
Re^6: Convert undef to empty string in a hash by Anonymous Monk on Jan 18, 2015 at 11:59 UTC
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"	[reply]