in reply to Why isn't C<use strict> the default?

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:

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.

Makeshifts last the longest.

Replies are listed 'Best First'.
Re^2: Why isn't C<use strict> the default?
by BrowserUk (Patriarch) on Oct 29, 2004 at 09:36 UTC

    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
[reply]
[d/l]

      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.

[reply]
[d/l]

        As I said elsewhere, but originally noted by demerphq, -e would be exempt. I don't follow you with regard to modules. As far as I am concerned, the only package that would be affected is main. People who right modules are well able to decide whether the code inside requires stric or not.

        Which funnily enough is exactly the reverse of the proposal for P6--which confuses the beggebers(sp? (I don't care:)) out of me. :?

        It's the guy writing his first few perl scripts that you want to catch.

        As for the those modifying scripts downloaded from the web, if the code screamed a stream of "It's broken" at them, they would probably either scream back at the author or decide that it was a crap download and look elsewhere. Who knows, it might even improve a few notorious artifacts.

        I agree about the inherent global nature of much of the internals, but these are much less of a problem than users setting out writing code that uses globals to pass data between subroutines, symbolic references and a mess of similar constructs that are a pain to undo once a tentatively working script needs to grow with the expectations and aspirations.

        Anyway, this has all got really rather deeper than I ever intended when I first posted my late night "I wonder why that is?" question.

        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
[reply]
[d/l]
      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.

[reply]
Re^2: Why isn't C<use strict> the default?
by Mutant (Priest) on Oct 29, 2004 at 14:46 UTC
    I'm happy enough to wait until P6 for strictures to be (more or less) default... there's certainly no backwards compatability issue here...
[reply]

In Section Meditations