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. ;-)
| [reply] [Watch: Dir/Any] |
|
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? | [reply] [Watch: Dir/Any] [d/l] |
|
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
| [reply] [Watch: Dir/Any] [d/l] |
(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.
| [reply] [Watch: Dir/Any] |
|
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?.
| [reply] [Watch: Dir/Any] |
|
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. ;-) | [reply] [Watch: Dir/Any] [d/l] [select] |
|
|