Re^2: What am I not understanding about $,

[BrowserUk]

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!

[Ovid]

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.

[polettix]

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).

[BrowserUk]

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 :)

[polettix]

Thanks for taking the time to point me to the other post.

Again, anyway, I tended to read Ovid's suggestion in the light of robustness (where it seems to be adequate) instead of readabiliy, that's why I went down at the microscopic level. I understand that after reading too many suggestions like these you might snap though :)

[FormerMonk]

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:

1. Mutating global state is bad. We all know this. Why should Perl special variables get a pass on that?
2. And the last is certainly not the least.

[BrowserUk]

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!)

1. 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.)

2. 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:

   • Have you never written a program that needed to override the default assumption about what constitutes a newline?

     Eg. A *nix program that used sockets.

   • Have you never written a program that needed (or benefited from) overriding the default value of cwd?

   • Have you never written a program that benefited from overriding the default setting of STDIN, STDOUT or STDERR?

     You've never used the one-arg form of select; nor redirected STDERR to a log file?

   • You've never messed with %INC?

     Eg, used lib?

   • You've never tweaked %ENV?
   • How about installed your own signal handler in %SIG?
   • You've never felt the need to reset $@, $!, $^E, and $? before running code that might influence them; and which you need to make decisions upon the values they might acquire?

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.

[Anonymous Monk]

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