http://www.perlmonks.org?node_id=125961


in reply to Re: Paradigm Shift - Don't use strict
in thread Paradigm Shift - Don't use strict

Just a few comments.

First of all I agree with you on the importance of making your own mind up. I have made similar points in the past, and on several occasions managed to irritate people by refusing to accept the received wisdom. But I think I learn better for it.

That said, there are a few points about your own behaviour that I would like to point out.

Which brings me to my biggest single comment. The average business has a huge concern known as, "What do we do if ___ gets hit by a bus tomorrow?" This is irritating for any decent programmer, we don't want to feel replacable. (Though a tip for bystanders, make yourself replacable and they are freer to put you into new, more interesting, roles.) Well you are not currently coding for a company that can ask that question, but for the sake of Perl, I hope you look both ways before you cross the street...

Replies are listed 'Best First'.
Re: Re (tilly) 2: Paradigm Shift - Don't use strict
by TheDamian (Vicar) on Nov 18, 2001 at 06:11 UTC
    Contrary to appearances, you do attempt sanity and caution.
    Well..."caution" at least. ;-)

    ...when you write more routine programs, I suspect you use fewer typeglobs and symbolic references.
    Probably so. Though I suspect that, even in those cases, I'm more partial to typeglobbing a closure than most folks would be.

    If you count documentation as commenting...then you do indeed have verbose comments.
    Hmmm. Not sure that counts in the sense I meant. I rarely document how the code works.

    Polymorphism is the one issue I disagree with you on.
    Well, thank goodness we differ somewhere! I think the point is that, unlike a member of a project coding team, I write code that (I hope) will be used by thousands of people around the world. That promotes TMTOWTDI to a prime design criterion and makes it essential to provide a range of interfaces that cater to a vast diversity of coding prejudices styles.

    for the sake of Perl, I hope you look both ways before you cross the street...
    Yes. I do try to keep myself available to support what I've contributed. ;-)

    Though, as my count of CPAN modules climbs towards the 30's (by the end of this year), it's becoming increasing difficult to maintain them all in a timely fashion. ;-(

    And things will probably get even worse next year. YAS is about to announce a funding drive to extend my Year For Perl into 2002 (and to sponsor another one or two Perl Serfs as well!) But, with so many Perl people hurting financially in the tech downturn, I'm concerned that indentured servants are a luxury the Perl community can no longer afford.

    So many people were so very generous in funding the work I've done this year, and I hope they felt that their contributions were well spent. But even if they do, that doesn't mean they'll still be in a position to extend that generosity this time round. Corporate donations may take up some of the short-fall, but I'm readying myself to have to cut back on my Perl work, in order to earn a living in 2002.

    Of course, I may be completely mistaken about that, and we'll raise the money as easily as we did last year. I hope that's the case. But even then, things will still get worse: I'll continue to churn out new modules at about the same rate, and therefore have to dice my maintenance timeslices even more thinly. ;-)

      Well..."caution" at least. ;-)

      This reminds me of something which Id like to make as an informal feature request for Perl 6. I had an idea ages ago (even wrote a prototype) for a pragma called

      use caution;
      My idea was simply to roll together use warnings and use strict into one easy to type pragma. When I brought it up on C.L.P.M people also mentioned that it maybe should include other options, like perhaps taint and diagnostics.

      Maybe its a silly idea, but I alwas thought it would be cool to have the words 'use caution;' at the top of a program. :-)

      Yves / DeMerphq
      --
      Have you registered your Name Space?

      mmm. Not sure that counts in the sense I meant. I rarely document how the code works.

      I've started to write code that I don't document, in terms of how the code works. When I started to do that, I was uncomfortable, because I was breaking a Rule. Then, I realized it's because the only people who would understand the algorithms and subversions of Perl that I was doing were the very same people who understand why the Rule was broken.

      As a Perl hacker I knew once commented ...

      # Here be black magic!

      And that was all he wrote before the line noise.

      ------
      We are the carpenters and bricklayers of the Information Age.

      Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

      I shouldn't have to say this, but any code, unless otherwise stated, is untested

(Ovid) Re: Re (tilly) 2: Paradigm Shift - Don't use strict
by Ovid (Cardinal) on Nov 17, 2001 at 04:51 UTC

    tilly wrote:

    I think the key-word about goto is well-placed.

    Just out of curiosity, what do you consider well-placed? The only time I have ever used goto is to subvert the call stack. And I did that once.

    You've mentioned before that goto has uses. Other than this Perl-specific reason, what else would you use it for?

    Cheers,
    Ovid

    Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

      To understand how to use goto, you need to understand why not to use it. And the best place to start with that is by reading Go To Statement Considered Harmful. If you read the classic paper that started the debate, you will find that the fundamental objection to goto is that it leads to control structures that are hard for people to model.

      Therefore it follows that the only kind of goto which you should want to use is a goto which helps the program fit into control structures that people can understand. If, of course, there are alternate commands which can redirect flow you should want to use them instead. They document intent more clearly. But it is occasionally true that the best way to do things is a goto.

      Knuth offered a number of examples in a paper I have not found online. However based on a variety of comments I have seen about it, it seems that the majority of his cases are addressed with having multiple exits from functions, and with Perl's loop control statements. In languages with single function exits and without loop control statements, you can reasonably reach for them with a goto. In Perl, as noted in perlsyn, you would be far better off reaching for loop control statements instead. Be warned, even so you will find that there is a debate on the advisability of internal loop exits. My position on this is shaped by Loop Exits and Structured Programming: Reopening the Debate.

      Another example mentioned in the original paper is exception programming. I have seen goto used this way in both VB and Perl. Trust me. Doing your exception programming with die/eval or some other specific exception handler is far preferable to using goto for this purpose. But that is a use you will occasionally run into.

      Given those extra control structures, it is rare to want a goto in Perl. You have stated one, subverting the stack. Eg to fool Exporter's caller. Or trying to get tail-recursion to work. A second would be if you were trying to create your own control structure. For instance that was the problem that TheDamian faced in Switch. His control of flow problem didn't fit with any loop control statements, it almost did but not quite. So he used an amazing goto to get what he wanted. Another example might be that you could use gotos to make state transitions for a finite state machine. (Hopefully the ugliness would be hidden behind some code autogeneration.) The goto is not problematic because it enables you to work within a good structure for the rest of the program.

      I have not personally ever felt the desire to (other than in deliberate experimentation) use a goto in Perl for anything other than subverting the stack. However I remain aware that I could, and I would do it without hesitation if I thought the situation warranted it. I also doubt I will ever encounter such a situation, but I think I could likely spot it if I did...

      UPDATE
      Knuth's reponse is at Structured Programming with go to Statements. (PDF scan of a print article. Acceptable quality.) Thanks to hsmyers for pointing it out at Re: Would you use 'goto' here?.

        I concur with everything tilly said above. To summarize, a goto is not considered harmful when you're:
        • replacing the current subroutine via a goto &othersub (rare),
        • autogenerating code that will never be seen or maintained directly (rarer),
        • implementing a flow-of-control that Perl doesn't support natively (rarest).

        For me, the key point in tilly's reply is that virtually all other "legitimate" uses of a goto in other languages are made redundant in Perl by the availability of named loops.

        Whereas in C/C++ you might reasonably have to write:

        for (i=1; i<10; i++) { for (j=1; j<10; j++) { for (k=1; k<10; k++) { /* Process data[i][j][k] here */ if (data[i][j][k] < threshold) goto EOLOOPS; } } } EOLOOPS:
        Perl has a much cleaner way to escape from a deep nesting:
        LOOPS: for $i (1..10) { for $j (1..10) { for $k (1..10) { # Process $data[$i][$j][$k] here last LOOPS if $data[$i][$j][$k] < $threshold; } } }
        Long ago, before I discovered the Way of the Camel, I used to rely on a couple of moderately evil preprocessor commands to give myself named loops in C/C++ too:
        #define named(name) goto name; name##_break: if (0) name: #define break(name) goto name##_break; /* Which then allows you to write... */ named (LOOPS) for (i=1; i<10; i++) { for (j=1; j<10; j++) { for (j=1; j<10; j++) { /* Process data[i][j][k] here */ if (data[i][j][k] < threshold) break(LOOPS); } } }
        Exploring how those #defines work -- and why they don't interfere with the semantics of normal (unnamed) break statements -- is left as an exercise for those of you who still follow the Dark Path. ;-)