--- Deborah Ariel Pickett <[EMAIL PROTECTED]> wrote:
> > Seriously, if they're smart enough to run a text editor, I think
> it's
> > safe to say that they can handle the conceptual difference between
> the
> > "length" (mins:secs) of a video, and the "length" (feet:inches) of
> the
> > mag-tape that encodes the video. People deal with different
> inherent
> > units all the time in the real world -- some of them even remember
> to
> > carry the units through their equations when they're doing math.
> Let's
> > give some credit to the audience at large.
>
> With respect, I have plenty of evidence to suggest that programming
> students *won't* handle the difference (many years of teaching
> first- and second-year programming at University). I see students at
> all levels saying things like:
> char *dupString = malloc(sizeof oldString + 1);
> when they mean:
> char *dupString = malloc(strlen(oldString) + 1);
> (Actually, that's a good argument against using "size" to mean
> number-of-elements of Perl arrays, isn't it?)
It's a good argument for better-explaining the difference between
pointer and target, not something that's likely to be a problem in
Perl.
One of the things I hated about HTML forms was that some things were
WIDTH= and some things were LENGTH= and some things were SIZE= and some
were COLS=. What crackhead smoked that up?
Much more consistent, readable, harmonious -- better -- to say
something like:
sub postoffice_sort(@items)
{
my @bins[10];
for (my $x = 0; my $x < @items.length; $x++)
{
..
}
}
