Which is one of the things I'm definitely looking forward to when (if!;)) it appears.

These are lines that get typed in 99% of the stuff I write (unless there's a good reason not to) and if nothing else, hey, it'll save on finger strain.

I'm still amazed by the amount of people at my current place of work who don't use strict (experienced programmers and not just new hires). It makes life updating their work when clients require it a bit of a 'mare to say the least. If things like strict were default then my life would certainly be easier.

--- Jay

All code is untested unless otherwise stated.
All opinions expressed are my own and are intended as guidance, not gospel; please treat what I say as such and as Abigail said Think for yourself.
If in doubt ask.

These are lines that get typed in 99% of the stuff I write (unless there's a good reason not to) and if nothing else, hey, it'll save on finger strain.

I always use strict for programs that are not of the -e type, and I'm a lazy typist. My solution was to tell my text editor (vim, but you can surely do something similar with others) to read from a template file whenever I try to edit a non-existent file ending on .pl. The template file includes the shebang line, use strict and use warnings. I also have a template file for *.pm with a little bit more stuff.

One of the major breaks that Perl6 makes is that strict (...) will be on by default.

Unfortunately, only in modules. The main program is still strictless :(

This is one of the things where I hope I misinterpreted the Apocalypses.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

There are several things to say about that. First, all Perl 6 programs already "use strict refs" because Perl 6 differentiates ${$hardref} from $::($symref) syntactically.

Second, all Perl 6 programs already "use strict syms" because there are no barewords in Perl 6.

That leaves only "use strict vars" which, as has been pointed out, is on by default in modules and classes. So all you have to do to get strictures in the main program is put

    module Main;
[download]

at the top, and you automatically get strictures and warnings. Hey, it's a lot shorter than IDENTIFICATION DIVISION... :-)

Look, I grew up in California, where we have decent freeways, by and large. A good freeway has to have both fast lanes and slow lanes, and onramps that don't require you to merge until you're ready. Not everyone coming up the onramp into the slow lane has an engine with great acceleration. I drive a 1977 Honda Accord, and I don't particularly appreciate merging into a freeway when someone whose shoesize is larger than their IQ is coming up in the slow lane at 90 mph, usually in an oversized SUV. But most drivers here are polite, and if you come onto the freeway with less-than-ideal velocity or acceleration, they'll move over to let you on.

Requiring you to say module Main to get strictures is in the same category as moving over a lane to make it easier for someone to get started on Perl 6, I think. I admit it's an arbitrary place to draw the boundary, but all the other places are just as arbitrary.

I think you're correct, Juerd. AFAIK, it's the enclosing package-type declaration, if any, that determines the strictures.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

until then, you could still bribe your unix sysadmins to   alias perl='perl -Mstrict'   globally.

Anybody can turn it of with   alias/unalias   and it doesn't affect shebangs anyway, so old code will still work, unless calling perl without a path to it.

Of course, to be really mean, you could put a wrapper around   /usr/bin/perl   too...

Cheers, Sören

Of course, to be really mean, you could put a wrapper around /usr/bin/perl too...

That is not mean. Ovid's Acme::Code::Police is mean.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

Perl one liners are nice. Don't forget that, although perl is also an awesome fully-featured programming language, it's roots are as a command-line data-processing tool (ala sed, awk and even grep). Who wants to spend those extra characters in a -e?

Don't get me wrong, I like strict in anything more than a few lines long, but I also write a lot of stuff that's less than a few lines long.

------------
:Wq
Not an editor command: Wq
[download]

This argument doesn't addresss the fact that one could arrange it so perl would turn on strict and warnings for code from any other source than -e but leave -e code unencumbered.



---
demerphq


First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi

Flux8

Or you could have another name for the binary that makes perl assume use strict; (and maybe warnings also)…

#!/usr/bin/perls
no swine;
[download]

Makeshifts last the longest.

People who want to write really short one-liners and stuff. We'd be forced to choose between explicitly turning off strict or declaring every little thing, which kind of defeats the point of Perl being such a nice language for extremely small programs.

Update: Apparently Perl 6 will take a compromise approach. use strict will be off by default for -e programs (one-liners) and on for everything else. I think that's fair.

Agree whole-heartedly that strict should be on by default. A few people who use Perl only for sysadmin scripting might complain they had to type 'no strict' at the top of every program, but these people are in the minority now.

When I first started coding in Perl, i never use'd scrict (mainly because I didn't know it existed). Once I'd developed a whole lot of bad habits (like never using 'my'), it took a long time for me to break them. I think this is something that causes a lot of people to decide not to use strict - it seems like a big learning curve when you've already been using Perl without issue for years...

Backwards compatability issues could be solved... it's only going to affect people who upgrade their Perl version.. if they do that on a system that has important stuff on it, they should RTFM, and see that they have to set such and such environment variable to turn off strict, or update all their code.

In my company, Perl is seen as a lower level in the food chain than other languages (even ASP), and it's mainly because most people don't use strict. Even if they do, they don't realise the importance of it. I think Perl would be taken a lot more seriously as an application language if use strict was the default.

A few people who use Perl only for sysadmin scripting might complain they had to type 'no strict' at the top of every program, but these people are in the minority now.

Source, please.

I hate to say this, but there is so much crap Perl code out there on the internet in free (and paid for) CGI programs, dodgy tutorials, half-arsed postings on various forums and so forth, that barely struggles to resemble Perl 5 let alone run under 'strict' that if stricture were to become the default (and consequently all this crap code stopped working) then we would all be inconvenienced as we are inundated here (and other places people talk about perl) by the torrent of questions of the "I got this code from <replace with favourite resource of hate> and it doesn't work" variety, it would probably drown out all the other content, the more insightful posters would get bored of answering the same question over and over and would drift away, and the people left would only know enough to type no strict at the top of their programs ...

Okay perhaps I exaggerate, but you get my point.

/J\

I guess I would 'fix' that problem by including an extra prompt that would be displayed when an AM or new member (say their first 10 posts), posts a SoPW that read:

Is your problem related to the (possibly sudden) appearance of errors like:

"Global symbol "$x" requires explicit package name at ..."?

Are you using, or did you just install version 5.x.strict of Perl?

Have you tried adding "no strict" to the top of your program?

You must answer these questions before continuing.

If you answer "Yes, Yes, No" to these 3 questions your question will not be submitted.

If you answer otherwise, but it then transpires that you lied, your question will be summarially deleted and ignored.

If adding "no strict" fixes your problem, but you would like to learn how to avoid using it, then Welcome to the Monastery.

Hmm. Probably need a lawyer (or just someone competent with English!) to get the wording just right. Or maybe that's just too selfish? :)

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

What makes you think that someone who doesn't know what 'strict' does really wants to avoid using "no strict", if "no strict" solves his problem?

All you do is cargo cult "no strict" into every bad program! Hurray, a great victory!

Aren't you overdramatising things a bit?

Makeshifts last the longest.

So far, I see no convincing argument from either side. All the various similes and analogies limp equally. It may be fun to draw elaborate parallels to metaphoric images, but that does nothing to actually analyze the situation.

As near as I can tell, there are two factual concerns:

• Backward compatibility.
• Encouragement or good habits.

As I already said on this thread, the latter is a social issue rather than a technical one. I do not think defaulting to strictures would solve it.

Many novices start out with Perl by making minor modifications to existing code, which are often incredibly shoddily written scripts found somewhere on the web. What would happen if strictures became the default? As has been mentioned elsewhere, likely, no strict; would be cargo culted into them. It's a given that that wouldn't help the existing code base, but would it improve the situation for the twiddling novices? Unlikely. If they don't understand strictures, they're not going to take the time for a quick script of their own they feel confident enough to write, either. After all, sticking no strict; in there works.

Other novices start out by reading tutorials or books with bad advice (or, more precisely, a lack of good advice). The situation is not so clear here. I can certainly see it that some of those will actually be updated to encourage no strict;. Many will not be updated, resulting in confusion for their readers. Others will be updated with confused advice (<q>use my for all variables</q>). Overall, there is no clear win here either.

The situation is similar to that of gun control. In Germany, it is very difficult to legally own a real gun (other than certain classes of BB guns). It is very clear that Germany has profitted from this; areas with very low gun density tend to have very low crime rates, also. Criminals are easier to pin down as well, if only because their posession of guns is illegal and provides a means to get hold of them. But the situation is very different in the USA, where there is no strict gun control, and hundreds of millions of guns (at least) are already in circulation. You cannot solve the problems there simply by introducing gun control laws and expecting it all to sort itself out. The USA have not had use strict; in their gun legislation in eons, and defaulting to it now would be as problematic as it is a good idea. Germany has no such problem because Germany has always defaulted to strictures.

With Perl6, we will have the opportunity of a tabula rasa; and indeed, it will (not entirely, but largely) default to strictures. I see this as the best possible course of action that can be taken at this time. Defaulting new versions of Perl5 to strictures, on the other hand, would be a mistake.

Thankyou. Nice counter argument.

All the various similes and analogies limp equally.

I think that my 'sport mode' analogy is very accurate. The only people against the idea are those wizards who see it as training wheels, and the typing of (say) -z on the shebang line an imposition. For most of them it would be typed once into their emacs template or equivalent. A one-time, two keystroke effort.

Instead, another two generations of newbies have to (un)learn the hard way.

• Backwards compatibility.

  For anyone building their own version of Perl, who knew that the would be at risk of this, simply opts out of the use strict; default.

  For P6, if it was enabled this way from the start, this becomes a non-issue. If it isn't, it can never be changed for this reason. P6 is designed to last 20+ years? If it takes off, that's an aweful lot of newbies that have to "discover" it. And let's face it. We will all be newbies.

  Would you consider trying to write your first P6 program without enabling strict and warnings? I know I won't.

• Encouragement of good habits.

  Social issue or not, all those posts that say: "I've tried to enable strict and warnings, but it is just so hard" testify that unlearning bad habits is always harder than learning good ones.

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

Yes, your "sports mode" analogy certainly is much less faulty than some others, but that doesn't make it very precise. It cannot convey one-liner vs application, and it shears completely once you start considering that you can very well use modules written to run under strictures in one-liners (LWP::Simple, anyone?), and ever more so since such a module might itself be using other modules that are not written to run under strictures… But it wasn't my aim to dispute each metaphor individually.

Social issue or not, all those posts that say: "I've tried to enable strict and warnings, but it is just so hard" testify that unlearning bad habits is always harder than learning good ones.

I never claimed otherwise. I did say that the overwhelming majority of the teaching material available, whether that be for those who learn by example of for those who learn by lesson, teaches bad habits. Defaultifying strictures will not change that.

Even if use strict; was to be the default from now on, most novices will still end up having to unlearn bad habits, because we have a huge legacy of bad habits in the wider Perl culture. Some of it is even built right into Perl — just look at all the globals that control I/O behaviour. This can't all just change overnight.

I understand your concern and I certainly do wish we could teach everyone good practice right off the bat, so they would make both their own and our lives easier. But to think that just enabling strictures by default is all that this will take is vastly oversimplifying the matter. And that legacy gives us an unfortunate and unwelcome but nevertheless very real reason not to default to strictures.

Sometimes, reality just bites.

Here's hoping that the community's rewrite of the community will improve matters.

Makeshifts last the longest.

Let me get one thing straight: I think using strict and warnings is a good idea. There's no discussion about that. I just don't think my believes should be trusted upon others by making it the default. I also think it's a good idea to eat two pieces of fruit a day, and to not drink coffee. That doesn't mean I think in offices coffee machines should be replaced with fruit baskets, and those who want coffee should fetch it in the basement.

I also agree that for a lot of programmers, whether they are newbies or more seasoned, more BDSM in the language would be a good benefit for them. Not just "use strict", but also a strong type system and a far more rigid syntax. It'll improve the quality of many programmers programs. But you shouldn't do that by changing the language - the programmers who need more structure need to change language.

I'm happy enough to wait until P6 for strictures to be (more or less) default... there's certainly no backwards compatability issue here...

A main reason to not have use strict or warnings mandatory is the fact that perl4 doesn't have them. By making strictness and warnings the default, programs would break - a high price to pay for the small gain earned (a few keystrokes).

I don't think they should be mandatory. BSDM should be done with explicite consent, just like in sex.

It just struck me reading yet another "I haven't quite yet made the leap to using strict and my..." story of woe that if it were made

• the default configuration for source distributions.

  Most installations needing backwards compatibility probably build their own, and would be able to cope with changing the default configuration.

• the default for binary distributions disable-abe by a command line, she-bang line or PERL5OPT switch.

an aweful lot of newbies would have been saved an aweful lot of pain by not building the seemingly insurmountable "barrier of experience" to using strict.

Ce la vie. History shows, but rarely shows it well.

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

Exactly... I really struggle to see who we're protecting with this backwards compatability issue. There's basically two groups

• People who download a script from somewhere that doesn't run under use strict
• People who are running applications that don't run under use strict (they are either old, or poorly written), and decide to upgrade their version of Perl without doing any testing.

It seems to me there are simple solutions for both groups (either don't upgrade, or turn off strict).

Do we really want to protect these groups to the detriment of everyone else?

Build a language aimed at newbies, and only newbies will use your language.

It's a LOT more than the price of a few keystrokes... it's the whole culture of Perl. 99% of people that start coding in perl aren't even going to know that 'use strict' exists, and will end up creating sloppy code (ever noticed that Perl has a reputation for being messy - this is exactly why).

And as I said above, backwards compatability issues can be resolved in a number of ways....

"...people that start coding in perl aren't even going to know that 'use strict' exists, and will end up creating sloppy code"

This seems to be true for much of the code I end up inheriting. Whenever I am given code, two tasks are created:

1. Add use strict;
2. Run perltidy, specifically "perltidy -nolq -pt=0 -bbb -bl"

And as I said above, backwards compatability issues can be resolved in a number of ways....

You suggestion is unacceptable. You want strictures on by default, alias /usr/bin/perl to /usr/bin/perl -Mstrict

99% of people that start coding in perl aren't even going to know that 'use strict' exists

That sounds like a failure of introductory material and instructors, not one of the language itself.

Makeshifts last the longest.

So, you don't like the culture of Perl and you want to change it? You want to change the way 99% of the people are coding Perl? You think this is good for the language or its culture? Enlighten us, please!

AM sits back with some popcorn, awaiting a show with lots of unfounded statistics

I tried doing this before, and there's a thread about it on PM somewhere. Many times in code, you might see strict without warnings or vice versa. So sometimes it might make sense to combine both.

I think combining warnings and strict into one package, let's call it "caution", would help. Then we could "use caution".

I proposed exactly this years ago. I even registered the ex::caution namespace and put together an implementation. It wasnt particularly well received when I first brought it up, but maybe its worth returning to. Perl has moved on from then quite a bit.



---
demerphq


First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi

Flux8

to "Perl isn't a B&D language", but who or what would be inconvenienced if it were?

If you are asking "who or what would be inconvienced if Perl was a B&D language", the answer is EVERYONE!

"who or what would be inconvienced if Perl was a B&D language"

I didn't ask that...and your preaching to the converted. :)

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

Why I would do this? I like database-definition files. Executed by sh they create a database. Required they give a connection to that database. Or what about a maintainancescript that works whatever interpreter is installed?