6 ms·

> There are plenty of things that are shown as possible in the Perl docs, and only slightly less things recognized as generally a bad idea in most circumstances

by JadeNB 11y ago

> There are plenty of things that are shown as possible in the Perl docs, and only slightly less things recognized as generally a bad idea in most circumstances. Notice, though, that I'm not talking about the Perl docs merely noting that it's possible—I agree that the spirit of the docs is more "look what I can do!" than "look what you should do." I'm talking about what Perl itself does (with the use of `$ARGV`, `@ARGV`, and `ARGV`—although maybe `$_` and `@_` is a better illustration). chromatic is an excellent programmer, and I certainly respect his voice on Perl over, say, mine, but I feel that he is rather strict, and I do not take his opinions as necessarily representing those of the larger Perl community, as exemplified, among many others, by Wall, tchrist, Conway, and/or merlin.

kbenson 11y ago
> I'm talking about what Perl itself does (with the use of `$ARGV`, `@ARGV`, and `ARGV` I suspect that's a combination of Perl's influence from awk (@ARGV), wanting something easier than awk's ARGIND for the current index in ARGV, and wanting to try out some of these new features Perl had in the beginning. I also suspect that things like this may be on the list of things Larry regrets about early Perl choices. I believe he's on record as saying he regrets the choice of sigil variance for array/hash and array/hash access (@foo as $foo[0] instead of something like @foo[0]). He's got good reasoning for why he chose what he did (based on language, it makes sense), but it's just overly confusing for beginners. > although maybe `$_` and `@_` is a better illustration I'm willing to give them a special case, because they are unique, as variables go (well, less so than they should be given Perl's many magic variables, but I think you understand my point). That said, I don't think many Perl programmers would argue that @_ was a better choice than @ARGUMENTS, or something equivalent. As for assuming the docs in general reflect the current best practices.. I'll just note that the perlopentut man page still uses bare filehandles in the majority of its examples, and to my mind that was decided long ago as a community to be downplayed in favor of lexical filehandles (but for more practical reasons than what we are discussing, bare filehandles are globally scoped). > chromatic is an excellent programmer, and I certainly respect his voice on Perl over, say, mine, but I feel that he is rather strict I'm not going to argue with that. I respect chromatic's opinions on style and Perl 5, but I'm not entirely sure he's capable of being entirely objective with Perl 6 yet (which I can understand). He is rather adamant about what he believes are better approaches to a topic. > I do not take his opinions as necessarily representing those of the larger Perl community, as exemplified, among many others, by Wall, tchrist, Conway, and/or merlin. Fair enough, but I wasn't sourcing that believe from Modern Perl, just pointing to it as evidence. To be honest, I haven't read Modern Perl (but I've read a lot of chromatic's writing from his blog back in the day when he was writing it), I just assumed it might have something to back up my view, so looked in it. My view on variable naming here is perfectly capable of being more my own opinion that the community, and I was projecting. It's hard to know in Perl unless there's a discussion (and sometimes even after that), as what's acceptable is often a mostly overlapping set of best practices from person to person, but rarely are the sets of preferences entirely equivalent. :) That said, Conway's Perl Best Practices suggests "Name arrays in the plural and hashes in the singular." It doesn't address our topic directly, but I don't know where my copy went (I sourced that from one of the many two page reference PDFs for PBP) and I don't recall the reasoning he used for that one. I wouldn't fault you for disagreeing with him though, I've shifted my view on some of his suggestions over the year towards or away from his suggestions (notably not using parens on built-ins, but I'm more in-line with his thinking now than I was a decade ago).
- JadeNB 11y ago
  Your points are all very good ones, and I appreciate your civil engagement with my argument—especially since all I've really done is quibble with your sources rather than produce any of my own (because I am in the same boat as you, being away from my Perl books). In fact, even if I could find quotations from eminent Perl programmers to support my position, the very nature of TIMTOWTDI would mean that my argument wouldn't represent the entirety, or even the majority of, the Perl community.
  - kbenson 11y ago
    Sure! In the end, there's not much that could really be said to definitively settle this besides a survey of a sizable amount of the Perl community. All we're left with is what our own preference is, and what's stuck out to us from books, blog posts, comments and meetings, which is very prone to confirmation bias. In the end, even if the consensus is it's better not done, I don't doubt it would be on the lighter side of ways you could disappoint coworkers. It's only really confusing to the Perl amateur. That's sort of what I meant by coworkers and dirty looks, rather than suggest your coworker will forcibly change your code for their own sanity. ;)
chromatic 11y ago
Keep in mind two things, with regard to Modern Perl: * it's a book for novice programmers, people with perhaps six months of practical programming experience * it's a book for novice Perl programmers, people who don't have voluminous experience with the language itself I believe programming is an exercise in making tradeoffs based on incomplete information. You can't teach the kind of good judgment that's based on experience, but I can try, at least, to guide novices away from some of the traps that they're likely to fall into. The subtleties of separate namespaces are difficult enough to learn on your own that it seemed worthwhile to advise strongly against name cognates. I don't expect that Larry, Tom, Damian, or Randal follow my advice. I don't even follow it in my own code many times. It's not advice for experts.
- JadeNB 11y ago
  I appreciate this measured response, but want to make very explicit that I did not mean to criticise you or your advice, much less deny its value to the novice programmer; I certainly apologise if I did so unintentionally. I always enjoy your writings on Perl, even if I sometimes disagree with specific opinion-based recommendations (as is, almost by definition, the prerogative of Perl programmers), and I hope that I didn't seem to be knocking you or them. I was not even disagreeing with this particular advice, just saying that it didn't necessarily establish the attitude of the broader Perl community on punning in variable names. (There always will be code golfers who will value cleverness over maintainability—and there should be; without them we would never have such gems as `[$a => $b]->[$b <= $a]` for `min($a, $b)`.)

by JadeNB 11y ago

kbenson 11y ago

> I'm talking about what Perl itself does (with the use of `$ARGV`, `@ARGV`, and `ARGV` I suspect that's a combination of Perl's influence from awk (@ARGV), wanting something easier than awk's ARGIND for the current index in ARGV, and wanting to try out some of these new features Perl had in the beginning. I also suspect that things like this may be on the list of things Larry regrets about early Perl choices. I believe he's on record as saying he regrets the choice of sigil variance for array/hash and array/hash access (@foo as $foo[0] instead of something like @foo[0]). He's got good reasoning for why he chose what he did (based on language, it makes sense), but it's just overly confusing for beginners. > although maybe `$_` and `@_` is a better illustration I'm willing to give them a special case, because they are unique, as variables go (well, less so than they should be given Perl's many magic variables, but I think you understand my point). That said, I don't think many Perl programmers would argue that @_ was a better choice than @ARGUMENTS, or something equivalent. As for assuming the docs in general reflect the current best practices.. I'll just note that the perlopentut man page still uses bare filehandles in the majority of its examples, and to my mind that was decided long ago as a community to be downplayed in favor of lexical filehandles (but for more practical reasons than what we are discussing, bare filehandles are globally scoped). > chromatic is an excellent programmer, and I certainly respect his voice on Perl over, say, mine, but I feel that he is rather strict I'm not going to argue with that. I respect chromatic's opinions on style and Perl 5, but I'm not entirely sure he's capable of being entirely objective with Perl 6 yet (which I can understand). He is rather adamant about what he believes are better approaches to a topic. > I do not take his opinions as necessarily representing those of the larger Perl community, as exemplified, among many others, by Wall, tchrist, Conway, and/or merlin. Fair enough, but I wasn't sourcing that believe from Modern Perl, just pointing to it as evidence. To be honest, I haven't read Modern Perl (but I've read a lot of chromatic's writing from his blog back in the day when he was writing it), I just assumed it might have something to back up my view, so looked in it. My view on variable naming here is perfectly capable of being more my own opinion that the community, and I was projecting. It's hard to know in Perl unless there's a discussion (and sometimes even after that), as what's acceptable is often a mostly overlapping set of best practices from person to person, but rarely are the sets of preferences entirely equivalent. :) That said, Conway's Perl Best Practices suggests "Name arrays in the plural and hashes in the singular." It doesn't address our topic directly, but I don't know where my copy went (I sourced that from one of the many two page reference PDFs for PBP) and I don't recall the reasoning he used for that one. I wouldn't fault you for disagreeing with him though, I've shifted my view on some of his suggestions over the year towards or away from his suggestions (notably not using parens on built-ins, but I'm more in-line with his thinking now than I was a decade ago).

JadeNB 11y ago
Your points are all very good ones, and I appreciate your civil engagement with my argument—especially since all I've really done is quibble with your sources rather than produce any of my own (because I am in the same boat as you, being away from my Perl books). In fact, even if I could find quotations from eminent Perl programmers to support my position, the very nature of TIMTOWTDI would mean that my argument wouldn't represent the entirety, or even the majority of, the Perl community.
- kbenson 11y ago
  Sure! In the end, there's not much that could really be said to definitively settle this besides a survey of a sizable amount of the Perl community. All we're left with is what our own preference is, and what's stuck out to us from books, blog posts, comments and meetings, which is very prone to confirmation bias. In the end, even if the consensus is it's better not done, I don't doubt it would be on the lighter side of ways you could disappoint coworkers. It's only really confusing to the Perl amateur. That's sort of what I meant by coworkers and dirty looks, rather than suggest your coworker will forcibly change your code for their own sanity. ;)

chromatic 11y ago

Keep in mind two things, with regard to Modern Perl: * it's a book for novice programmers, people with perhaps six months of practical programming experience * it's a book for novice Perl programmers, people who don't have voluminous experience with the language itself I believe programming is an exercise in making tradeoffs based on incomplete information. You can't teach the kind of good judgment that's based on experience, but I can try, at least, to guide novices away from some of the traps that they're likely to fall into. The subtleties of separate namespaces are difficult enough to learn on your own that it seemed worthwhile to advise strongly against name cognates. I don't expect that Larry, Tom, Damian, or Randal follow my advice. I don't even follow it in my own code many times. It's not advice for experts.

JadeNB 11y ago
I appreciate this measured response, but want to make very explicit that I did not mean to criticise you or your advice, much less deny its value to the novice programmer; I certainly apologise if I did so unintentionally. I always enjoy your writings on Perl, even if I sometimes disagree with specific opinion-based recommendations (as is, almost by definition, the prerogative of Perl programmers), and I hope that I didn't seem to be knocking you or them. I was not even disagreeing with this particular advice, just saying that it didn't necessarily establish the attitude of the broader Perl community on punning in variable names. (There always will be code golfers who will value cleverness over maintainability—and there should be; without them we would never have such gems as `[$a => $b]->[$b <= $a]` for `min($a, $b)`.)