[30134] in Perl-Users-Digest
Perl-Users Digest, Issue: 1377 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Mar 20 14:14:27 2008
Date: Thu, 20 Mar 2008 11:14:20 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 20 Mar 2008 Volume: 11 Number: 1377
Today's topics:
strategys other than subroutine and OO? <ela@yantai.org>
Re: strategys other than subroutine and OO? <RedGrittyBrick@SpamWeary.foo>
Re: strategys other than subroutine and OO? <joost@zeekat.nl>
Re: strategys other than subroutine and OO? <willem@stack.nl>
Re: strategys other than subroutine and OO? <abigail@abigail.be>
Re: strategys other than subroutine and OO? <cartercc@gmail.com>
Re: strategys other than subroutine and OO? <joost@zeekat.nl>
Re: strategys other than subroutine and OO? <ela@yantai.org>
Re: strategys other than subroutine and OO? <cartercc@gmail.com>
Re: strategys other than subroutine and OO? <cartercc@gmail.com>
Re: strategys other than subroutine and OO? <RedGrittyBrick@SpamWeary.foo>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 20 Mar 2008 19:34:31 +0800
From: "Ela" <ela@yantai.org>
Subject: strategys other than subroutine and OO?
Message-Id: <frti4b$cbf$1@ijustice.itsc.cuhk.edu.hk>
I have 300 lines of codes that are used roughly twice. Some of the lines
have delicate difference in execution (e.g. ~6 variables have to be replaced
and conditional statements are also different) and therefore many arguments
need to be passed into it in order to differentiate the execution parts. OO
development is analogously also difficult. I wonder if there is any good way
to reuse the codes, e.g. some sort of "goto" rather than duplicating these
lines. Whenever there is any change, I find that is really error-prone.
------------------------------
Date: Thu, 20 Mar 2008 12:07:12 +0000
From: RedGrittyBrick <RedGrittyBrick@SpamWeary.foo>
Subject: Re: strategys other than subroutine and OO?
Message-Id: <47e25374$0$32043$da0feed9@news.zen.co.uk>
Ela wrote:
> I have 300 lines of codes that are used roughly twice. Some of the lines
> have delicate difference in execution (e.g. ~6 variables have to be replaced
> and conditional statements are also different) and therefore many arguments
> need to be passed into it in order to differentiate the execution parts. OO
> development is analogously also difficult. I wonder if there is any good way
> to reuse the codes,
There are good ways and there are easy ways. Choose good.
> e.g. some sort of "goto" rather than duplicating these
> lines. Whenever there is any change, I find that is really error-prone.
"For a number of years I have been familiar with the observation that
the quality of programmers is a decreasing function of the density of go
to statements in the programs they produce. More recently I discovered
why the use of the go to statement has such disastrous effects, and I
became convinced that the go to statement should be abolished from all
"higher level" programming languages (i.e. everything except, perhaps,
plain machine code). At that time I did not attach too much importance
to this discovery; I now submit my considerations for publication
because in very recent discussions in which the subject turned up, I
have been urged to do so."
Edager W. Dijkstra. Go To Statement Considered Harmful. 1968.
In nearly 30 years of programming I have completely avoided use of GOTO
in a professional context. All I have seen continues to convince me that
Dijkstra was right on this matter. YMMV.
--
RGB
------------------------------
Date: Thu, 20 Mar 2008 13:20:29 +0100
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: strategys other than subroutine and OO?
Message-Id: <87eja560z6.fsf@zeekat.nl>
"Ela" <ela@yantai.org> writes:
> I have 300 lines of codes that are used roughly twice. Some of the lines
> have delicate difference in execution (e.g. ~6 variables have to be replaced
> and conditional statements are also different) and therefore many arguments
> need to be passed into it in order to differentiate the execution parts. OO
> development is analogously also difficult. I wonder if there is any good way
> to reuse the codes, e.g. some sort of "goto" rather than duplicating these
> lines. Whenever there is any change, I find that is really error-prone.
Sounds like using closures/passing functions as arguments could be very
helpful here, but without seeing your code it's impossible to be sure.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: Thu, 20 Mar 2008 12:22:34 +0000 (UTC)
From: Willem <willem@stack.nl>
Subject: Re: strategys other than subroutine and OO?
Message-Id: <slrnfu4loa.av8.willem@snail.stack.nl>
Ela wrote:
) I have 300 lines of codes that are used roughly twice. Some of the lines
) have delicate difference in execution (e.g. ~6 variables have to be replaced
) and conditional statements are also different) and therefore many arguments
) need to be passed into it in order to differentiate the execution parts. OO
) development is analogously also difficult. I wonder if there is any good way
) to reuse the codes, e.g. some sort of "goto" rather than duplicating these
) lines. Whenever there is any change, I find that is really error-prone.
Maybe you can take the lines that are exactly duplicated and put those
into sub functions. If you define the sub functions inside the main
function they can access the main function's 'my' variables, so you
don't need to pass them as arguments.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: 20 Mar 2008 14:40:12 GMT
From: Abigail <abigail@abigail.be>
Subject: Re: strategys other than subroutine and OO?
Message-Id: <slrnfu4tqc.n25.abigail@alexandra.abigail.be>
_
RedGrittyBrick (RedGrittyBrick@SpamWeary.foo) wrote on VCCCXV September
MCMXCIII in <URL:news:47e25374$0$32043$da0feed9@news.zen.co.uk>:
::
:: "For a number of years I have been familiar with the observation that
:: the quality of programmers is a decreasing function of the density of go
:: to statements in the programs they produce. More recently I discovered
:: why the use of the go to statement has such disastrous effects, and I
:: became convinced that the go to statement should be abolished from all
:: "higher level" programming languages (i.e. everything except, perhaps,
:: plain machine code). At that time I did not attach too much importance
:: to this discovery; I now submit my considerations for publication
:: because in very recent discussions in which the subject turned up, I
:: have been urged to do so."
::
:: Edager W. Dijkstra. Go To Statement Considered Harmful. 1968.
::
::
::
:: In nearly 30 years of programming I have completely avoided use of GOTO
:: in a professional context. All I have seen continues to convince me that
:: Dijkstra was right on this matter. YMMV.
Dijkstra also wrote:
"Please don't fall into the trap of believing that I am terribly
dogmatic about [the goto statement]. I have the uncomfortable
feeling that others are making a religion out of it, as if the
conceptual problems of programming could be solved by a simple
trick, by a simple form of coding disciple!"
Edsger W. Dijkstra, personal communication, 1973.
Quoted by Donald E. Knuth, "Structured Programming with the go to
Statement", 1974.
What Knuth and Dijkstra are saying is that it's not so much the use of
"goto" that should be avoided, the real horror is unstructured programming.
But most people only know the title of Dijkstra's paper, and not the
content [1], let alone know what others have to say about it.
I'm not afraid to confess I do use goto. I prefer:
again:
my $result = do_something;
goto again if it_failed;
over
my $result;
my $success = 0;
until ($success) {
$result = do_something;
$success = 1 unless it_failed;
}
[1] This little, innocent, article was intended to explain a phenomenon
I thought most of us knew. Instead, it evoked a violent storm that
raged for more than a decade. This was the last thing I had expected,
and I still don't quite understand the violence of the emotions,
which have blurred the vision of many: when my "Notes on Structured
Programming" appeared a few years later, many believed that that
was primarily about avoiding of eliminating GOTO statements.
I have also been blamed for its title, which became a template
for many titles of the form "X considered harmful" (among them even
"Dijkstra considered harmful"), but this blame is misplaced. I
had submitted my article under the name "A case against the GOTO
statement", but thee editor I mailed it to, Dr. Niklaus Wirth,
wanted to speed up its publication, which he could do by turning
it into a Letter-to-the-Editor; in the process he gave it the title
that became a template.
Edsger W. Dijkstra about "Go To Statements Considered Harmful",
October 1993, in Phillip Laplante (ed): "Great Papers in Computer
Science", 1996.
Abigail
--
perl -wle'print"Κυστ αξοτθες Πεςμ Θαγλες"^"\x80"x24'
------------------------------
Date: Thu, 20 Mar 2008 07:55:53 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: strategys other than subroutine and OO?
Message-Id: <87cfaa1d-f0bb-4423-a35f-a34fd7d7efe0@a23g2000hsc.googlegroups.com>
On Mar 20, 7:34 am, "Ela" <e...@yantai.org> wrote:
> I have 300 lines of codes that are used roughly twice. Some of the lines
> have delicate difference in execution (e.g. ~6 variables have to be replaced
> and conditional statements are also different) and therefore many arguments
> need to be passed into it in order to differentiate the execution parts. OO
> development is analogously also difficult. I wonder if there is any good way
> to reuse the codes, e.g. some sort of "goto" rather than duplicating these
> lines. Whenever there is any change, I find that is really error-prone.
I have a suggestion. Since you didn't post a coding sample, my
suggestion may not be appropros, but maybe it will.
First, you surely don't have a function that is 300 lines long. If you
do, I don't think I can help. You probably have batches of lines that
are duplicated. The first thing I would do is abstract these batches
of lines into separate functions and call them separately, like this:
&batch_a;
&batch_b;
&batch_c;
sub batch_a { #first batch of lines
}
sub batch_b { #second batch of lines
}
sub batch_c { #third batch of lines
}
Second, you can pass different parameters into these functions to
account for the different variables. If you need to set a variable as
a result of some behavior, set the variable by calling a function,
like this:
$var = &setvar;
sub setvar { #code here sets a var which you would return
return $var; }
Third, you can replace your conditional statements with booleans and
set them outside the function call, like this:
my $conditional = 0
$conditional = 1 if &some_function_that_returns_true;
$contitional = 0 unless &some_function_that_returns_true;
if ($conditional) { #code to execute
}
Fourth, if possible, place your common code (our variables and
functions) in a PM and import the backage. This way, you can separate
the interface and the functionality, and this will also allow you to
refactor your code if and when you have the time to do so. You don't
need to create classes and objects to do this.
Fifth, as a strength building exercise, you might attempt to place ALL
your code, every line of it, in user defined functions and execute the
program by the judicious call of these functions. Of course, you would
still need to declare your lexical variables, but you set them by
function calls.
CC
------------------------------
Date: Thu, 20 Mar 2008 16:10:53 +0100
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: strategys other than subroutine and OO?
Message-Id: <874pb15t36.fsf@zeekat.nl>
ccc31807 <cartercc@gmail.com> writes:
> &batch_a;
> &batch_b;
> &batch_c;
Erm, you *do* know what that does, right? In most circumstances you want
to use
batch_a();
batch_b();
batch_c();
instead.
See perlfaq7
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: Thu, 20 Mar 2008 23:30:18 +0800
From: "Ela" <ela@yantai.org>
Subject: Re: strategys other than subroutine and OO?
Message-Id: <frtvuf$ic5$1@ijustice.itsc.cuhk.edu.hk>
> Fourth, if possible, place your common code (our variables and
> functions) in a PM and import the backage. This way, you can separate
> the interface and the functionality, and this will also allow you to
> refactor your code if and when you have the time to do so. You don't
> need to create classes and objects to do this.
>
> Fifth, as a strength building exercise, you might attempt to place ALL
> your code, every line of it, in user defined functions and execute the
> program by the judicious call of these functions. Of course, you would
> still need to declare your lexical variables, but you set them by
> function calls.
>
> CC
I don't quite understand the last 2. Maybe I need to refer to some Advanced
Perl Programming? Anyway I guess your first 3 suggestions should be
sufficient to solve the headache-causing clumsy coding problem. Thank you
and all others' help!
------------------------------
Date: Thu, 20 Mar 2008 08:41:19 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: strategys other than subroutine and OO?
Message-Id: <c2ecf7e6-9da8-45cb-8848-fac2015fe21d@d62g2000hsf.googlegroups.com>
On Mar 20, 11:10 am, Joost Diepenmaat <jo...@zeekat.nl>
> Erm, you *do* know what that does, right?
I know exactly what calling a function using & does. As I understand
it, it uses your programs underscore varibles.
> In most circumstances you want
> to use
>
> batch_a();
> batch_b();
> batch_c();
I'm sorry if what I posted was confusing. Yes, you are correct, and I
certainly did not want to mislead anyone. However, I certainly wasn't
misled when I wrote what I did and didn't think that anyone else would
be, either. In any case, you can call a function clearly and
ambiguously using &. And I just prefer to do so. TIMTOWTDI.
CC
------------------------------
Date: Thu, 20 Mar 2008 08:55:15 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: strategys other than subroutine and OO?
Message-Id: <bbfdab10-ec6b-4136-b028-b4c611ed9301@n58g2000hsf.googlegroups.com>
On Mar 20, 11:30 am, "Ela" <e...@yantai.org> wrote:
> > Fifth, as a strength building exercise, you might attempt to place ALL
> > your code, every line of it, in user defined functions and execute the
> > program by the judicious call of these functions. Of course, you would
> > still need to declare your lexical variables, but you set them by
> > function calls.
> I don't quite understand the last 2.
1. Please note that I may have misled you by suggesting that you call
your functions using &. While you can certainly do that, ommitting the
& and using the () will probably suit you better, at least until you
get a handle on your personal preference and scripting needs.
2. I strongly suggest you understand the last point. What I mean is
that the body of your script contain only comments, variable
declarations, and function calls. Your functionality is abstracted to
your subroutines. This promotes clarity and modularity, and can help
tremendously with debugging. It separates your logic from your
behavior so you can think about your program logic without considering
implementation. When you write your functions, you don't have to think
about your logic.
I frequently find myself writing the logic in pseudo code as comments,
writing subroutines that implement peices of the logic, and adding the
call to the main script using the pseudo comments as documentation.
This isn't a good way to write big applications, but it is a good way
to develop small to moderate size scripts.
CC
------------------------------
Date: Thu, 20 Mar 2008 16:12:05 +0000
From: RedGrittyBrick <RedGrittyBrick@SpamWeary.foo>
Subject: Re: strategys other than subroutine and OO?
Message-Id: <47e28cd5$0$10628$fa0fcedb@news.zen.co.uk>
Abigail wrote:
> _
> RedGrittyBrick wrote:
> ::
<snip>
> ::
> :: Edager W. Dijkstra. Go To Statement Considered Harmful. 1968.
> ::
> :: In nearly 30 years of programming I have completely avoided use of GOTO
> :: in a professional context. All I have seen continues to convince me that
> :: Dijkstra was right on this matter. YMMV.
>
> Dijkstra also wrote:
>
> "Please don't fall into the trap of believing that I am terribly
> dogmatic about [the goto statement]. I have the uncomfortable
> feeling that others are making a religion out of it, as if the
> conceptual problems of programming could be solved by a simple
> trick, by a simple form of coding disciple!"
>
> Edsger W. Dijkstra, personal communication, 1973.
> Quoted by Donald E. Knuth, "Structured Programming with the go to
> Statement", 1974.
>
> What Knuth and Dijkstra are saying is that it's not so much the use of
> "goto" that should be avoided, the real horror is unstructured programming.
> But most people only know the title of Dijkstra's paper, and not the
> content [1], let alone know what others have to say about it.
Guilty as charged. Perhaps I am unlucky in that almost all the examples
of GOTO I have had to wrestle with, have been in examples of "spaghetti
programming". It is certainly possible to write spaghetti code without
using GOTO, but use of GOTO seems to encourage this trend in many
programmers.
>
>
> I'm not afraid to confess I do use goto. I prefer:
>
> again:
> my $result = do_something;
> goto again if it_failed;
>
> over
>
> my $result;
> my $success = 0;
> until ($success) {
> $result = do_something;
> $success = 1 unless it_failed;
> }
OK. I don't prefer the former, but I see your point.
However, in this case do_something is three hundred lines, I hope you'd
consider putting it into a subroutine do_something() - or perhaps
re-factoring into several subroutines. The OP is looking for an
"alternative strategy" that doesn't involve subroutines. The OP appears
to be hoping that using GOTO will avoid the perceived difficulty of
reorganising code into well-formed subroutines or objects and methods.
I infer the OP prefers
...
<stuff>
...
<perhaps hundreds of lines of intervening code>
...
<similar stuff>
...
to be transformed into something like
...
my second_time = 0;
stuff:
<stuff probably containing many IFs / GOTOs for dissimilar bits>
if (second_time) goto continuation
...
<perhaps hundreds of lines of intervening code>
...
second_time = 1;
goto stuff:
continuation:
...
instead of
...
stuff("foo", ...);
...
<perhaps hundreds of lines of intervening code>
...
stuff("bar", ...);
...
sub stuff {
<various stuff>
}
I still feel that re-factoring unwieldy and repetitive code into
subroutines (or objects and methods) is a more useful skill to learn
than how to sprinkle GOTO statements into that unwieldy code.
--
RGB
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 1377
***************************************
