Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.perl.misc > #8710
| From | Rainer Weikusat <rweikusat@mssgmbh.com> |
|---|---|
| Newsgroups | comp.lang.perl.misc |
| Subject | Re: this should work |
| Date | 2013-07-15 13:41 +0100 |
| Message-ID | <87ip0cgfli.fsf@sapphire.mobileactivedefense.com> (permalink) |
| References | <krkm21$19jd$1@news.ntua.gr> <87k3kxasym.fsf@sapphire.mobileactivedefense.com> <krmvhv$v3k$1@speranza.aioe.org> <87txk0oioo.fsf@sapphire.mobileactivedefense.com> <spt3ba-i9r2.ln1@anubis.morrow.me.uk> |
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Charles DeRykus <derykus@gmail.com> writes:
>>
>> > But it (illogically) stays alive longer than is needed unless you
>> > insert an additional, artificial scope as another poster showed:
>>
>> The 'logically' was supposed to refer to the fact that perl employs
>> self-defense mechanisms against code of this type by NOT doing what
>> the author requested: It keeps the variable alive despite this seems
>> 'ill/im' (arbitrary suffix attached) to some people:
>
> It explicitly does not keep the variable alive: it sets the PADSTALE
> bit, which indicates that this variable is 'dead', and prevents string
> evals and such from picking the variable up by mistake. It doesn't
> deallocate the storage used for the variable, but that's just the same
> level of optimisation as malloc uses when it doesn't reduce the brk just
> because something has been freed.
It's not: Malloc usually retains whatever 'memory' (adress space, actually) it
already requested from the kernel in order to satisfy future
allocation requests. This means that code like this
-------------------
use Devel::Peek;
sub yow
{
for (0 .. 100) {
{
my $a = "$_ + 1";
print(\$a, "\n");
Dump($a);
}
{
my $b = "$_ + 1";
print(\$b, "\n");
Dump($b);
}
}
}
&yow;
-------------------
would reuse the same space both for the $a and $b 'control blocks' and
their string bodies and that all meta-information associated with any
of these four 'logical' memory areas would be lost after each
block: There wouldn't be a way to 'set the PADSTALE bit' for any of
the scalars because whatever memory happened to be allocated to them
would turn into a completely generic 'free memory area' of a certain
size. That's not happening in this case (for perl 5.10.1 at least).
[...]
>> The computer has been programmed to work around this obsession with
>> the 'micro-optimized lifecycle management' (And this is a
>> euphemism. I'd wager a bet this this is practically just 'create a
>> new variable whenever you need one because remembering what
>> variables were created two lines ago would be SO cumbersome' [and
>> 'plan in advance variables will be needed' an imposition beyond any
>> physically tolerable by man]).
>
> We are not writing assembler, where you have a limited number of
> registers and their use needs to be planned carefully.
Programming means 'construction of algorithms', these algorithms are
usually stateful, that is, they employ variables to keep track of
'past events' and constructing such an algorithm requires a certain
amount of planning/ forethought, especially if it is supposed to be a
sensibly implemented algorithm, that is, one which both solves a
certain problem efficiently and does so without unneeded complications
putting a burden on the mind of someone trying to understand the code.
You're free to believe that you're - thankfully - absolved form the
burden of thinking about what you're going to write before you write
it because "you are not writing assembler" but so far, I haven't
encountered a more ludicrous statement about 'software development'
(and I'm fairly certain that you didn't mean to express that).
> 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).
[...]
> 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.
>> 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, 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.
[...]
> 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.
Back to comp.lang.perl.misc | Previous | Next — Previous in thread | Next in thread | Find similar
this should work "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam> - 2013-07-11 01:08 +0300
Re: this should work Jim Gibson <jimsgibson@gmail.com> - 2013-07-10 15:49 -0700
Re: this should work George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com> - 2013-07-11 09:42 +0300
Re: this should work tmcd@panix.com (Tim McDaniel) - 2013-07-11 08:02 +0000
Re: this should work Ben Morrow <ben@morrow.me.uk> - 2013-07-11 12:45 +0100
Re: this should work George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com> - 2013-07-11 15:03 +0300
Re: this should work "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2013-07-11 14:52 +0200
Re: this should work George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com> - 2013-07-11 16:01 +0300
Re: this should work Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-11 14:29 +0100
Re: this should work Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-11 14:27 +0100
Re: this should work Peter Makholm <peter@makholm.net> - 2013-07-11 15:50 +0200
Re: this should work Jürgen Exner <jurgenex@hotmail.com> - 2013-07-11 03:34 -0700
Re: this should work George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com> - 2013-07-11 13:55 +0300
Re: this should work Peter Makholm <peter@makholm.net> - 2013-07-11 13:57 +0200
Re: this should work Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> - 2013-07-11 09:10 -0400
Re: this should work Ben Morrow <ben@morrow.me.uk> - 2013-07-11 21:35 +0100
Re: this should work Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-11 10:32 +0100
Re: this should work Ben Morrow <ben@morrow.me.uk> - 2013-07-11 12:51 +0100
Re: this should work Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-11 13:42 +0100
Re: this should work Ben Morrow <ben@morrow.me.uk> - 2013-07-11 16:23 +0100
Re: this should work Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-11 17:17 +0100
Re: this should work Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-11 18:08 +0100
Re: this should work Ben Morrow <ben@morrow.me.uk> - 2013-07-11 21:48 +0100
Re: this should work Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> - 2013-07-11 10:32 -0700
Re: this should work Jürgen Exner <jurgenex@hotmail.com> - 2013-07-11 10:48 -0700
Re: this should work "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam> - 2013-07-11 21:38 +0300
Re: this should work Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-11 23:08 +0100
Re: this should work Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-11 18:48 +0100
Re: this should work Charles DeRykus <derykus@gmail.com> - 2013-07-11 12:03 -0700
Re: this should work Ben Morrow <ben@morrow.me.uk> - 2013-07-11 22:02 +0100
Re: this should work Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-11 23:06 +0100
Re: this should work Ben Morrow <ben@morrow.me.uk> - 2013-07-12 01:04 +0100
Re: this should work Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-15 13:41 +0100
Re: this should work Ben Morrow <ben@morrow.me.uk> - 2013-07-15 14:07 +0100
Re: this should work Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-15 15:05 +0100
Re: this should work Ben Morrow <ben@morrow.me.uk> - 2013-07-15 21:02 +0100
Re: this should work Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-15 23:58 +0100
Re: this should work tmcd@panix.com (Tim McDaniel) - 2013-07-15 17:23 +0000
Re: this should work Charlton Wilbur <cwilbur@chromatico.net> - 2013-07-15 15:40 -0400
Re: this should work Ben Morrow <ben@morrow.me.uk> - 2013-07-11 21:58 +0100
Re: this should work Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-11 23:17 +0100
[OT] scoping Ivan Shmakov <oneingray@gmail.com> - 2013-07-12 07:50 +0000
Re: [OT] scoping aka 'new holes in old shoes' Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-12 11:53 +0100
[OT] engineering Ivan Shmakov <oneingray@gmail.com> - 2013-07-15 11:37 +0000
Re: [OT] engineering Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-16 21:49 +0100
Re: [OT] engineering Ivan Shmakov <oneingray@gmail.com> - 2013-07-17 09:27 +0000
Re: [OT] engineering Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-17 15:53 +0100
Re: [OT] engineering Ivan Shmakov <oneingray@gmail.com> - 2013-07-22 10:36 +0000
Re: [OT] engineering Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> - 2013-07-23 06:43 -0400
Re: [OT] engineering Ivan Shmakov <oneingray@gmail.com> - 2013-07-22 10:38 +0000
Re: [OT] engineering Rui Maciel <rui.maciel@gmail.com> - 2013-07-26 10:09 +0100
Re: [OT] scoping "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2013-07-12 14:58 +0200
Re: [OT] scoping Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-12 15:50 +0100
Re: [OT] scoping Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> - 2013-07-12 13:34 -0400
Re: [OT] scoping Ben Morrow <ben@morrow.me.uk> - 2013-07-12 22:04 +0100
Re: [OT] scoping Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-13 13:13 +0100
Re: [OT] scoping John Black <jblack@nospam.com> - 2013-07-13 20:01 -0500
Re: [OT] scoping Ben Morrow <ben@morrow.me.uk> - 2013-07-14 03:24 +0100
Re: [OT] scoping "Dr.Ruud" <rvtol+usenet@xs4all.nl> - 2013-07-14 10:49 +0200
Re: [OT] scoping Ben Morrow <ben@morrow.me.uk> - 2013-07-14 13:13 +0100
Re: [OT] scoping "Dr.Ruud" <rvtol+usenet@xs4all.nl> - 2013-07-14 17:02 +0200
Re: [OT] scoping Ben Morrow <ben@morrow.me.uk> - 2013-07-14 22:21 +0100
Re: [OT] scoping "Dr.Ruud" <rvtol+usenet@xs4all.nl> - 2013-07-15 02:21 +0200
Re: [OT] scoping Xho Jingleheimerschmidt <xhoster@gmail.com> - 2013-07-14 17:04 -0700
Re: [OT] scoping Ben Morrow <ben@morrow.me.uk> - 2013-07-15 14:12 +0100
Re: [OT] scoping tmcd@panix.com (Tim McDaniel) - 2013-07-14 15:11 +0000
Re: [OT] scoping "Dr.Ruud" <rvtol+usenet@xs4all.nl> - 2013-07-14 17:34 +0200
Re: [OT] scoping Xho Jingleheimerschmidt <xhoster@gmail.com> - 2013-07-14 15:34 -0700
Re: [OT] scoping Ben Morrow <ben@morrow.me.uk> - 2013-07-15 14:27 +0100
Re: [OT] scoping John Black <jblack@nospam.com> - 2013-07-14 23:48 -0500
Re: [OT] scoping Martijn Lievaart <m@rtij.nl.invlalid> - 2013-07-13 12:14 +0200
Re: this should work David Harmon <source@netcom.com> - 2013-07-11 10:02 -0700
Re: this should work Ben Morrow <ben@morrow.me.uk> - 2013-07-11 22:04 +0100
Re: this should work David Harmon <source@netcom.com> - 2013-07-12 09:34 -0700
Re: this should work Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-12 18:16 +0100
Re: this should work "Dr.Ruud" <rvtol+usenet@xs4all.nl> - 2013-07-12 15:44 +0200
Re: this should work David Harmon <source@netcom.com> - 2013-07-12 15:53 -0700
Re: this should work Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> - 2013-07-11 09:14 -0400
Re: this should work "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam> - 2013-07-11 19:45 +0300
csiph-web