Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re: What am I not understanding about $,

by Ovid (Cardinal)
on May 03, 2016 at 17:32 UTC ( #1162123=note: print w/replies, xml ) Need Help??


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

Replies are listed 'Best First'.
Re^2: What am I not understanding about $,
by BrowserUk (Pope) 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.
    "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
    In the absence of evidence, opinion is indistinguishable from prejudice.

      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.

      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?
        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.
        "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
        In the absence of evidence, opinion is indistinguishable from prejudice.

      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.

        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.


        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". I knew I was on the right track :)
        In the absence of evidence, opinion is indistinguishable from prejudice.

        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

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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1162123]
help
Chatterbox?
[Lady_Aleena]: Module is currently 104 lines but will shirnk to 63. The script using the module is currently 40 lines but will grow to 82, 180 to 146 lines total. (This is after rewrting the data files.)

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (5)
As of 2017-05-29 03:01 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?