[32727] in Perl-Users-Digest
Perl-Users Digest, Issue: 3991 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jul 15 18:09:31 2013
Date: Mon, 15 Jul 2013 15:09:04 -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 Mon, 15 Jul 2013 Volume: 11 Number: 3991
Today's topics:
Re: [OT] scoping <ben@morrow.me.uk>
Re: [OT] scoping <ben@morrow.me.uk>
Re: the fastest way to create a directory <news@lawshouse.org>
Re: the fastest way to create a directory <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Re: the fastest way to create a directory <cwilbur@chromatico.net>
Re: the fastest way to create a directory (Tim McDaniel)
Re: the fastest way to create a directory <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Re: the fastest way to create a directory <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Re: the fastest way to create a directory <hjp-usenet3@hjp.at>
Re: the fastest way to create a directory <hjp-usenet3@hjp.at>
Re: this should work <ben@morrow.me.uk>
Re: this should work <rweikusat@mssgmbh.com>
Re: this should work (Tim McDaniel)
Re: this should work <ben@morrow.me.uk>
Re: this should work <cwilbur@chromatico.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 15 Jul 2013 14:12:44 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: [OT] scoping
Message-Id: <c39dba-9591.ln1@anubis.morrow.me.uk>
Quoth Xho Jingleheimerschmidt <xhoster@gmail.com>:
> On 07/14/13 14:21, Ben Morrow wrote:
> >
> > Fair enough. I'm surprised that's the case, but you've obviously tested
> > it with your database driver. I generally use Pg, and I'm reasonably
> > certain (I haven't benchmarked it) that the most efficient way to write
> > that statement would be with a single placeholder that gets bound to an
> > arrayref (which is then sent to the database as a Pg array), but
> > presumably that isn't the case in your situation.
>
> Oooh, cool. I'll have to try that. This seems to the defy the docs of
> DBI itself, so I'd never considered the possibility.
DBI hands most of this sort of thing straight off to the DBD, so those
docs are usually more important.
Unfortunately I've just checked the code and the DBD::Pg docs are indeed
literally correct that the arrayref is stringified into a Pg array
literal before being sent to the database. This is a shame, given than
Pg has a binary interface; I suppose the problem is that it's
underdocumented and doesn't have any library support.
> Any neat tips for making this annoying mess less of an annoying mess?
>
> 'UPDATE foo set (bar, baz, bxw, snaz1, snaz2, snaz3, snaz4,snaz5) =
> ($2,$3,$4,$5,$6,$7,$8,$7+$8) where pkey=$1'
Generate it? But you knew that...
No, sorry, though I'm not quite sure what sort of tidying up you thought
might be possible.
Ben
------------------------------
Date: Mon, 15 Jul 2013 14:27:01 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: [OT] scoping
Message-Id: <5u9dba-9591.ln1@anubis.morrow.me.uk>
Quoth Xho Jingleheimerschmidt <xhoster@gmail.com>:
> On 07/14/13 05:13, Ben Morrow wrote:
> > Quoth "Dr.Ruud" <rvtol+usenet@xs4all.nl>:
> >
> >> local $" = q{,};
> >>
> >> qq{
> >> SELECT
> >> $columns_csv
> >> FROM
> >> $table
> >> WHERE
> >> id IN (@ids) -- hundreds easily
> >
> > Please, someone tell your cow-orkers about placeholders...
>
> ...which alas don't work well with IN-lists, or column names, or table
> names.
I've never had a problem with IN-lists, which are just lists of values.
Column and table names, yes.
> >> The worst are the do-blocks of many hundreds of lines.
> >> They tend to keep growing, and prove hard to get rid of.
> >
> > Um, just turn 'em into subs. (Of course, a sub of hundreds of lines
> > isn't much better, but then you can start breaking it up into sensible
> > pieces.)
>
> I'd much rather read one sub with hundreds of lines, than 49 individual
> subs each of 10 lines, each only used once, in a linear fashion from one
> meta-sub.
Really? I strongly disagree. The meta-sub, assuming the sub names have
been chosen sensibly, gives a useful overview of the algorithm the rest
implement, and the use of variables in the meta-sub shows how data flows
from one part of the algorithm to another.
> You should create subs when they encapsulate a nicely self-contained
> re-usable nugget, not because the line count achieved a certain value.
To my mind 'self-contained' is more important than 'reusable', or at
least more important than 'actually going to be reused immediately'.
Except under special circumstances, a sub of hundreds of lines is very
unlikely to be a self-contained unit doing a simple, well-understood
job. Even the exceptions, which generally run along the lines of 'a big
switch', should probably be rewritten to be data-driven.
Obviously I am not saying you should split a sub into 'foo1' and 'foo2'
just because 'foo' got too long. I am saying I believe that if you look
carefully at a sub of that size it will have natural 'paragraphs' within
it, which could be split out into subs with sensible names and
well-defined jobs.
Ben
------------------------------
Date: Mon, 15 Jul 2013 15:44:27 +0100
From: Henry Law <news@lawshouse.org>
Subject: Re: the fastest way to create a directory
Message-Id: <ALidncZ13phWl3nMnZ2dnUVZ8nudnZ2d@giganews.com>
On 15/07/13 12:09, George Mpouras wrote:
> Create a directory with all upper directories if missing.
Use File::Path.
--
Henry Law Manchester, England
------------------------------
Date: Mon, 15 Jul 2013 18:45:05 +0300
From: "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Subject: Re: the fastest way to create a directory
Message-Id: <ks15e6$1l8p$1@news.ntua.gr>
Ο "Henry Law" έγραψε στο μήνυμα
news:ALidncZ13phWl3nMnZ2dnUVZ8nudnZ2d@giganews.com...
On 15/07/13 12:09, George Mpouras wrote:
> Create a directory with all upper directories if missing.
Use File::Path.
no it is slow
------------------------------
Date: Mon, 15 Jul 2013 15:36:05 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: the fastest way to create a directory
Message-Id: <87oba3fwey.fsf@new.chromatico.net>
>>>>> "GM" == George Mpouras
>>>>> <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
>>>>> writes:
GM> Ο "Henry Law" έγραψε στο μήνυμα
GM> news:ALidncZ13phWl3nMnZ2dnUVZ8nudnZ2d@giganews.com...
GM> On 15/07/13 12:09, George Mpouras wrote:
>> Create a directory with all upper directories if missing.
GM> Use File::Path.
GM> no it is slow
If you create so many directories that the execution time of File::Path
is greater than the debugging time of roll-your-own code, Perl is
probably the wrong langauge for the task.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Mon, 15 Jul 2013 20:27:11 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: the fastest way to create a directory
Message-Id: <ks1luv$415$1@reader2.panix.com>
In article <ks0l7j$9j4$1@news.ntua.gr>,
George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com> wrote:
>Create a directory with all upper directories if missing.
On Linux-like systems,
system("mkdir", "-p", $dir);
Unless you're creating millions of directories per day, doing it with
a known way is far faster and far more reliable than trying to code
your own.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Tue, 16 Jul 2013 00:04:06 +0300
From: "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Subject: Re: the fastest way to create a directory
Message-Id: <ks1o4c$5jj$1@news.ntua.gr>
yes there are about thousands dirs. try to undestand the code. looks simple
but it is not
------------------------------
Date: Tue, 16 Jul 2013 00:07:54 +0300
From: "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam>
Subject: Re: the fastest way to create a directory
Message-Id: <ks1obg$64m$1@news.ntua.gr>
I have found that usingn Perl with clever code you can be faster than the
usual c
of cource if you write the same code with C it will be faster but then, the
deadlines will pass !
------------------------------
Date: Mon, 15 Jul 2013 23:55:01 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: the fastest way to create a directory
Message-Id: <slrnku8rto.gkv.hjp-usenet3@hrunkner.hjp.at>
On 2013-07-15 15:45, George Mpouras <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam> wrote:
> Ο "Henry Law" έγραψε στο μήνυμα
> news:ALidncZ13phWl3nMnZ2dnUVZ8nudnZ2d@giganews.com...
>
> On 15/07/13 12:09, George Mpouras wrote:
>> Create a directory with all upper directories if missing.
>
> Use File::Path.
>
>
> no it is slow
On my system it is exactly as fast as your version, creating 2*70644
directories.
Here is the test program:
#!/usr/bin/perl
use warnings;
use strict;
use File::Path qw(make_path);
use Time::HiRes qw(time);
$| = 1;
my $n = $ARGV[0];
{
my $t0 = time;
for my $i (0 .. $n) {
for my $j (0 .. $n) {
for my $k (0 .. $n) {
make_path("t1/$i/$j/$k");
}
}
printf("%3d %9.6f\n", $i, time - $t0);
}
}
{
my $t0 = time;
for my $i (0 .. $n) {
for my $j (0 .. $n) {
for my $k (0 .. $n) {
make_path("t2/$k/$j/$i");
}
}
printf("%3d %9.6f\n", $i, time - $t0);
}
}
__END__
(second test program uses your Mkdir_recursive instead of make_path)
With $n = 40, The first loop takes about 20 seconds, the second about 24
seconds for both programs. As expected, they are completely disk-bound.
strace shows that they are also performing essentially the same system
calls.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Tue, 16 Jul 2013 00:02:00 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: the fastest way to create a directory
Message-Id: <slrnku8saq.gkv.hjp-usenet3@hrunkner.hjp.at>
On 2013-07-15 21:04, George Mpouras <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam> wrote:
> yes there are about thousands dirs. try to undestand the code. looks
> simple but it is not
What? It's trivial. It also has a bug: It doesn't perform silently under
use warnings. Ok, so maybe it isn't trivial after all ...
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpat. -- Ralph Babel
------------------------------
Date: Mon, 15 Jul 2013 14:07:32 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: this should work
Message-Id: <kp8dba-9591.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
>
> > A variable is just a way of giving a value a name;
>
> This is true for so-called 'functional programming languages' but Perl
> isn't one: There, a 'variable' is something like a deposit box
> (term?): A container which can be used to store 'stuff' of a certain
> kind (depending on the type of box) until it is again needed which can
> be 'addressed' in a convenient way (usually, by using an abstract name
> referring to the 'function' of this variable).
How is that different from 'just a way of giving a value a name'?
> > The whole point of lexical variables is to avoid the problems that
> > occur when uncontrolled and implicit data leakage occurs between
> > different parts of the program; having Perl ensure that values we no
> > longer need are properly disposed of as soon as possible is just
> > common sense.
> >
> > (And, again, this is not about efficiency, either of CPU or memory. It's
> > about making the code comprehensible.)
>
> IMO, it is about making the code incomprehensible for the sake of
> 'efficiency', namely, to avoid the dreaded, mythological function call
> overhead, by cramming as many different algorithms into a single run
> of sequential code as seems remotely feasible instead of giving
> 'different things different names' and invoke them using these in
> higher-level control routines. If 'possible information leakage'
> becomes a problem, the constituent parts of 'the code' are way too
> large and do way too many different things.
We were discussing these two forms:
for (...) { my $tmp;
my $tmp = "/.../$_"; for (...) {;
...; $tmp = "/.../$_";
} ...;
}
and you claimed the second was superior on grounds of efficiency. Sub
call overhead doesn't come into it.
> >> Do you think it was programmed to work around that because this is
> >> such a great idea? I don't. Especially since the computer can only
> >> work around the execution time penalty of this convention and not
> >> against the mess in the source code ("which of the 1,375 $i I
> >> encountered in the last 2000 lines of code is it this time?").
> >
> > Um, it's the one in the 'my' statement just above your cursor. That's
> > the whole point of tight scoping: except for the various kinds of
> > globals, which should not be created lightly and do require planning,
> > the scope of a single variable should not exceed one screenful of
> > code.
>
> Except if 'screenful' is supposed to refer to 80x25,
Of course.
> it should
> usually be less: Some random 'screenful of code' I just looked at (148
> lines of text) contained five different complete subroutines whose
> bodies where (from top to bottome), 5 lines of text, 12 lines of text,
> 17 lines of text, 4 lines of text and 1 line of text.
Do you understand the meaning of 'should not exceed'?
> > If you are having to deal with code which has multiple variables with
> > the same name in nested scopes, some extending over hundreds of lines of
> > code, you have my sympathies. That is not a code style I am
> > advocating.
>
> It's rather "multiple variables of the same type with the names spelled
> somewhat differently, eg mdmCommand, MdmCommand and MDMCommand, all
> supposed to contain the same thing, namely, the current MDM command,
> which occur (or in this case, occurred) in the same 'hundreds of lines
> of code' subroutine (Java method), with the number of different
> spellings presumably equal to the number of different people who added
> code to this particular method" (this is slight 'abstraction' of the
> actual situation, but IMO an honest one). And without the possiblity
> to 'declare variables on the spot' whenever one is needed, something
> like this couldn't occur.
Why are you talking about Java? Who (here) cares about Java? Everyone
knows it encourages poor programmers to write incomprehensible rubbish.
Ben
------------------------------
Date: Mon, 15 Jul 2013 15:05:18 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: this should work
Message-Id: <87ehazhqap.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>> > A variable is just a way of giving a value a name;
>>
>> This is true for so-called 'functional programming languages' but Perl
>> isn't one: There, a 'variable' is something like a deposit box
>> (term?): A container which can be used to store 'stuff' of a certain
>> kind (depending on the type of box) until it is again needed which can
>> be 'addressed' in a convenient way (usually, by using an abstract name
>> referring to the 'function' of this variable).
>
> How is that different from 'just a way of giving a value a name'?
In simply terms, it is 'stuff the value into the named box' vs
'evaluating a term in the context of some binding', that is, with
certain set of 'name substitution rules' in place. I don't know if
something like 'introductory text books' (or WWW texts) on
'functional programming' (vs 'programming with imperative languages')
exist but if they do, you'd find a better explanation there
(especially one you're more likely to consider than to reject it 'with
a jerk of your knee' because it comes with $authority attached :->).
>> > The whole point of lexical variables is to avoid the problems that
>> > occur when uncontrolled and implicit data leakage occurs between
>> > different parts of the program; having Perl ensure that values we no
>> > longer need are properly disposed of as soon as possible is just
>> > common sense.
>> >
>> > (And, again, this is not about efficiency, either of CPU or memory. It's
>> > about making the code comprehensible.)
>>
>> IMO, it is about making the code incomprehensible for the sake of
>> 'efficiency', namely, to avoid the dreaded, mythological function call
>> overhead, by cramming as many different algorithms into a single run
>> of sequential code as seems remotely feasible instead of giving
>> 'different things different names' and invoke them using these in
>> higher-level control routines. If 'possible information leakage'
>> becomes a problem, the constituent parts of 'the code' are way too
>> large and do way too many different things.
>
> We were discussing these two forms:
>
> for (...) { my $tmp;
> my $tmp = "/.../$_"; for (...) {;
> ...; $tmp = "/.../$_";
> } ...;
> }
>
> and you claimed the second was superior on grounds of efficiency.
I didn't claim that, I pointed it out. Arguably for tactical reasons
because trying to convince people who dumped $native_language with a
sigh of relief at the earliest possible opportunity during their
educational career in order to dedicate themselves to the domain of
incomprehensible strings of non-alphabetic symbols meticiously
arranged according to some set of traditional rules that they're still
writing texts and the same rules for "don't make a mess of it" apply
as to any other text (eg, don't constantly and gratuitiously introduce
new stuff just because you can) is hopeless: Pointing out that the
result is lacking according to some measurable 'hard' criterion will
usually at least lead to the admission that "well, it does, but -
cunningly - we programmmed the computer to work around that already".
But that doesn't really belong into a discussion of problems which might
occur in large, sequential runs of code when band aids of this kind
weren't available
>> >> Do you think it was programmed to work around that because this is
>> >> such a great idea? I don't. Especially since the computer can only
>> >> work around the execution time penalty of this convention and not
>> >> against the mess in the source code ("which of the 1,375 $i I
>> >> encountered in the last 2000 lines of code is it this time?").
>> >
>> > Um, it's the one in the 'my' statement just above your cursor. That's
>> > the whole point of tight scoping: except for the various kinds of
>> > globals, which should not be created lightly and do require planning,
>> > the scope of a single variable should not exceed one screenful of
>> > code.
>>
>> Except if 'screenful' is supposed to refer to 80x25,
>
> Of course.
>
>> it should
>> usually be less: Some random 'screenful of code' I just looked at (148
>> lines of text) contained five different complete subroutines whose
>> bodies where (from top to bottome), 5 lines of text, 12 lines of text,
>> 17 lines of text, 4 lines of text and 1 line of text.
>
> Do you understand the meaning of 'should not exceed'?
I think 'should not exceed' and 'should usually be a lot less than'
are substantially different.
------------------------------
Date: Mon, 15 Jul 2013 17:23:50 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: this should work
Message-Id: <ks1b76$p8t$1@reader2.panix.com>
In article <kp8dba-9591.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>
>Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>>
>> > A variable is just a way of giving a value a name;
>>
>> This is true for so-called 'functional programming languages'
I would quibble with this terminology. There are languages (LISP and
its children) that I would call "functional" because the MAJOR
emphasis is for functional programming, but they may still provide a
way to change the value of variables (setq and such) in the same was
as an imperative language like Perl. I do not see setq and such as
fatally tainting the essential functionalness of the language. You
definitions may be different.
>> but Perl
>> isn't one: There, a 'variable' is something like a deposit box
>> (term?): A container which can be used to store 'stuff' of a certain
>> kind (depending on the type of box) until it is again needed which can
>> be 'addressed' in a convenient way (usually, by using an abstract name
>> referring to the 'function' of this variable).
>
>How is that different from 'just a way of giving a value a name'?
Because it's giving the STORAGE LOCATION a name. The value in the
storage location can change without altering the name of the
container.
If the Lochners move out of a house and the Willowbys move in,
and it remains 730 Watling Street, that's the name of the container.
If it goes from being Lochner House to Willowby House, it's the name
of the contents.
I contrast this with single-assignment languages. Since I wasn't
familiar with them, I'll explain in a bit of detail, even though many
other people already know about it. I was unfamiliar with them until
I had to use DSSSL, a Lisp-like language that was designed for
transforming XML into other XML or into formatted output. XSLT is a
later version of the same concept.
DSSSL is single-assignment, and I think XSLT is too. You can define a
name for the result of a computation, but the definition is immutable
-- you cannot change the right-hand side once defined. You cannot
change the input either.
In that case, there may BE no "storage location". Whereever you use
the name, so far as I can tell, the interpreter is entirely free to
substitute the right-hand side verbatim at that point. I think that
any reasonably efficient interpreter would have to evaluate it once
and then cache the result. But ideal caching is always behind the
scenes.
In that case, I'd call it a name for the value. You may object that
it's more properly a name for the expression, and I can't argue
against that viewpoint, but I am more interested in the value and they
do go together.
(As an aside, can I exclaim about what a hideous PAIN IN THE ASS it is
to program a single-assignment pattern-matching language? So many
times I wanted to do the imperative thing (assign -> use) when I
couldn't even think of a way to do it with this single-assignment
thing. End of rant.)
Anyway, sorry if I belabor the obvious.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Mon, 15 Jul 2013 21:02:03 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: this should work
Message-Id: <r21eba-jjb1.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> > Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> >> Ben Morrow <ben@morrow.me.uk> writes:
> >> > A variable is just a way of giving a value a name;
> >>
> >> This is true for so-called 'functional programming languages' but Perl
> >> isn't one: There, a 'variable' is something like a deposit box
> >> (term?): A container which can be used to store 'stuff' of a certain
> >> kind (depending on the type of box) until it is again needed which can
> >> be 'addressed' in a convenient way (usually, by using an abstract name
> >> referring to the 'function' of this variable).
> >
> > How is that different from 'just a way of giving a value a name'?
>
> In simply terms, it is 'stuff the value into the named box' vs
> 'evaluating a term in the context of some binding', that is, with
> certain set of 'name substitution rules' in place. I don't know if
> something like 'introductory text books' (or WWW texts) on
> 'functional programming' (vs 'programming with imperative languages')
> exist but if they do, you'd find a better explanation there
> (especially one you're more likely to consider than to reject it 'with
> a jerk of your knee' because it comes with $authority attached :->).
Yes, I understand the difference between let and setq, and between a pad
slot called $x and the SV it points to, and I know that Perl has no real
equivalent of a let-binding. That's not the point: the point is that
assignment to a lexical is the usual way in Perl to temporarily give a
name to an interesting value, and that one should therefore not be
afraid to create lexicals on the basis of some spurious argument about
performance.
> >> > The whole point of lexical variables is to avoid the problems that
> >> > occur when uncontrolled and implicit data leakage occurs between
> >> > different parts of the program; having Perl ensure that values we no
> >> > longer need are properly disposed of as soon as possible is just
> >> > common sense.
> >> >
> >> > (And, again, this is not about efficiency, either of CPU or memory. It's
> >> > about making the code comprehensible.)
> >>
> >> IMO, it is about making the code incomprehensible for the sake of
> >> 'efficiency', namely, to avoid the dreaded, mythological function call
> >> overhead, by cramming as many different algorithms into a single run
> >> of sequential code as seems remotely feasible instead of giving
> >> 'different things different names' and invoke them using these in
> >> higher-level control routines. If 'possible information leakage'
> >> becomes a problem, the constituent parts of 'the code' are way too
> >> large and do way too many different things.
> >
> > We were discussing these two forms:
> >
> > for (...) { my $tmp;
> > my $tmp = "/.../$_"; for (...) {;
> > ...; $tmp = "/.../$_";
> > } ...;
> > }
> >
> > and you claimed the second was superior on grounds of efficiency.
>
> I didn't claim that, I pointed it out.
You pointed out it was more efficient (in that particular case), which I
didn't dispute (in that particular case). You claimed it was therefore
superior, which I do dispute.
> Arguably for tactical reasons
> because trying to convince people who dumped $native_language with a
> sigh of relief at the earliest possible opportunity during their
> educational career in order to dedicate themselves to the domain of
> incomprehensible strings of non-alphabetic symbols meticiously
> arranged according to some set of traditional rules that they're still
> writing texts and the same rules for "don't make a mess of it" apply
> as to any other text (eg, don't constantly and gratuitiously introduce
> new stuff just because you can) is hopeless: Pointing out that the
> result is lacking according to some measurable 'hard' criterion will
> usually at least lead to the admission that "well, it does, but -
> cunningly - we programmmed the computer to work around that already".
ESENTENCETOOLONG: Stack overflow, core dumped.
If you are attempting to use your skills with natural language as
evidence of your skills with Perl, you're doing a pretty poor job :).
This is not a debating society nor a marketing seminar; you don't win
points for convincing someone of something by devious means. Advancing a
deliberately bad argument in favour of a point you believe to be good is
a very bad idea, for three reasons. First, people who don't know any
better might think the argument is a good one, and apply it in other
situations. Second, people who do know better will assume you have no
better argument, and discount your argument. Third, once people find out
what you are doing it makes you look dishonest.
> But that doesn't really belong into a discussion of problems which might
> occur in large, sequential runs of code when band aids of this kind
> weren't available
We weren't discussing large sequential runs of code, with or without
band-aids of any kind. We were discussing whether a temporary used in a
for loop should be declared inside or outside the loop.
> >> >> Do you think it was programmed to work around that because this is
> >> >> such a great idea? I don't. Especially since the computer can only
> >> >> work around the execution time penalty of this convention and not
> >> >> against the mess in the source code ("which of the 1,375 $i I
> >> >> encountered in the last 2000 lines of code is it this time?").
> >> >
> >> > Um, it's the one in the 'my' statement just above your cursor. That's
> >> > the whole point of tight scoping: except for the various kinds of
> >> > globals, which should not be created lightly and do require planning,
> >> > the scope of a single variable should not exceed one screenful of
> >> > code.
> >>
> >> Except if 'screenful' is supposed to refer to 80x25,
> >
> > Of course.
> >
> >> it should
> >> usually be less: Some random 'screenful of code' I just looked at (148
> >> lines of text) contained five different complete subroutines whose
> >> bodies where (from top to bottome), 5 lines of text, 12 lines of text,
> >> 17 lines of text, 4 lines of text and 1 line of text.
> >
> > Do you understand the meaning of 'should not exceed'?
>
> I think 'should not exceed' and 'should usually be a lot less than'
> are substantially different.
Ah. I don't. 'Should usually be a lot less than' is more specific than
'should not exceed', but does not contradict it.
Ben
------------------------------
Date: Mon, 15 Jul 2013 15:40:04 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: this should work
Message-Id: <87k3krfw8b.fsf@new.chromatico.net>
>>>>> "BM" == Ben Morrow <ben@morrow.me.uk> writes:
BM> Why are you talking about Java? Who (here) cares about Java?
I find myself caring about it for professional reasons.
BM> Everyone knows it encourages poor programmers to write
BM> incomprehensible rubbish.
I thought that was Perl. Java encourages poor programmers whose
greatest aspiration is to be an unthinking cog in a poorly-designed
machine to write incredibly verbose rubbish, most of which could more
easily be copied and pasted.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 3991
***************************************
