--- Austin Hastings <[EMAIL PROTECTED]> wrote:
>
> --- 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++)
> {
> ..
> }
> }
Hit the post key too soon, there. Anyway, visualize an example
involving @items.length and $zipcode.length ...
=Austin
