Re^3: Two simple code style advice questions

You have a point, but I think you're taking it a bit too far (and yes, I did stop and think).

First of all, "dumbing down" is an awfully harsh term here. The for loop and if statement solutions that LanX suggests are functionally equivalent to any other solution that has been proposed, and there is no meaningful performance penalty.

To me "dumbing down" would be avoiding powerful language features (such as regexes) because they are confusing. That would be dumb. But this is nothing more than a benign style preference.

Perl's allowable syntax is so vast that anyone who wants to write sane code will only use a subset of it. Maybe avoiding map and the ternary operator is going too far. But as much as I love map, I have to admit that I am usually using it "because I can" not because it is clearly advantageous in my code. And as much as I love the ternary operator, it has its pitfalls (such as the can-be-used-as-an-lvalue-making-assignments-have-unexpected-behavior pitfall).

Finally, all of your examples are professionals using their jargon with other professionals. Any good doctor will speak quite differently when talking to non-medical staff or a patient. Perl, because of the nature of the language, is often used by Perl "non-professionals"--sysadmins, web designers, and others who only spend a small part of their time writing Perl code. If this is your context, it makes sense to write the code with that in mind. It would be foolish not to.

Comment on Re^3: Two simple code style advice questions

Replies are listed 'Best First'.
Re^4: Two simple code style advice questions by BrowserUk (Patriarch) on Jan 18, 2013 at 01:09 UTC
But this is nothing more than a benign style preference. Sorry, but I think you must have missed the bit of LanX's post that I quoted, so I'll re-quote it here: At $work (where the word "ternary" provoked empty glares) My post was in specific reaction to that statement. (Though to be fair to LanX, it could equally have been applied to a lot of Re: Two simple code style advice questions). I have no problem with people choosing a particular style -- well, not too much anyway :). I do have a problem with programmers "simplifying" their preferred style under the justifiction that those that come along after them may not understand it. And I have even more problems with people advocating that everyone should dumb down their code in order to make it accessible to the lowest common denominator of programmer skill sets. Be that done under the auspices of 'best practices'; or 'modern Perl'; or Perl::Critic; or any other set of non-personal rules or guidelines. And the reason I have a problem with it is because it demeans the dedication and perseverance that it requires for even half descent programmers to acquire the education and skills that make them such. It encourages (and even enshrines!) the viewpoint amongst those non-programmers and 'did a bit once many years ago' semi-skilled programmers (think:managers and personnel types), that all too often control the purse strings (think:recruitment and education budgets), in our industry, into believing that programming is easy and that any ol'post-grad that had sufficient attendance on a half-credit basic programming or CompSci course, is sufficiently skilled to design, write and maintain code. Finally, all of your examples are professionals using their jargon with other professionals. Any good doctor will speak quite differently when talking to non-medical staff or a patient. Perl, because of the nature of the language, is often used by Perl "non-professionals"--sysadmins, web designers, and others who only spend a small part of their time writing Perl code. If this is your context, it makes sense to write the code with that in mind. It would be foolish not to. Sorry again, but that just doesn't make sense. Anyone who needs to read your code with a view to understanding it well enough to base business decisions upon that understanding, is acting in a professional capacity. As such they should be sufficiently educated to understand the code, or willing to expend the effort to acquire that education. And if they are not making business decisions based upon their understanding of the code, what do you care if they do not understand it? I'm most offended by "Perl, because of the nature of the language,". The fact that Perl is an accessible language -- designed to be so -- should not prevent the recognition that is a fully capable professional language usable for the construction of highly complex software. And just as with any other profession, the products of the programmer's skills require a certain level of education and/or aptitude to understand before you can hope to safely maintain, modify or extend them. Nobody would deny the non-programmer sysadmin from learning just enough Perl to allow him to knock up a few scripts to simply his daily workload; or the hobbyist webmaster from learning enough to add a bit of dynamism to his website. But trying to use that ease-of-entry of the Perl language as reasoning that professional Perl programmers should code down to their level is just crazy. Wrong at every level. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' 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.	[reply]
Re^4: Two simple code style advice questions by Anonymous Monk on Jan 17, 2013 at 11:02 UTC
sysadmins, web designers, and others who only spend a small part of their time writing Perl code. If this is your context, it makes sense to write the code with that in mind. It would be foolish not to. Funny, I can't envision that as a valid scenario -- if you can't read it, don't try to modify it ... educate yourself	[reply]
Re^5: Two simple code style advice questions (Chuck Norris) by LanX (Saint) on Jan 17, 2013 at 14:56 UTC
> ... educate yourself LOL ... Please take a seat and relax! I have a shocking message for you: `In some companies people don't wanna be educated!` Always a valuable read to get a taste of real life: "Chuck Norris"-ing code Cheers Rolf	[reply]
Re^6: Two simple code style advice questions (Chuck Norris) by Anonymous Monk on Jan 18, 2013 at 05:42 UTC
LOL... Please take a seat and relax! ... Thanks, I'm already sitting down and I'm relaxed, you'll notice because I'm not shouting I have a shocking message for you: In some companies people don't wanna be educated! That doesn't shock me, although I don't see why those people insist on playing with electricity	[reply]
Re^5: Two simple code style advice questions by Anonymous Monk on Jan 17, 2013 at 14:36 UTC
Well, ok...but in the real world you don't necessarily have control of who tries to modify your code!	[reply]
Re^6: Two simple code style advice questions by Anonymous Monk on Jan 18, 2013 at 05:33 UTC
Well, ok...but in the real world you don't necessarily have control of who tries to modify your code! My statement is about the context, its funny. All those sysadmins, web designers, and others who only spend a small part of their time writing Perl code , when faced with code they don't understand, should leave it alone If you don't know what you're doing, leave it alone You can't idiot-proof code, a smarter idiot will always come along to break it, so why bother	[reply]