For the most part, the “feature” that allows this is that if you aren’t running strict, a bareword that doesn’t resolve to a sub becomes a string. So offering an input of only Nok is taken as "Nok" and does nothing. This feature is not usually available, though there is one case that still works under strict, which is a bareword beginning with a dash. That can never be confused with the name of a sub, as dash is not allowed, and you’ll see it used very rarely to pass arguments that feel like command-line flags.
Since I’m explaining this to be educational, strict has been best practice for well over 20 years and on by default if you use v5.12 or later. I know strict was a thing in Perl 4 but i don’t know the history of the barewords-as-strings feature except that it’s almost always disabled and was also often the real secret to “perl golf” lines. Strict should just be the default but some folks concerned with backward compatibility believe that if they fixate on things like this, you’ll be able to run an ancient script with a new perl and absolutely nothing else will have changed and it will run fine.
The next feature I see helping out here is that if you use a numeric operator on a string, perl coerces to a number by looking for digits at the beginning. There is no switch for that, but there is a warning when that happens to a string that isn’t solely a number. Warnings are also a best practice and this can be made fatal, but note that it’s emitted/fatal at run-time while the feature above, rejected by strict, is fatal at compile time.
I think it’s the first one doing the heavy lifting, as most examples are just runs of letters. Both you don’t really run into with the old advice of use strict, use warnings.
Paint spatters have yet to spell out “use strict” - I think if we can get the precise bootstrap Pollack, we can shrink the space of invalid perl paint spatters to a minimum 😃
Strict should just be the default but some folks concerned with backward compatibility believe that if they fixate on things like this, you’ll be able to run an ancient script with a new perl and absolutely nothing else will have changed and it will run fine.
I respectfully disagree with you, and this is one of the reasons I have chosen Perl for my current project.
Not because of this specific feature– I am totally with “use strict”– but because of Perl’s general respect and high priority for backwards compatibility, unwillingness to break things for “progress”, and general stability.
There’s not really anyone champing at the bit to break things, but things have subtly broken or become deprecated regardless so you still can’t necessarily switch out a dependency like the interpreter and expect things to just run perfectly. The only way to be certain is to freeze your dependencies, or put in the time to update alongside your dependencies. At least perl releases have very good changelogs.
Like I said, folks fixate on this particular thing and say to switch the default is “breaking backward compatibility”. It’s a great example because it’s barely a break to make strict default: it would make “use strict;” lines redundant in current code, save every perl dev from having to write some form of use strict; in every file forever, and require people who try to run code that has been called a bad idea for the entire life of perl 5 to add “no strict;” in their stuff if they really want to run it with perl 5.34 in the year 2022.
This is so easy and people have resisted so much over the years and it’s almost certainly harmed perl. I mean here we are in a post that’s pretty much having a laugh at perl’s expense… because nobody ever flipped this default.
And I don’t meant to sound to harsh on perl here, because perl has absolutely moved forward too, it’s just that sometimes things should break, otherwise they’re holding you back. I mean Debian is also well regarded for its stability … but it’s also moved forward when necessary.
Umm… Use strict requires variable declaration before use, which is not required without it. That is a huge breaking change for many quick 10-liners.
And it would require an extra line of code “in every file forever” for every single quick 10-liner script people write in Perl, which is half of Perl’s use cases.
I appreciate both yours and @meredith’s views on this topic - whether a future Perl should be “use strict” by default.
However
Have you ever written any Perl?
is uncalled for.
I’ve written a ton of Perl (first used in production in 1999). I’ve always used strict and warnings, because I’m a dweeb who reads the documentation, and it’s saved my bacon a ton of times, and pre-declaring vars is what I learned to do in Pascal, damnit. I’ve never written a “quick 10 liner”, added it to production, and blithely expect it to keep running 19 years later.
I’m sure there are Perl hackers who simply cannot imagine having to comply with strict (they probably don’t grok references either), but are they a majority whose views should always be respected? I don’t think so. They have a voice and a vote, but so do the strict proponents.
People write Perl in their own way. It’s the blessing and the curse of the language. But it also should prevent one from casting judgement on other’s choice of how to write Perl. After all, there’s more than one way to do it.
I’ve been writing Perl for 20 years. I know the implications, as well as the possibilities for moving the language forward.
I wouldn’t call strict “variable declaration before use”, it’s more like “declare on first use”, except in cases where you need to refer to the variable again in the same statement it’s been declared in. I wouldn’t portray it quite like compulsory declaration at the top of a scope.
For anyone reading and unfamiliar with Perl, when you’re not in strict, the first mention of a variable without its scope having been established by my, our, or state, will be taken to refer to a package variable of that name, basically a global. In this context, strict is forcing you to be clear what you mean the first time you mention a variable within a lexical scope. Going without strict in this way is discouraged, for example, because it allows you to forget to say my somewhere then be surprised that a variable isn’t falling out of scope and being reset, it’s silently a global. Most Perl code today is ‘strict’, and there are occasional small scopes of no strict where someone can get weird in a controlled context (like an unsafe block in rust where you’ve got a hopefully small and readable scope where someone is carefully dereferencing a raw pointer), but it’s not usually this aspect of strict they’re turning off.
This is a pretty clear case of “on first use”. $xstr and $xid are declared at the same time their values are set in the middle of the function, even after a possible return. But the first use doesn’t even have to be the complete outer statement like this, it can be inline:
This is FFI, where I’m hiding weird C stuff from my caller in perl-land†, and I need to provide a reference to a variable for the C function to write the exception back in to - it’s only needed for this and to return on the next line, so it’s declared as a lexical, and a reference to it is made, in the middle of the line.
Personally, I think going without strict in any case except an actual command line one-liner is sloppy and prone to mistakes, but do you really think it would that burdensome to have to write ‘no strict;’ when you don’t want it or to just be explicit with ‘my/our’ in scripts? I haven’t had any trouble with it.
In my throwaway scripts I write everything strict-safe, even if I forget to literally enable strict - even in my REPL - but also I’m fairly sure there’s still much, much more business Perl code being written than “quick 10-liners.”
† Technically, Perl does allow mutating variables passed as arguments, but it’s somewhat discouraged (side effects!), as well as just more idiomatic to return a list of values, compared to how common this pattern is in C, so what you’re looking at is a tiny wrapper on the function just to switch the calling conventtion and return to something more perlish.
If you’re talking about the feature that lets a story submitter know that an article has already been submitted, it looks back no further than 30 days. (RECENT_DAYS is the story model.)
I get a silly kind of joy from these types of post. I got my professional start in Perl and still have a fair amount of nostalgic fondness for the language even if I’d probably never use it professionally these days.
This doesn’t really talk about what’s going on.
For the most part, the “feature” that allows this is that if you aren’t running
strict, a bareword that doesn’t resolve to a sub becomes a string. So offering an input of onlyNokis taken as"Nok"and does nothing. This feature is not usually available, though there is one case that still works under strict, which is a bareword beginning with a dash. That can never be confused with the name of a sub, as dash is not allowed, and you’ll see it used very rarely to pass arguments that feel like command-line flags.Since I’m explaining this to be educational, strict has been best practice for well over 20 years and on by default if you
use v5.12or later. I know strict was a thing in Perl 4 but i don’t know the history of the barewords-as-strings feature except that it’s almost always disabled and was also often the real secret to “perl golf” lines. Strict should just be the default but some folks concerned with backward compatibility believe that if they fixate on things like this, you’ll be able to run an ancient script with a new perl and absolutely nothing else will have changed and it will run fine.The next feature I see helping out here is that if you use a numeric operator on a string, perl coerces to a number by looking for digits at the beginning. There is no switch for that, but there is a warning when that happens to a string that isn’t solely a number. Warnings are also a best practice and this can be made fatal, but note that it’s emitted/fatal at run-time while the feature above, rejected by strict, is fatal at compile time.
I think it’s the first one doing the heavy lifting, as most examples are just runs of letters. Both you don’t really run into with the old advice of use strict, use warnings.
Paint spatters have yet to spell out “use strict” - I think if we can get the precise bootstrap Pollack, we can shrink the space of invalid perl paint spatters to a minimum 😃
I respectfully disagree with you, and this is one of the reasons I have chosen Perl for my current project.
Not because of this specific feature– I am totally with “use strict”– but because of Perl’s general respect and high priority for backwards compatibility, unwillingness to break things for “progress”, and general stability.
There’s not really anyone champing at the bit to break things, but things have subtly broken or become deprecated regardless so you still can’t necessarily switch out a dependency like the interpreter and expect things to just run perfectly. The only way to be certain is to freeze your dependencies, or put in the time to update alongside your dependencies. At least perl releases have very good changelogs.
Like I said, folks fixate on this particular thing and say to switch the default is “breaking backward compatibility”. It’s a great example because it’s barely a break to make strict default: it would make “use strict;” lines redundant in current code, save every perl dev from having to write some form of
use strict;in every file forever, and require people who try to run code that has been called a bad idea for the entire life of perl 5 to add “no strict;” in their stuff if they really want to run it with perl 5.34 in the year 2022.This is so easy and people have resisted so much over the years and it’s almost certainly harmed perl. I mean here we are in a post that’s pretty much having a laugh at perl’s expense… because nobody ever flipped this default.
And I don’t meant to sound to harsh on perl here, because perl has absolutely moved forward too, it’s just that sometimes things should break, otherwise they’re holding you back. I mean Debian is also well regarded for its stability … but it’s also moved forward when necessary.
Umm… Use strict requires variable declaration before use, which is not required without it. That is a huge breaking change for many quick 10-liners.
And it would require an extra line of code “in every file forever” for every single quick 10-liner script people write in Perl, which is half of Perl’s use cases.
Have you ever written any Perl?
I appreciate both yours and @meredith’s views on this topic - whether a future Perl should be “use strict” by default.
However
is uncalled for.
I’ve written a ton of Perl (first used in production in 1999). I’ve always used strict and warnings, because I’m a dweeb who reads the documentation, and it’s saved my bacon a ton of times, and pre-declaring vars is what I learned to do in Pascal, damnit. I’ve never written a “quick 10 liner”, added it to production, and blithely expect it to keep running 19 years later.
I’m sure there are Perl hackers who simply cannot imagine having to comply with
strict(they probably don’t grok references either), but are they a majority whose views should always be respected? I don’t think so. They have a voice and a vote, but so do the strict proponents.People write Perl in their own way. It’s the blessing and the curse of the language. But it also should prevent one from casting judgement on other’s choice of how to write Perl. After all, there’s more than one way to do it.
I’ve been writing Perl for 20 years. I know the implications, as well as the possibilities for moving the language forward.
I wouldn’t call strict “variable declaration before use”, it’s more like “declare on first use”, except in cases where you need to refer to the variable again in the same statement it’s been declared in. I wouldn’t portray it quite like compulsory declaration at the top of a scope.
For anyone reading and unfamiliar with Perl, when you’re not in strict, the first mention of a variable without its scope having been established by
my,our, orstate, will be taken to refer to a package variable of that name, basically a global. In this context, strict is forcing you to be clear what you mean the first time you mention a variable within a lexical scope. Going without strict in this way is discouraged, for example, because it allows you to forget to saymysomewhere then be surprised that a variable isn’t falling out of scope and being reset, it’s silently a global. Most Perl code today is ‘strict’, and there are occasional small scopes ofno strictwhere someone can get weird in a controlled context (like an unsafe block in rust where you’ve got a hopefully small and readable scope where someone is carefully dereferencing a raw pointer), but it’s not usually this aspect of strict they’re turning off.For example,
https://github.com/merrilymeredith/p5-Magick-Wand/blob/master/lib/Magick/Wand/API.pm#L77-L87
This is a pretty clear case of “on first use”.
$xstrand$xidare declared at the same time their values are set in the middle of the function, even after a possible return. But the first use doesn’t even have to be the complete outer statement like this, it can be inline:https://github.com/merrilymeredith/p5-Magick-Wand/blob/master/lib/Magick/Wand/API.pm#L113
This is FFI, where I’m hiding weird C stuff from my caller in perl-land†, and I need to provide a reference to a variable for the C function to write the exception back in to - it’s only needed for this and to return on the next line, so it’s declared as a lexical, and a reference to it is made, in the middle of the line.
Personally, I think going without strict in any case except an actual command line one-liner is sloppy and prone to mistakes, but do you really think it would that burdensome to have to write ‘no strict;’ when you don’t want it or to just be explicit with ‘my/our’ in scripts? I haven’t had any trouble with it.
In my throwaway scripts I write everything strict-safe, even if I forget to literally enable strict - even in my REPL - but also I’m fairly sure there’s still much, much more business Perl code being written than “quick 10-liners.”
† Technically, Perl does allow mutating variables passed as arguments, but it’s somewhat discouraged (side effects!), as well as just more idiomatic to return a list of values, compared to how common this pattern is in C, so what you’re looking at is a tiny wrapper on the function just to switch the calling conventtion and return to something more perlish.
We had that one already: https://lobste.rs/s/f1vies/93_paint_splatters_are_valid_perl
Only six months ago. With two out of three of the same tags. Is the auto-merge thingy not working, or is it not intended to handle this case?
If you’re talking about the feature that lets a story submitter know that an article has already been submitted, it looks back no further than 30 days. (RECENT_DAYS is the story model.)
The first links to a different domain, which now redirects to this one, but probably didn’t at the time.
…because nearly 93 % of paint splatters are valid undefined alphanumeric identifiers :-)
I get a silly kind of joy from these types of post. I got my professional start in Perl and still have a fair amount of nostalgic fondness for the language even if I’d probably never use it professionally these days.