Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > this should work

Reply
Thread Tools

this should work

 
 
Rainer Weikusat
Guest
Posts: n/a
 
      07-11-2013
Keith Keller <(E-Mail Removed)-francisco.ca.us> writes:
> On 2013-07-11, Rainer Weikusat <(E-Mail Removed)> wrote:
>>
>> In this case, this would be transforming the
>>
>> for (...) {
>> my $tmp = 'ar!';
>> }
>>
>> to
>>
>> my $tmp;
>> for (...) {
>> $tmp = 'ar!';
>> }
>>
>> because the 'my $tmp' is invariant code: It's effective result never
>> changes throughout the loop.

>
> This strikes me as premature optimization.


'Premature optimization' is a term which originally referred to the idea
of trying to write an 'optimal' machine-language programming 'from the
start', instead of concentrating on writing a working machine-language
program first and then - possibly - transform that into an
also-working but faster machine-language program and this in the
context of highly 'irregular' CISC-architecture as they were (still)
common in the 1970s where a lot of relatively 'bizarre' ways to
perform semantically identical operations in different ways actually
existed and it makes a hell lot of sense in this context.

It was never meant to be a universal justification for "But I don't
want to think about that!" and certainly also not for "But I don't
want to change my habits!"

> Unless I know my program is
> spending too much time doing my $tmp = 'ar!'; inside the for loop, I
> would much prefer to keep $tmp properly scoped and initialized inside
> the loop.


It is 'properly scoped' in the second example because the variable
stays (logically) alive for as long as it is going to be used and
'improperly scoped' in the first because (again, logically) it keeps
being destroyed and recreated (this is supposed to be a demonstration
that 'proper' means nothing on its own).

Unless you are having a serious out of memory problem,
'micro-optimizing' your code such that each object has the shortest
possible livetime can also be considered 'a premature optimization',
especially as it might not even help, as in this example.
 
Reply With Quote
 
 
 
 
George Mpouras
Guest
Posts: n/a
 
      07-11-2013
+1000 !



 
Reply With Quote
 
 
 
 
Charles DeRykus
Guest
Posts: n/a
 
      07-11-2013
On 7/11/2013 10:48 AM, Rainer Weikusat wrote:
> Keith Keller <(E-Mail Removed)-francisco.ca.us> writes:
>> On 2013-07-11, Rainer Weikusat <(E-Mail Removed)> wrote:
>>>
>>> In this case, this would be transforming the
>>>
>>> for (...) {
>>> my $tmp = 'ar!';
>>> }
>>>
>>> to
>>>
>>> my $tmp;
>>> for (...) {
>>> $tmp = 'ar!';
>>> }
>>>


....
>
> It is 'properly scoped' in the second example because the variable
> stays (logically) alive for as long as it is going to be used and
> 'improperly scoped' in the first because (again, logically) it keeps
> being destroyed and recreated (this is supposed to be a demonstration
> that 'proper' means nothing on its own).


But it (illogically) stays alive longer than is needed unless you insert
an additional, artificial scope as another poster showed:

{ my $tmp; for (...) { $tmp='ar!'} }.

[ And, of course, Ben's refaddr demo showed it really isn't "destroyed
and re-created". Digression: I seem to recall having seen a demo that
confirmed the older behavior once - it just printed \$tmp in lieu of
refaddr but the addr's differed each time and I could swear (almost) it
was newer than 5.6 ]


>
> Unless you are having a serious out of memory problem,
> 'micro-optimizing' your code such that each object has the shortest
> possible livetime can also be considered 'a premature optimization',
> especially as it might not even help, as in this example.
>


But, clearly, the narrowest possible scope for variables does help...
with potential variable collisions, havoc, and confusion in that
dangerous "no-man's land outside your own trench".

IMO, the insane optimization, is running a timing benchmark and
obsessing about microseconds of speed over hundreds, or more often
thousands, of iterations.

--
Charles DeRykus


 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      07-11-2013
Charles DeRykus <(E-Mail Removed)> writes:

> On 7/11/2013 10:48 AM, Rainer Weikusat wrote:
>> Keith Keller <(E-Mail Removed)-francisco.ca.us> writes:
>>> On 2013-07-11, Rainer Weikusat <(E-Mail Removed)> wrote:
>>>>
>>>> In this case, this would be transforming the
>>>>
>>>> for (...) {
>>>> my $tmp = 'ar!';
>>>> }
>>>>
>>>> to
>>>>
>>>> my $tmp;
>>>> for (...) {
>>>> $tmp = 'ar!';
>>>> }
>>>>

>
> ...
>>
>> It is 'properly scoped' in the second example because the variable
>> stays (logically) alive for as long as it is going to be used and
>> 'improperly scoped' in the first because (again, logically) it keeps
>> being destroyed and recreated (this is supposed to be a demonstration
>> that 'proper' means nothing on its own).

>
> 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: 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]).

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?").
 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      07-11-2013
Ben Morrow <(E-Mail Removed)> writes:
> Quoth Rainer Weikusat <(E-Mail Removed)>:
>> Keith Keller <(E-Mail Removed)-francisco.ca.us> writes:
>> > On 2013-07-11, Rainer Weikusat <(E-Mail Removed)> wrote:
>> >>
>> >> because the 'my $tmp' is invariant code: It's effective result never
>> >> changes throughout the loop.
>> >
>> > This strikes me as premature optimization.

>>
>> 'Premature optimization' is a term which originally referred to the idea
>> of trying to write an 'optimal' machine-language programming 'from the
>> start', instead of concentrating on writing a working machine-language
>> program first and then - possibly - transform that into an
>> also-working but faster machine-language program and this in the
>> context of highly 'irregular' CISC-architecture as they were (still)
>> common in the 1970s where a lot of relatively 'bizarre' ways to
>> perform semantically identical operations in different ways actually
>> existed and it makes a hell lot of sense in this context.
>>
>> It was never meant to be a universal justification for "But I don't
>> want to think about that!" and certainly also not for "But I don't
>> want to change my habits!"

>
> This is not about habits:


It is about habits grown out of the perfectly accidental fact that a
certain language allows variable declarations in inner scopes. Not all
of them do ...

> anyone who's been here (or anywhere else
> programming is taught) for a while will know that getting beginners to
> understand the value of proper scoping is not easy. It's about
> cleanliness:


.... and specifically, a certain language who was explicitly created to
teach beginners about 'proper scoping' and 'cleanly designed code',
namely, Pascal, doesn't and IMHO, with a good reason: When people
can't have multiple disjunct sets of variables used by unrelated parts
of the same 'aggregate subroutine', they do what they should be doing
instead, namely, structure their code.


 
Reply With Quote
 
Ivan Shmakov
Guest
Posts: n/a
 
      07-12-2013
>>>>> Rainer Weikusat <(E-Mail Removed)> writes:

[...]

> It is about habits grown out of the perfectly accidental fact that a
> certain language allows variable declarations in inner scopes. Not
> all of them do ...


[...]

> ... and specifically, a certain language who was explicitly created
> to teach beginners about 'proper scoping' and 'cleanly designed
> code', namely, Pascal, doesn't


Somehow, my impression was that it /does/ allow for nested
variable scopes. However, I have only a passing experience with
the language.

> and IMHO, with a good reason: When people can't have multiple
> disjunct sets of variables used by unrelated parts of the same
> 'aggregate subroutine', they do what they should be doing instead,
> namely, structure their code.


I disagree. I deem the use of nested scopes as crucial to code
structuring. Should the "roles" of the variables (whether
input, output, or local) become apparent later, it'd be trivial
to split the function, -- and that's likely to be done exactly
along the scope boundaries previously coded in.

--
FSF associate member #7257
 
Reply With Quote
 
Peter J. Holzer
Guest
Posts: n/a
 
      07-12-2013
On 2013-07-12 07:50, Ivan Shmakov <(E-Mail Removed)> wrote:
>>>>>> Rainer Weikusat <(E-Mail Removed)> writes:

> > ... and specifically, a certain language who was explicitly created
> > to teach beginners about 'proper scoping' and 'cleanly designed
> > code', namely, Pascal, doesn't


Pascal was designed in the late 1960s, only about a decade after
FORTRAN and COBOL. I hope we have learned something in the more than
four decades since then.


> Somehow, my impression was that it /does/ allow for nested
> variable scopes.


Maybe ISO Pascal does now. But Pascal as originally designed by Wirth
didn't. All the variable declarations had to be at the beginning of the
program, procedure or function and the code had to be at the end (with
possibly more nested procedures or functions in between). Of course the
nested procedures and functions could have their own properly scoped
variables, so there were nested scopes, but only at the
procedure/function level, not at the block level. This had two negative
consequences: Variable declarations in the outer procedures were
separated widely (often hundreds or thousands of lines) from the place
where they were used and they were visible in all the inner procedures,
so it was easy to accidentally reuse a loop variable in an inner
procedure called from that loop. I think a large part of the motivation
for Knuth's WEB came from the rigid structure of Pascal which forced you
to put stuff which logically belonged together into different portions
of the program.

> However, I have only a passing experience with the language.


Likewise. And all that experience happened in the 1980s, so it's almost
as dated as my experience with BASIC (the line-numbers-and-goto kind of
BASIC).

> > and IMHO, with a good reason: When people can't have multiple
> > disjunct sets of variables used by unrelated parts of the same
> > 'aggregate subroutine', they do what they should be doing instead,
> > namely, structure their code.

>
> I disagree. I deem the use of nested scopes as crucial to code
> structuring. Should the "roles" of the variables (whether
> input, output, or local) become apparent later, it'd be trivial
> to split the function, -- and that's likely to be done exactly
> along the scope boundaries previously coded in.
>


Right. I split functions/methods quite frequently. Either if a function
becomes too long or if I notice that I need part of a function in a
different function. Nested scopes make this kind of refactoring a
no-brainer. And of course they make reading the code a lot simpler, too.

hp


--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | http://www.velocityreviews.com/forums/(E-Mail Removed) | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
 
Reply With Quote
 
Dr.Ruud
Guest
Posts: n/a
 
      07-12-2013
On 11/07/2013 19:02, David Harmon wrote:

> Are you really proposing that the programmer should be expected to
> write:
>
> {
> my $tmpdir;
> foreach my $dir (qw/commands_pre commands_post/) {
> $tmpdir = "/tmp/$dir";
> print "$tmpdir\n"
> }
> }


I would expect her to write it as:

print "/tmp/$_\n"
for qw/ commands_pre commands_post /;

--
Ruud

 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      07-12-2013
"Peter J. Holzer" <(E-Mail Removed)> writes:
> On 2013-07-12 07:50, Ivan Shmakov <(E-Mail Removed)> wrote:
>>>>>>> Rainer Weikusat <(E-Mail Removed)> writes:
>> > ... and specifically, a certain language who was explicitly created
>> > to teach beginners about 'proper scoping' and 'cleanly designed
>> > code', namely, Pascal, doesn't

>
> Pascal was designed in the late 1960s, only about a decade after
> FORTRAN and COBOL. I hope we have learned something in the more than
> four decades since then.


ALGOL 60 was (as the name may suggest) designed at the beginning of
the 1960s and it included the concept of nested lexical scopes with
attached variable sets, cf

http://www.masswerk.at/algol60/report.htm

This means your statement would be more appropriately worded as: Four
decades after someone suggested a different approach, we are as
unconvinced as ever that anything was deficient with the tradional way
of handling this.

[Pascal program structure description]


> This had two negative consequences: Variable declarations in the
> outer procedures were separated widely (often hundreds or thousands
> of lines) from the place where they were used


That's not a consequence of having to put variable definitions at the
beginning of a procedured but of including 'hundreds or thousands' of
lines of loosely related code in between and the simple solution to
this problem is "Don't do that".

> and they were visible in all the inner procedures, so it was easy to
> accidentally reuse a loop variable in an inner procedure called from
> that loop.


Again, the way to solve the problem that 'nobody can still find his
way through this mess' is to avoid creating it in the first place:
Don't separate 'declaration and use' of a variable by 'thousands of
lines of code', move these 'thousands of lines' into subroutines which
don't have to share state with some parent routine and pass the data
they need to them as arguments.

[...]

>> > and IMHO, with a good reason: When people can't have multiple
>> > disjunct sets of variables used by unrelated parts of the same
>> > 'aggregate subroutine', they do what they should be doing instead,
>> > namely, structure their code.

>>
>> I disagree. I deem the use of nested scopes as crucial to code
>> structuring. Should the "roles" of the variables (whether
>> input, output, or local) become apparent later, it'd be trivial
>> to split the function, -- and that's likely to be done exactly
>> along the scope boundaries previously coded in.

>
> Right. I split functions/methods quite frequently. Either if a function
> becomes too long or if I notice that I need part of a function in a
> different function. Nested scopes make this kind of refactoring a
> no-brainer.


The point is that this 'kind of refactoring' shouldn't ever be
necessary because the '15,000 lines of code and counting' 'subroutine'
shouldn't have been created to begin with: That's another of these
'outlandish new concepts' people have been ignoring for four decades
now ('stepwise refinement') because 'the old ways' don't need no
fixing especially since ...

> And of course they make reading the code a lot simpler, too.


.... abstraction is evil because it hides details. It is claimed that
some of them wouldn't be significant at some higher level but
actually, higher level already sounds highly suspicious ...

 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      07-12-2013
David Harmon <(E-Mail Removed)> writes:
> On Thu, 11 Jul 2013 22:04:45 +0100 in comp.lang.perl.misc, Ben
> Morrow <(E-Mail Removed)> wrote,
>>> Are you really proposing that the programmer should be expected to
>>> write:
>>>
>>> {
>>> my $tmpdir;
>>> foreach my $dir (qw/commands_pre commands_post/) {
>>> $tmpdir = "/tmp/$dir";
>>> print "$tmpdir\n"
>>> }
>>> }

>>
>>This will, of course, be a good bit slower than with the my inside the
>>loop. Blocks are quite expensive, because they're one-iteration loops,
>>and that requires a bit of setup.

>
> Sorry to hear that.


When adding an additional block to the last out_of_loop example I
posted, it doesn't become any slower than it was without the block.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Who can explain this bug? mathog C Programming 57 06-11-2013 10:09 PM
How do I encode and decode this data to write to a file? cl@isbd.net Python 11 05-01-2013 11:36 PM
Why does this incorrect CRTP static_cast compile? kfrank29.c@gmail.com C++ 2 04-25-2013 01:38 PM
This looks like a Perl bug George Mpouras Perl Misc 18 04-21-2013 11:56 PM
Really throwing this out there - does anyone have a copy of my oldDancer web browser? steven.miale@gmail.com Python 1 04-10-2013 03:32 PM



Advertisments