Check POP3 E-mail

[David Gale]

It is a trivial waste of runtime, and a non-trivial waste of a
reader's time when they try to figure out *why* you're explicitly
initializing something which doesn't need it.

Wait, you're saying that the perl interpretter doesn't just skip the
unnecessary assignment? That's a surprise to me; I've always had the
impression that perl optimizes fairly well (I've never had a problem with
its running speed), and since most early perl programmers were coming from
languages which did require explicit initialization, I would've expected
that this trivial optimization would've been one of the first features.
Granted, I haven't run any tests to see if there is, in fact, a noticeable
difference, but I'd be shocked to find there is one.

As for wasting a reader's time: a) Anyone as familiar with perl as you would
immediately realize that this is an extraneous hold-over, and thus not waste
any time wondering about the initialization; b) anyone not as wise and
experienced, or whose primary experience is in a different language,
wouldn't even notice the initialization as being out-of-place. In neither
case would it slow the reader down, and, in fact, can often aid in
interpretation--if I initialize a scalar to 0, then it's clear that I intend
that variable to be numeric; if I initialize it to '', then it's clear that
I intend to use it as a string. Granted, wise perl programmers like
yourself would know that 0 and '' are both false values, and thus
equivalent--but the lesser mortals would benefit from the extra tip. Think
of it as a small form of self-commenting code.

Thus I would strongly disagree here. Write less code, unless that
makes things less clear.

And, as argued above, I think that it does help keep things clear.

my $var;
my $var = 0;
my $var = '';

are all equivalent statements, but, as pointed out above, the first tells
you *nothing* about how the variable is intended to be used; that has to be
determined through code examination. The second and third, however, show
their purpose immediately.

Know The Language You're Writing In. It *never* pays to carry habits
across from one language to another.

Ah, the great philosophy of, "If you can't become an instant expert in
whatever language your boss determines to be appropriate for the job, you
might as well flip burgers at the local burger joint." Code is code.
Often, habits that are helpful in one language are helpful in others--or do
you not use subroutines, because they are too similar to C's functions? I
terminate my lines in TCL with semi-colons, even though it's completely
superfluous to do so, because I think it makes it clearer, and it doesn't
slow TCL down at all. Proper code commenting should be a habit, regardless
of language; granted, the character sequence to delimit a comment changes,
but that doesn't change the fact that it's a good habit. And so on. That's
why most programming classes try to teach programming styles, rather than
specific language features--yes, it's great that I learned how to program
Dyllan. But if I couldn't transfer the skills and habits from there, I'd be
forced to start from scratch when dealing with Scheme, Lisp, etc.

I'll grant that there's one language which specifically *tried* to break
totally away from all previous languages (Intercal), but I've never seen
familiarity with that listed as a required skill on a job posting.

You do. Perl guarantees variables to be correctly initialized to what
you expect. If you don't trust Perl to leave $x undef after 'my $x;',
why do you trust it after 'my $x = undef;'?

I do, in perl. But not in most other languages. And, again, 'my $x;' tells
me nothing of the expected use of the variable, whereas 'my $x = 0;' does.
(Incidentally, 'my $x = undef;' suffers from the same problem, and so I
never use it. So, *in my opinion*, 'my $x;' and 'my $x = undef;' are both
equivalent unclear constructs, and ought to be avoided.)

 

[Tad McClellan]

my $var;
my $var = 0;
my $var = '';

are all equivalent statements,

No they're not.

$var gets 3 different values for the 3 different statements,
I don't see that as "equivalent"!

 

[Ben Morrow]

Wait, you're saying that the perl interpretter doesn't just skip the
unnecessary assignment?

~% perl -MO=Concise -e'my $x = undef'
6 <@> leave[1 ref] vKP/REFC ->(end)
1 <0> enter ->2
2 <;> nextstate(main 1 -e:1) v ->3
5 <2> sassign vKS/2 ->6
3 <0> undef s ->4
4 <0> padsv[$x:1,2] sRM*/LVINTRO ->5
-e syntax OK

Note the sassign and the undef; so no, it doesn't.

That's a surprise to me; I've always had the impression that perl
optimizes fairly well (I've never had a problem with its running
speed),

I did say a trivial waste. I would bet that it almost never makes any
difference, so it's not worth the optimizer finding it.

and since most early perl programmers were coming from languages which
did require explicit initialization,

What, like shell and awk?

As for wasting a reader's time: a) Anyone as familiar with perl as you
would immediately realize that this is an extraneous hold-over, and
thus not waste any time wondering about the initialization;

Not true. I am familiar with Perl; however, although I had a little
knowledge of C when I learned Perl most of my background was in BASIC
and FoxPro, which do not require explicit initialization. When someone
puts an explicit initial value in, it makes me think immediately that
there is some reason why that value a. is not there anyway and b. is
necessary (I tend to start with the assumption that the writer of the
code wasn't a fool). If I can't see any obvious reason for it it makes
me worry for a minute that there is something going on that I don't
understand, which is not a kind thing to do to a reader of your code.

b) anyone not as wise and experienced, or whose primary experience is
in a different language, wouldn't even notice the initialization as
being out-of-place.

Languages which require explicit initialization are by no means as
common as those which do not.

In neither case would it slow the reader down, and, in
fact, can often aid in interpretation--if I initialize a scalar to 0,
then it's clear that I intend that variable to be numeric; if I
initialize it to '', then it's clear that I intend to use it as a
string. Granted, wise perl programmers like yourself would know that
0 and '' are both false values, and thus equivalent

NO! They are both false, yes; but they are *NOT* equivalent, and are
*NOT* equivalent to undef. I will occasionally write something like

my $x = '';

where I wish to avoid uninit value warnings, or am going to use undef as
a flag later, or something; and that initialization tells the reader
that there is some reason why the default initial value of undef won't
do.

--but the lesser
mortals would benefit from the extra tip. Think of it as a small form
of self-commenting code.


And, as argued above, I think that it does help keep things clear.

my $var; my $var = 0; my $var = '';

are all equivalent statements,

NO THEY ARE NOT.

$\ = '';
print '[';
{
local ($\, $,) = ("]\n[", '], [');
{
my $var;
print $var, defined $var;
}
{
my $var = 0;
print $var, defined $var;
}
{
my $var = '';
print $var, defined $var;
}
}
print "]\n";

but, as pointed out above, the first
tells you *nothing* about how the variable is intended to be used;
that has to be determined through code examination. The second and
third, however, show their purpose immediately.


Ah, the great philosophy of, "If you can't become an instant expert in
whatever language your boss determines to be appropriate for the job,
you might as well flip burgers at the local burger joint."

I said noting about 'expert', and nothing about 'instant'. You should
read enough about the language to understand how it works before writing
(real) code in it. I would have thought this was obvious.

Code is code. Often, habits that are helpful in one language are
helpful in others--or do you not use subroutines, because they are too
similar to C's functions?

Yes, I use subs, because they are a feature of *Perl*. I do not
explicitly initialize variables where I don't need to, because such
initializations not being required is a feature of *Perl*.

I do, in perl. But not in most other languages. And, again, 'my $x;'
tells me nothing of the expected use of the variable, whereas 'my $x =
0;' does. (Incidentally, 'my $x = undef;' suffers from the same
problem, and so I never use it. So, *in my opinion*, 'my $x;' and 'my
$x = undef;' are both equivalent unclear constructs, and ought to be
avoided.)

They are not unclear; they leave $x with a value of undef, which has a
function in Perl similar to SQL's NULL. If you came to Perl from C you
may not yet have realised it's usefulness, as C has no equivalent.

Ben

 

[krakle]

(e-mail address removed) (krakle) wrote in


Your statement is full of half truths. If you don't write 'good' programs,
then bad things surely mya happen. However, I have quite a few CGI scripts
that are being run under mod_perl, and I have yet to run into such an
issue.

Sinan.

Then you don't use mod_perl much. See my example.

 

[krakle]

Did you run that code? Apparently not, since it doesn't even compile
(under strict). Consequently, it does not serve the purpose of
illustrating anything.

some_other_yada ISNT a Perl function or sub-routine. I'm not going to
write an entire Perl script to make a point in one single thread in
usenet when you guys know what i'm talking about. And YES this code
serves a purpose.

The purpose is @message will retain ALL data added to the array in
memory unless it is reset when you run under mod_perl.

The POINT is

my @message = ();

ISN'T bad syntax. I consider it proper.

As I explained in another message in this thread, your theory is
incorrect, and if you had written real code and run it, you'd have found
out for yourself.

It ISN'T incorrect at all. Have you even used mod_perl??? It keeps the
scripts in memory. And a global variable that does NOT reset it self
or assign itsself a value immediatly before an action will retain the
pervious sessions data.

Wow I can't believe the people here...

 

[A. Sinan Unur]

(e-mail address removed) (krakle) wrote in

Then you don't use mod_perl much. See my example.

Your example is bad code.

It is true that you will have problems if you do:

my $q = CGI->new;

sub mysub {
my $value = $q->param('some_param');
...
}

you will have problem, but you should not be doing that kind of thing
anyway whether your script is running under mod_perl or not.

Sinan.

 

[Gunnar Hjalmarsson]

It ISN'T incorrect at all. Have you even used mod_perl???

Yes. But I have to admit that it has only been CGI scripts run under
Apache::Registry and similar.

The point I was trying to make is that package variables and lexically
scoped variables behave differently in this respect. However, see
Brian's message in this thread. Even if I haven't seen file scoped
lexicals retain their values, I trust that Brian knows what he is
talking about.

 

[A. Sinan Unur]

The point I was trying to make is that package variables and lexically
scoped variables behave differently in this respect. However, see
Brian's message in this thread. Even if I haven't seen file scoped
lexicals retain their values, I trust that Brian knows what he is
talking about.

Gunnar,

You were correct. What krakle is krakling about is summarized here:

http://perl.apache.org/docs/1.0/guide/porting.html#Exposing_Apache__Regis
try_secrets

He does not understand it but I am sure you will

Sinan.

 

[Gunnar Hjalmarsson]

Gunnar,

You were correct. What krakle is krakling about is summarized here:

http://perl.apache.org/docs/1.0/guide/porting.html#Exposing_Apache__Registry_secrets

To me, that rather confirms that brian was correct. The handler
subroutine, seemingly top level subroutines behaving as nested ditto, etc...

I for one learned from this exchange of messages that *really* file
scoped lexicals, i.e. top level lexicals in programs that are run under
variants of mod_perl that do not make use of any "handler subroutine",
retain their values. I did not know that before.

 

[A. Sinan Unur]

To me, that rather confirms that brian was correct. The handler
subroutine, seemingly top level subroutines behaving as nested ditto,
etc...

I for one learned from this exchange of messages that *really* file
scoped lexicals, i.e. top level lexicals in programs that are run
under variants of mod_perl that do not make use of any "handler
subroutine", retain their values. I did not know that before.

OK. I misunderstood your earlier statement then. Of course, Brian is
correct. I am re-reading the thread, and it seems like I lost track of
who was saying what at one point.

My main argument was with the statement that krakle made regarding the
necessity of resetting package lexicals. That necessity only arises from
when good programming discipline is not followed, IMHO.


Sinan.

 

[krakle]

OK. I misunderstood your earlier statement then. Of course, Brian is
correct. I am re-reading the thread, and it seems like I lost track of
who was saying what at one point.

My main argument was with the statement that krakle made regarding the
necessity of resetting package lexicals. That necessity only arises from
when good programming discipline is not followed, IMHO.


Sinan.

mod_perl is my primary use for the web. In the example I gave it would
retain the values from the previous session.

 

[David Gale]

Wait, you're saying that the perl interpretter doesn't just skip the
unnecessary assignment?

~% perl -MO=Concise -e'my $x = undef'
6 <@> leave[1 ref] vKP/REFC ->(end)
1 <0> enter ->2
2 <;> nextstate(main 1 -e:1) v ->3
5 <2> sassign vKS/2 ->6
3 <0> undef s ->4
4 <0> padsv[$x:1,2] sRM*/LVINTRO ->5
-e syntax OK

Note the sassign and the undef; so no, it doesn't.

Huh. Well, that's new to me.

I did say a trivial waste. I would bet that it almost never makes any
difference, so it's not worth the optimizer finding it.

Yes, I'd tend to say that if this optimization is enough to make a
noticeable difference in your code, well, you've got a bigger problem to
worry about.

What, like shell and awk?

Actually, C was what I was thinking of; when I was in school, C was the
default language, and, from what I've seen, extremely common in business
programming as well. Of course, I must confess to not knowing Fortran or
COBOL, so I don't know if those required explicit initialization or not,
though I do know that both were very widely used.

Not true. I am familiar with Perl; however, although I had a little
knowledge of C when I learned Perl most of my background was in BASIC
and FoxPro, which do not require explicit initialization. When someone
puts an explicit initial value in, it makes me think immediately that
there is some reason why that value a. is not there anyway and b. is
necessary (I tend to start with the assumption that the writer of the
code wasn't a fool). If I can't see any obvious reason for it it makes
me worry for a minute that there is something going on that I don't
understand, which is not a kind thing to do to a reader of your code.

Hrm, always fun to see what preconceptions different people have. My early
programming was in BASIC, quickly supplanted by C; I honestly couldn't have
told you whether you needed to initialize BASIC variables or not. I do find
that, for me, at least, seeing an explicit variable initialization helps,
since I immediately without thinking, "Oh, this variable has that value".
And, of course, this is especially helpful when reading through code in a
language that I'm not intimately familiar with--imagine a language with a
default numeric value of pi, for instance. If you didn't know that and ran
across an uninitialized variable in someone's code, it could be, well,
confusing.

Languages which require explicit initialization are by no means as
common as those which do not.

Last I checked, C/C++ was very, very common. Of course, that might just be
because there are many Windows programs these days, a large number of them
written in the same language the OS is. Of course, I haven't done any sort
of survey...

NO! They are both false, yes; but they are *NOT* equivalent, and are
*NOT* equivalent to undef. I will occasionally write something like

my $x = '';

where I wish to avoid uninit value warnings, or am going to use undef
as a flag later, or something; and that initialization tells the
reader that there is some reason why the default initial value of
undef won't do.

Ok, I stand corrected. My statement (and most of my subsequent argument)
was based on my personal programming style, in which I rarely leave a
variable undefined for long, so I rarely need the defined check (unless,
like you suggested, I'm using undef as a flag), and since I know that a
scalar is initialized to a numeric/string 'false' value based on what it'll
be used for, I tend to think of the false values as being equivalent.

A quick check shows that ('' == 0) is true, while ('' eq 0) is false; this
makes sense, of course. However, since I keep numeric variables and string
variables separate, I don't do cross-type checking, so I've not been
bothered by this difference.

So I stand guilty of arguing a position based on my personal coding style.
And, of course, I feel that there are enough benefits to my personal style
that I think everyone else ought to follow it as well.

NO THEY ARE NOT.

Again, you're right, and I'm wrong.

But I do still feel that this is right.

I said noting about 'expert', and nothing about 'instant'. You should
read enough about the language to understand how it works before
writing (real) code in it. I would have thought this was obvious.

You know, as was demonstrated at the very beginning of this post, I still
don't know how Perl works. Sure, I know a goodly percentage of the syntax,
and I know enough of it to get it to do everything I need it to, but I sure
don't know what the optimizer is doing, and I'll confess that I periodically
look stuff up in my "Programming Perl" book (it's right here next to my
keyboard as I'm typing this). And yet I use Perl pretty much every day at
the office, and consider it to be my strongest programming language
currently. (I've also heard rumor that Ada is so complex that no single
programmer fully understands it, and so the military uses it, but that
smacks of Urban Legend to me...)

If I were to hire on at a job and they told me that they needed a Prolog
program upgraded, I'd get a good reference and learn enough of that to get
the job done. If I waited until I knew fully how Prolog works, I know I'd
miss far more deadlines than I'd hit.

To me, the obvious statement is that you need to know enough of how the
language works to get the job done.

Yes, I use subs, because they are a feature of *Perl*. I do not
explicitly initialize variables where I don't need to, because such
initializations not being required is a feature of *Perl*.

What about, oh, proper indentation? That's not a feature of Perl; in fact,
if anything, Perl would seem to encourage improper indentation, since it
treats all white space as equivalent. Other languages, such as Python,
*require* proper indentation.

They are not unclear; they leave $x with a value of undef, which has a
function in Perl similar to SQL's NULL. If you came to Perl from C you
may not yet have realised it's usefulness, as C has no equivalent.

I do use undef variables, but only when I feel I need them. This, in my
opinion, is a good case of "teach the rules to protect the student; when he
is wise enough, he will find that some rules are breakable--but he will
break them only when necessary." If you use uninitialized variables
frequently, you can end up with buggy or harder-to-read code (eg., "if(
defined($x) and $x ne '' )" vs "if( $x ne '' )" ).

 

[John W. Kennedy]

This is off-topic for a Perl NG, but you brought it up, and I feel the
need to correct this misinformation. That would indeed be an Urban
Legend. I have programmed in both Ada (many years ago) and C++ (for the
past 9 years) and IMHO Ada is no where near as complex as C++. The
reference manual for Ada 83 is 330 pages, and that includes 20 pages on
Tasks, which Ada has built-in and C++ does not. Ada 95 added many more
features, but they are all optional and backwards compatible with Ada
83. (I do not have an Ada 95 reference manual.)

Another reason for complexity in Ada is that Ada, PL/I, and Java are
just about the only important languages with strictly defined semantics
(Java's only as a product of the JavaVM). The complexities of Ada weigh
far more on the writer of an Ada compiler or an Ada RTL than they do on
an Ada programmer.