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

Re^3: Modernizing the Postmodern Language?

by WaywardCode (Sexton)
on Jul 02, 2020 at 05:26 UTC ( [id://11118787]=note: print w/replies, xml ) Need Help??


in reply to Re^2: Modernizing the Postmodern Language?
in thread Modernizing the Postmodern Language?

If your code works with 5.32, why won't it work with 7?

If you aren’t inclined to change your code, plenty will break if the p7 announcement post is accurate—because flipping strict and turning off bareword file handles and indirect object calls breaks a lot of code.

If you are willing to change some pragmas, then nothing will break in 7. But what seems to bother me and almost no-one else is: they explicitly say you will lose compatibility promises when they move to 8–even guessed out loud that indirect object notation could be removed in 8 as an example. And they clearly don’t plan to wait too long to make that jump. What actually transpires may be very different, but I’m taking what was presented at face value, and I personally think it’s unwise. I could be convinced in the face of large gains (I listed a few that I would consider worth some breakage), but breaking compatibility because you think signatures look better where prototypes are? No thanks.

Replies are listed 'Best First'.
Re^4: Modernizing the Postmodern Language?
by Anonymous Monk on Jul 02, 2020 at 20:14 UTC
    If your code only works properly without strict, wasn't your code already broken? And broken by design? Unless you're talking about one liners (which will likely be just fine with the automatic compatibility mode on -e), only people who write code that would be a nightmare to review and maintain anyway will be caught off guard by perl7.
      No, that reasoning is wrong.

      You may see those "best practices" as an end in itself. I don't. I consider those practices something useful that allows me to write better code, catch more errors, etc. and that's why I use them. But then, if for some reason I get to some place where they get in the way I just ignore them without a blink.

      I have modules that don't use strict or warnings; I have code that uses bareword filehandles; probably, I have code that goes against any "best practice" of those that could become forced in perl 7.

      And it is good, reliable, beautiful code...

        And it's okay because you know Perl. You understand when and why strict, etc. might "get in the way" and how to keep working without them without having the world fall on your head. But the people who already 'know perl' and don't want to change aren't the audience for the future of perl7+. From the announcement, it's clear that the future of perl is targeted towards allowing people who do not currently know Perl to come into it with a standard foundation that even you admit helps you write better code. How many times has a person come here asking why code they found online or pieced together themselves doesn't work when it's something that would have been resolved if they knew to use strict and warnings (and if the message generated made any sense but that's an entire conversation itself)? The first few months of learning Perl is mostly "oh, I forgot to use strict before and now I see what's wrong." After all these years, I don't see how you don't agree that such basic 'best practices' should just be standard practice for people new to Perl who'll be writing "better code" from the start.

        As someone who 'knows perl', adding a one line pragma to keep your wild and crazy weekend coding lifestyle intact is hardly an onerous task. Because you'll be aware it exists and understand the impact, it's not nearly as much of a hindrance as flat out not knowing to use strict. ¯\_(ツ)_/¯
        «...I have modules that don't use strict or warnings; I have code that uses bareword filehandles...»

        You're fired!

        «The Crux of the Biscuit is the Apostrophe»

        perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help

      If your code only works properly without strict, wasn't your code already broken? And broken by design?

      that! (*points at you*) is the attitude that disgusted me so much from the announcements. SawyerX, is that you? LOL

      Wow. I don't know if it's still true today, but back when Perl was actually popular there were 1,000 "single-screen scripts" out in the wild for every CPAN module or application framework. And, emphatically and forever, I say it's silly to call those broken by design, or bad code, just because they didn't put unnecessary constraints on themselves.

      Anonymous, I script everything. Bash, sed, perl, python, lua, pwsh, and tons of others (but never once in awk, true fact). I write scripts that write scripts so I can script while I'm scripting. And I am here to bring you the good news that there is a wide wide spectrum of scripting tasks out there, and one size does not fit all.

      So sure, when you get past that one-screen level of script, you start to care more about misspelling a variable, and you don't mind spending a couple lines of code making sure $3 isn't undef before you splice it into a string. Probably 2/3rds of my perl scripts are strict+warnings, and factored into modules, and all that. But, Anonymous Monk, listen to me now and hear me later: the single screen, non-mission-critical, just-lives-in-my-$HOME scripting... the -p scripting where $cnt++ comes out of nowhere but totally has your back when you need the count at the END, is some of the best scripting there is. That's the 20-minutes of scripting that does the next 8 hours of your job while you browse XKCD. Don't miss out on that scripting, Anonymous.

      Broken? ...like a fox!

        I'm AM because the only people left on Perlmonks are those who will disagree with you out of spite and then hassle you for no reason until you just log out and forget your password. Look at your comments in this thread... you don't even really disagree with my comment but still swing between imagining I don't know that darkpan exists and can't grasp that some small scripts are one-offs that do a very small, specific task and do not need to be perfect as long as they work. But in the time it took you to write all that condescending noise, you could have tested and 'fixed' several of your little pet scripts that might not be strict-ready and be done with it. Instead, here you are, defending your right to not put `my` in your code.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11118787]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others pondering the Monastery: (7)
As of 2024-03-29 15:10 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found