Re: [ID 20000111.008] use strict 'vars'

[london@pixelmagic.com]

you can be quite hubritic sometimes, really.

I start out by saying "I'm sure there was a reason it was done this way"
followed by saying its a weird exception to the norm.
I then ask if there were anyway that the exception could be redone
so that it doesn't trip up the neophytes.

your response it to reject the idea out of hand,
with no explanation of the reasons it was originally done that way,
and with nothing but sarcastic remarks on the suggestions offered.

given that any language is useless if there aren't any people using
it, may I suggest that if you wish to forward perl, it isn't
simply "what you know" that's important.  

You are a veritable wealth of knowledge on the subject of perl and 
its intracacies.  but perl isn't about what you know. its about
what other people can learn and use for themselves.  
(for perl developers, perl is about getting someone else's job done.)

if anyone asks an honest perl question and you reply with sarcasm,
I'd say you are doing a disservice for the whole of perl.

specific responses below:

Tom Christiansen wrote:
> 
> >I'm sure there is a really good reason that user defined sort subs
> >use the global/local/univeral/magical variables $a and $b to determine
> >sorting order, rather than having the sort routine look at a less painful
> >variable, such at @_.   faster, less memory, something.
> 
> Was that a question?
> 
> >but from a user point of view, its a hidden gotcha.
> 
> I fail to see how something that it is documented can be adjudged
> "hidden".  Neither do I understand how something that has worked in that
> fashion since time immemorial (perl-wise) is "hidden".  What, pray tell,
> might we have to do to make it "not hidden"?  Make it the first thing
> in the the perl(1) manpage?  Do you have a suggested patch to perlvar(1)?


people expect computer languages to all behave pretty much the same.
a conditional statement should be pretty straighforward.
so should the use of variables.  It's arrogant to demand that people 
read all the man pages before they start their first perl program
so they discover all the exceptions to the rules of normal 
computer language behaviour.


 
> >I recall writing some code that unknowingly used the $a $b
> >variables (ran out of $i, $j, $k, $x, $y, $z) and had some
> >weird behaviour that I didn't figure out until I asked a perl "guru".
> 
> Perhaps this is a special penalty for those with insufficient
> imagination to use properly named variables. :-)



could not the same penalty be applied to Perl for using
$a and $b as names for sorting variables then?
should we broadcast that person's name and phone number 
to the universe for that decision?



> >could perl spit out some kind of note when it encounters $a or $b
> >such as "this is a weird variable reserved for sorting."
> >just to inform a neophyte that $a is not the same as $c .. $z?
> >that the perl people know about it, and that the user should
> >probably use a different variable?
> 
> Goodness, I don't think so.

we can put a man on the moon, but we can't do this ....

> >would it be too much to rename it to something less likely to
> >collide with the neophyte? maybe $_sorting_variable_a_
> 
> Only if breaking it in that odious fashion should cause Perl to emit
> your name, email address, and home phone number.
> 
> First of all, there's no reason to shamelessly destroy all existing sort code.
> Secondly, designing something to be novice-friendly at the expense
> of making it expert-hostile is a fundamental error, for you shall be a
> novice but once and briefly, yet a trans-novice for all the days of your
> life that follow your initiation into these the outermost mysteries.
> Thirdly, so long a variable name as that is completely repugnant.
> It reminds me of the same sentiment as drives the misguided to write
> 
>     for ($loop_index_variable = 0;
>          $loop_index_variable < scalar(@array);
>          $loop_index_variable = $loop_index_variable + 1
>         )
>     {
>         $cumulative_sum = $cumulative_sum
>                         + $an_array_variable[$loop_index_variable];
>     }



figure out the number of sorting subroutines that exist in perl 
that use $a $b,  multiply that by the number of characters in a 
long variable name (say 15), and you will still have fewer additional 
characters than is found in any of your common rants on p5p.



>> Upon packing his bags in preparation for a journey, the savvy traveller
>> discards fully fifty percent of his stowed possessions, for he realizes
>> that needless clutter and gratuitous baggage but weigh him down and
>> distract him from his goal.  It is only after many years of repeated
>> mistakes that the truly seasoned traveller can a priori recognize
>> unjustifiable bloat for its hidden promise of inevitable annoyance.


that rant alone should fully exceed the number of characters needed to expand
all sorting routines in perl such that 
s/\$a/\$_sort_a_/ and
s/\$b/\$_sort_b_/



> >if there isn't much of a performance/memory/etc hit, could
> >it use @_  since the sort routine must be a subroutine?
> 
> Sure, as long as you agree that Perl should in perpetuity emit your real
> home phone number because you decided to hose a million people because
> you stubbed your toe.  Eschew immediate gratification.


is that such a foolish suggestion?
am I misunderstanding what Larry Wall said here?



Larry Wall wrote:
> In a very recent development version of Perl, if you use a sort sub
> with a ($$) prototype, it'll give you the arguments in @_.  Eventually
> you'll be able to use a prototype of ($a, $b) and get them back into
> $a and $b, only as lexicals.


it looks like @_ would get rid of the globals and everyone would be happy.


Greg

"Waiter, a round of diligence, patience, and humility 
 for everyone at the bar, including myself."

---

Follow-Ups from:

Steve Fink <sfink@digital-integrity.com>

---

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

---