|
in reply to What am I not understanding about $,
As pointed out, you probably want $" instead of $,, but in reality, you want to join those elements and print them that way:
my @array =
(
'abc', 'def', 'ghi', 'jkl', 'mno', 'pqr', 'stu', 'vwx', 'yz '
);
my $output = join '', @array[2,4];
print "$output\n";
Why is that better? Because nobody knows what $" is, but everyone knows what join() is. Always write your software to be as readable as possible :)
|
Re^2: What am I not understanding about $,
by BrowserUk (Patriarch) on May 04, 2016 at 08:32 UTC
|
Because nobody knows what $" is
Anyone who doesn't know what $" is, almost certainly won't understand @array[2,4], so you better make that:
my $output = join '', $array[2], $array[4];
But then, even if they know about the function join(), they probably won't understand the statement join, so you'd better make that: my $output = join( '', $array[2], $array[4] );
Then, of course, for consistency you should make that last line: print( "$output\n" );
But WFT!? Variable names inside quoted strings? That can't be right: print( $output . "\n" );
But what the hell is that dot doing there!? print( join( '', $output, "\n" ) );
But hang on a minute! Nested function calls!? We can sort that abomination out: my $output2 = join( '', $output, "\n" );
print( $output2 );
my @array =
(
'abc', 'def', 'ghi', 'jkl', 'mno', 'pqr', 'stu', 'vwx', 'yz '
);
my $output = join( '', $array[2], $array[4] );
my $output2 = join( '', $output, "\n" );
print( $output2 );
But, but, but, where are the classes and objects and methods and, and and ... Sod this! I'm going back to a proper language like JavaPy++ Cscript 3000 where fings are dun proply!
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.
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l]
[select] |
|
|
The issue I have isn't so much with the core Perl behavior, so much as the plethora of built-in global variables in Perl, and the general abuse of globals. For example, in one of my @INC directories I ran ack '^\s*\$\w+::.*=' and read plenty of CPAN modules who set global variables for other packages and don't localize those changes. I've had my code break as a result of other people doing that and it's very hard to track down these bugs.
When you combine the potential for mysterious action at a distance along with the relatively inscrutable punctuation variables, it's a double-whammy in my book. Thus, I used to use local $" = ...;, but I've stopped doing that and recommend join (yes, even with array slices) because it's clear and there's less risk of mysterious side effects.
| [reply] |
|
|
Ovid's reference to readability is wrong IMHO, the intent of "@array" is indeed clear.
That's unfortunate because it transformed a perfectly sensible suggestion about robustness - try to avoid global variables if you can, they might bite you in the long run - in a battle for idioms.
Some of your suggestions might be read in that light too, but I'd make them more explicit:
- Variable names inside quoted strings? - are you thinking about overloading the stringification operator?
- But what the hell is that dot doing there!? - are you thinking about overloading the dot operator?
- ... I fail to see a reason why nested function calls might be detrimental from a robustness point of view though.
Operator overloading is definitely possible but highly improbable though as it's quite difficult (at least for me) to overload an operator in every possible scope. I'm eager to see comments about it, I'll be able to learn something about operator overloading at last :).
Anyway... I tend to consider operators safe and the transformations unneeded. (I would stress I in the last statement).
Personally, I always feel a strange tingling when using "@expand_me", and I do so only in very basic situations and temporary print statements for debugging. I prefer Ovid's way in code that has a longer lifespan. This is where I set the line between idiomatic and idiotic (couldn't resist the pun, sorry).
perl -ple'$_=reverse' <<<ti.xittelop@oivalf
Io ho capito... ma tu che hai detto?
| [reply]
[d/l]
[select] |
|
|
are you thinking about overloading the ?? operator?
No. The point was simply that if you don't know perl, both those things are likely to be unreadable.
I fail to see a reason why nested function calls might be detrimental from a robustness point of view though.
Reductio ad absurdum, dear boy, reductio ad absurdum!
You're taking my post far too seriously at the microscopic level; and ignoring forgetting my point at the macroscopic level.
Personally, I always feel a strange tingling when using "@expand_me", and I do so only in very basic situations and temporary print statements for debugging. I prefer Ovid's way in code that has a longer lifespan.
I can't say it better than I did in my next post in this thread: Being selective about what functionality you accept as legitimate, and what you personally choose to reject is one thing; attempting to impose your affectations upon the world at large is another. If you haven't read it, that same post goes into much more detail of my feelings about selectivity.
I have no problem with your or Ovid's preferences -- I have my own -- but I do have a problem with Ovid's (and most other) justifications for rejecting parts of the language:
... nobody knows what $" is, but everyone knows what join() is.
This is where I set the line between idiomatic and idiotic.
I wish I said that. Then again, I probably will :)
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.
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
|
|
|
Thank you oh so very much for reminding me why I left Perl Monks. I was last here 5 years ago under a name I have long since forgotten the password to, and — to be honest — who I am (or was) is of no consequence. If you need to know who I am to take me seriously, then you've already lost the plot.
Do you remember the "fun" that was this SoPW? I was around for that and wondered why Abigail responded the way he did. Over time I came to understand his position; eventually leading me to quietly walk away a few years after the aforementioned exchange.
I will leave you with two things:
- Mutating global state is bad. We all know this. Why should Perl special variables get a pass on that?
- And the last is certainly not the least.
| [reply] |
|
|
Why should Perl special variables get a pass on that?
If you, as a "former monk" don't understand, then it both explains why you left; and why nothing I could possibly say would make the slightest bit of difference to your perception of this situation.
The key indicator here is your phrase: "Mutating global state is bad."
By which you mean: varying variables with top level scope. is verboten; (by you!)
- There is no point in having variables; if you cannot vary them!
Variables that do not; or are not "permitted" to, vary, are constants.
(It is this, beyond the performance penalties, that make Readonly a nonsense.)
- Every program has a 'top level scope'.
Choosing to differentiate between "global variables" and "top level, lexical variables" is a sham. A pointless and puerile non-distinction.
Further, every (useful) program ever written makes some assumptions about ... whatever. This is usually referred to as "configuration".
So your (bland and uninteresting; unless you bother to follow up with some supporting argument) statement reduces to: is there any legitimate reason for a program to ever override its startup assumptions?
And fine, if you can sit wherever you are, and hand-on-heart, conclude that there is never a legitimate reason for a program to override its startup assumptions; then you've won the argument.
But, before you pat yourself on the back consider each of these:
If you can say "No" to all of those; then you've both won the argument, and are either a liar; or not a programmer.
Being selective about what functionality you accept as legitimate, and what you personally choose to reject is one thing; attempting to impose your affectations upon the world at large is another.
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.
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l]
[select] |
|
|
Why bother saying any of that non-message related stuff if your message is what you want people to focus on?
My argument isn't strong enough, so I'll distract with the sentimental nostalgia
Mutating global state is bad. We all know this. Why should Perl special variables get a pass on that?
Hehe, why single out special variables, like STDIN/STDOUT/STDERR/@ARGV, why not single out perl itself? I mean global namespaces and all that, that's ten times worse than the special variables
| [reply] |
Re^2: What am I not understanding about $,
by bart (Canon) on May 04, 2016 at 06:52 UTC
|
I so want to downvote this. Please stop trying to convert Perl into Java. | [reply] |
|
|
Downvote away, I don't mind :) But first read Re^3: What am I not understanding about $,. I assure you I'm not trying to turn Perl into Java; I'm only trying to avoid the potential for abuse of inscrutable global behavior.
| [reply] |
|
|
