Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

getting rid of costly special features

by LanX (Canon)
on Feb 17, 2013 at 13:07 UTC ( #1019130=perlmeditation: print w/ replies, xml ) Need Help??

Hi

Does anyone really use features like

DB<108> $str='zy'; print $str++," ",$str++," ",$str++ zy zz aaa

except maybe in one liners???

I'm sure when Perl was intended to replace sed and awk this was super cool, but now it's just weird too special to be worth the trouble.

What are the chances that one day we have a pragma unfeature which disables such stuff?

Cheers Rolf

Comment on getting rid of costly special features
Select or Download Code
Re: getting rid of special features
by moritz (Cardinal) on Feb 17, 2013 at 13:26 UTC

    I do. It happens to align nicely to the way popular spreadsheet calculations label their columns, and many non-geeks can make sense of it.

    What are the chances that one day we have a pragma unfeature which disables such stuff?

    I hope the chances are low.

    When maintaining code, I have to be aware of what all the operations do under all the pragmas in scope. Which is already complicated enough when dealing with nested scopes that have use bytes; and no bytes; in effect.

    And then we strict, warnings, utf8 (and no, utf8 is not the opposite of "bytes", that would be too easy), use 5.010 and other versions. Oh, and can you remember which version enables strict by default? was it 5.12 or 5.14? Do you even remember where that is documented?

    The proliferation of catch-all(-ish) pragmas like common::sense and Modern::Perl don't help at all, because none of them is a de-facto standard, so you have to remember (or read up) about each that you encounter in foreign code.

    Long rant, short summary: The need for pragmas is an indication of design smell.

    If we want to make Perl 5 actually simpler in the long run -- and I do think that's a worthy goal --, we shouldn't make it more complicated in the process.

    So rather deprecate stuff (with long enough deprecation periods to give even slow-moving companies the chance to crawl along) than layer more complexity on top of it.

    A finishing thought: I never had a bug in my code from 'z' incrementing to 'aa', and I've never seen a SoPW here at the monastery where that behavior caused a bug. A much more worthy target for deprecation would be this one here:

    $ perl -wE '$_ = "ababc"; my $re = ""; say /(ab)/; say /\Q$re\E/' ab ab

    That is, an empty regex matching the same as the previous match (instead of disallowing it, or matching the empty string), which is especially annoying if it's not obvious that $re is empty.

    Update: Ok, I couldn't resist: Making Perl 5 simpler, more transparent and generally more modern requires boldness and breaking backwards compatibility. Since the Perl 5 community strongly values backwards compatibility, Perl 6 was created to take this pain off of Perl 5. These days, most Perl 5 hackers have lost faith in Perl 6 (for which I can't blame them), but if they do want a modern Perl, they will have to face at least some of the pain they were trying to avoid 13 years ago. There is no easy path that leads both to evolution and backwards compatibility, and missing out on either of those two will cause pain.

      > I do. It happens to align nicely to the way popular spreadsheet calculations label their columns, and many non-geeks can make sense of it.

      actually I don't wanna get rid of the feature but of the syntax.

      better something like strinc() which does the same.

      (EDIT: Out of millions of postincs only few are supposed to increment strings, no need to share the operator.)

      > an empty regex matching the same as the previous match (instead of disallowing it, or matching the empty string), which is especially annoying if it's not obvious that $re is empty.

      I'm using this productively╣, but again I'd rather prefer another syntax, something like m/$ČLAST/ for matching the last successful regex.

      > So rather deprecate stuff (with long enough deprecation periods to give even slow-moving companies the chance to crawl along) than layer more complexity on top of it.

      we had a keynote talk about this in Riga ...

      ... but I asked about the chances that this really happens soon.

      These side-effects make translating Perl5 to other languages a pain in the *ss.

      perlito for instance gets it "wrong".

      If you think about the steps needed to mimic this behaviour in JS ... maybe with something like a function

      postinc(variable)

      which handles the cases it gets incredible complicated and slow for such a basic operation like ++, especially because JS can't do call-by-references.

      Cheers Rolf

      ╣) see Re^4: grep trouble (body of flip-flop range)

        These side-effects make translating Perl5 to other languages a pain in the *ss.

        And you've lost me :) translating perl to other languages shouldn't guide the design of perl, come on

        actually I don't wanna get rid of the feature but of the syntax.

        Then we are (mostly) in violent agreement.

        I still think that ++ being special-cased for strings is a rather harmless example, and there is another argument for keeping it: It's nicely symmetric with how ranges of strings work:

        $ perl -wE 'say for "a".."e"' a b c d e

        which might be used a bit more often than direct increment on strings.

        Now that we've already having this discussion, I'd like to point out some more Perl 5 features that could be reworked to much saner:

        • The flipflop (.. operator in scalar context) could have its own operator, making accidental usage of ranges in scalar context much less confusing
        • reverse should lose its magic dual functionality (list reversal vs. string reveral) depending on context. Perl 6 uses another function for string reversal (flip), but other approaches are possible too.
        • Whitespace is allowed between sigils and the name of the variable. There's no good reason to keep that.
        • Indirect method call syntax. (This one is hard to remove).
        • The control sequences for newish regex features are really obscure and hard to remember.

        But in the long run, removing cruft is only a small part of evolving Perl 5. I firmly believe that in order to stay competitive, it needs a type system(*), proper subroutine signatures and a less bare-bones OO system in core.

        (*) If the need for a type system isn't obvious to you, let me just tell you that at least 95% of all the character encoding trouble in Perl 5 could easily be avoided by having separate types for text strings and byte buffers.

        "...something like strinc"
        C:\>perl -E "sub strinc { $strToBeInc = shift; $strToBeInc++; return $strToBeInc; } my $str='a'; my $foo = strinc($str); say $foo;" b

        While I agree with what I think is one of moritz' points -- namely, that P5 is going to have to break backward-compat at some point... or stop improving and die -- I don't think we're there, yet, nor do I see how replicating the code behind ++ to provide a (duplicative) strinc is a plus, unless it allows removing a lot of cruft from ++.


        If you didn't program your executable by toggling in binary, it wasn't really programming!

        actually I don't wanna get rid of the feature but of the syntax. better something like strinc() which does the same.
        I find that a very PHP-like suggestion. Far easier to remember the different effects of ++ for strings and numerals, rather than remembering a different function and again another one for the pre-increment. We don't need different functions and operators for all different use-cases like PHP does.

        CountZero

        A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

        My blog: Imperial Deltronics
Re: getting rid of costly special features
by Tux (Monsignor) on Feb 17, 2013 at 14:06 UTC

    I do for the first two, but never into overflow: I use it when I know the length will stay the same, but I use it for numeric as well as for alphanumeric.

    Thinking of it, I seldom - maybe never - use those in one-liners, but I do in scripts:

    $ perl -wE'$_="image001";say++$_' image002

    Go perl! :)


    Enjoy, Have FUN! H.Merijn
Re: getting rid of costly special features
by flexvault (Parson) on Feb 17, 2013 at 15:46 UTC

    Thank you LanX,

    ++ for your question/comment. I can use this 'feature' now.

    I have an application that because of losing leading zeros in strings in Perl, always starts with a '1' followed by the maximum number of zeros for the field number. I have always used "1_000" for small field numbers and "10_000" for 'large' field numbers. Using this 'feature', I can use "A000", or "A0000" to start and if I underestimated the requirement, it will just increment past the theoretical end of "A9..9", giving 25 times more then the 'maximum' original guess.

    I also agree that 'strinc' would make sense, but why not add 'strinc' for new requirements, and leave the current implementation intact. Either way, I like the capability :-)

    Thanks...Ed

    "Well done is better than well said." - Benjamin Franklin

Re: getting rid of costly special features
by BrowserUk (Pope) on Feb 18, 2013 at 06:00 UTC
    Does anyone really use features like ...

    This is exactly the kind of introspective navel gazing that I think does Perl harm.

    If the magical string increment was removed from perl, no one would notice any performance difference at all in their production code.

    (Except those of use that do use it, and would have to re-implement it ourselves in Perl.)

    And as for it being a barrier to porting to JavaScript VMs. Its not that complicated an algorithm.

    But mostly, there are just so many more important issues that could occupy our time.


    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.
      > And as for it being a barrier to porting to JavaScript VMs. Its not that complicated an algorithm.

      Not complicated but very slow.

      It considerably slows down any numeric increment, which are >99% of the use cases.

      > magical string increment was removed from perl,

      I didn't say that, I just want a switch to turn it off.

      Cheers Rolf

        Not complicated but very slow. It considerably slows down any numeric increment

        Care to back that assertion up with some evidence?


        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.
Reaped: Re: getting rid of costly special features
by NodeReaper (Curate) on Feb 18, 2013 at 18:59 UTC
Re: getting rid of costly special features
by sundialsvc4 (Monsignor) on Feb 18, 2013 at 19:00 UTC
    (duplicate - removed)
Re: getting rid of costly special features
by sundialsvc4 (Monsignor) on Feb 19, 2013 at 00:16 UTC

    May I offer a friendly suggestion here?   When Perlmonks gather to discuss Perl features, let’s strictly confine the discussion to ... Perl features, not “fellow monks.”

    Perl is:   a tool.   Nothing more or less.   Our entire interest in it, is that it helps in some way to keep bread on our table.   There has been entirely too much name-calling here lately, too many insulting jabs and responses thereunto.   None of that has any rightful place in a monastery.   If you want to beat up on anyone for any reason, please take it outside to the parking lot.   If you have a beef against anyone personally, for any reason i.e. not related to Perl, please take it nowhere at all ... keep it to yourself.   It’s off the subject.   If you want to meditate on what might make Perl a better tool, please step forward to the microphone.

      May I offer a friendly suggestion here?

      As soon as you start taking suggestions and your own advice, please

      ....

      And now you're imagining things again.

      Unsolicited advice where it doesn't apply, not likely to be much of use -- and very likely wrong advice to boot

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://1019130]
Approved by moritz
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (8)
As of 2014-09-19 08:07 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (133 votes), past polls