When to "use strict" when teaching?

[Simon Andrews]

I'm thinking about putting together a a series of evening classes at
work for a group of people who are interested in learning Perl. I'm
just thinking about how to split things up and the best approaches to
take. A couple of quetions presented themselves and I though I'd
solicit opinions from others who have done this sort of thing before.

1) When do you think it's best to introduce strictures into the programs
people write. Many moons back I learnt Perl using Learning Perl, which
I found to be excellent, but looking back I see that it doesn't
introduce the concept of strictures into any of the basic exercises. I
remember that adapting my programming to using strictures was one of the
harder things I had to get my head around, and I wonder if it would have
been easier to have started off by writing all programs under warnings
(+diagnostics) and strict?

2) How much Perl do you reckon people can comfortably take in one
sitting? I'm in the nice position of being able to spread the training
in short sesssions over several weeks so that people don't get
overloaded (most will never have done any programming before at all).
Most technical courses I've seen suffer from throwing too much
information at people which results in them not retaining much of it. I
was thinking of 1.5 hours at a stretch and maybe 10 sessions in total
(with exercises in between), to give them a good introduction to the
language.

Any thoughts / advice appreciated.

TTFN

Simon.

 

[Brian McCauley]

I'm thinking about putting together a a series of evening classes at
work for a group of people who are interested in learning Perl. I'm
just thinking about how to split things up and the best approaches to
take. A couple of quetions presented themselves and I though I'd
solicit opinions from others who have done this sort of thing before.

1) When do you think it's best to introduce strictures into the
programs people write.

From the outset put the shebang line, "use strict" and "use warnings"
at the top of all your programs. Mention in passing that use strict
"disables some feature that are mostly for Perl4 backward
compatability" and maybe add that "in the advanced course you will
encounter a few situations when you still want to use some of these
features".

Many moons back I learnt Perl [...] I wonder if it would have been
easier to have started off by writing all programs under warnings
(+diagnostics) and strict?

It would.

 

[Juha Laiho]

I'm thinking about putting together a a series of evening classes at
work for a group of people who are interested in learning Perl. I'm
just thinking about how to split things up and the best approaches to
take. A couple of quetions presented themselves and I though I'd
solicit opinions from others who have done this sort of thing before.

I haven't (been teaching Perl, that is), so don't put too much weight
on my words.

1) When do you think it's best to introduce strictures into the programs
people write. Many moons back I learnt Perl using Learning Perl, which
I found to be excellent, but looking back I see that it doesn't
introduce the concept of strictures into any of the basic exercises. I
remember that adapting my programming to using strictures was one of the
harder things I had to get my head around, and I wonder if it would have
been easier to have started off by writing all programs under warnings
(+diagnostics) and strict?

I think I'd try to get the students use warnings and strictures from the
start. But this depends on how much things your students allow as "just
do it this way", without questioning and/or requiring in-depth explanation.

I also had hard time when I moved to use strictures - and Perl wasn't
my first language.

2) How much Perl do you reckon people can comfortably take in one
sitting? I'm in the nice position of being able to spread the training
in short sesssions over several weeks so that people don't get
overloaded (most will never have done any programming before at all).

Here you have another challenge -- introducing people to the idea of
programming. This'll be the hard one, because you'll need to teach
at least some of the base abstractions:
- variables
- flow control (branching and looping)
- boolean logic (for controlling the above)
- modularity, reuse (subroutines)
- structured data (arrays, hashes)

Most technical courses I've seen suffer from throwing too much
information at people which results in them not retaining much of it. I
was thinking of 1.5 hours at a stretch and maybe 10 sessions in total
(with exercises in between), to give them a good introduction to the
language.

That's not too much, but could be enough for basics.

 

[Paul Lalli]

I'm thinking about putting together a a series of evening classes at
work for a group of people who are interested in learning Perl. I'm
just thinking about how to split things up and the best approaches to
take. A couple of quetions presented themselves and I though I'd
solicit opinions from others who have done this sort of thing before.

I taught Perl for 4 semesters at Rensselaer Polytechnic Institute, so take
that for what it's worth...

1) When do you think it's best to introduce strictures into the programs
people write. Many moons back I learnt Perl using Learning Perl, which
I found to be excellent, but looking back I see that it doesn't
introduce the concept of strictures into any of the basic exercises. I
remember that adapting my programming to using strictures was one of the
harder things I had to get my head around, and I wonder if it would have
been easier to have started off by writing all programs under warnings
(+diagnostics) and strict?

I taught use warnings; and use strict; on the first first day, I believe
within the first five slides. I told all the students that they were both
technically optional "but extraordinarily recommended". For my
programming assignments in class, I tried to always use strict; in the
solutions, but occasionally forgot (because like many, *I* was not taught
strictures to begin with either).

2) How much Perl do you reckon people can comfortably take in one
sitting? I'm in the nice position of being able to spread the training
in short sesssions over several weeks so that people don't get
overloaded (most will never have done any programming before at all).
Most technical courses I've seen suffer from throwing too much
information at people which results in them not retaining much of it. I
was thinking of 1.5 hours at a stretch and maybe 10 sessions in total
(with exercises in between), to give them a good introduction to the
language.

Our classes were scheduled for 2 hours a day, one day a week, for the
entire semester (about 13 weeks). About half the time, the class let out
within 90 minutes.

If you're insanely curious, the course webpage from the last semester I
taught can still be found at http://www.cs.rpi.edu/~lallip/perl/spring03

Paul Lalli

 

[Charlton Wilbur]

JL> I think I'd try to get the students use warnings and
JL> strictures from the start. But this depends on how much things
JL> your students allow as "just do it this way", without
JL> questioning and/or requiring in-depth explanation.

Students tend not to like being told "Just do it this way, because I
said so" -- but they're often willing to put up with "Do it this way
for now; there are times you will want to do something differently,
but I can't explain everything at once, and this is something I'll
explain later." Especially if you actually *do* explain bits of it
later on.

Charlton

 

[Jim Keenan]

1) When do you think it's best to introduce strictures into the programs
people write.

I don't fundamentally disagree with the other posters to this thread who
say, "Use 'use strict;' from the start." However, I want to note that there
exists at least one alternative approach. In Learning Perl ("llama"), 3rd
edition, Randal Schwartz introduces 'use warnings;' in Chapter 2 (Scalars)
but defers 'use strict;' until Chapter 4 (Subroutines). When I last taught
introductory Perl, I used Randal's book and followed his approach for at
least the first 6 chapters.

2) How much Perl do you reckon people can comfortably take in one
sitting? I'm in the nice position of being able to spread the training
in short sesssions over several weeks so that people don't get
overloaded (most will never have done any programming before at all).

The latest edition of the llama book benefits from Randal's/Stonehenge's
experience in teaching Perl many times. Each chapter is designed to fit
into a 45-minute presentation. I suspect that they are generally teaching
Perl to already experienced programmers. My teaching experience was mainly
with programming novices; I generally covered 2 chapters in a 140-minute
session.

jimk

 

[Tad McClellan]

I'm thinking about putting together a a series of evening classes at
work for a group of people who are interested in learning Perl. I'm
just thinking about how to split things up and the best approaches to
take. A couple of quetions presented themselves and I though I'd
solicit opinions from others who have done this sort of thing before.

There is a mailing list where Perl trainers hang out to discuss
just such things:

A discussion list for people who teach Perl.
http://lists.perl.org/showlist.cgi?name=perl-trainers

[ mention this thread if you also ask there. ]

1) When do you think it's best to introduce strictures into the programs
people write.

As soon as you've covered scoping.

Many moons back I learnt Perl using Learning Perl, which
I found to be excellent, but looking back I see that it doesn't
introduce the concept of strictures into any of the basic exercises.

It does in the 3rd edition, right after it's covered scoping.


[ not in the 1st edition: use strict was introduced in Perl 5,
after the Llama 1e was published.
not in the 2nd edition: too many folks were still using Perl 4
and it would have confused them when it
didn't work.

But you can't take my word for it, I am very biased.
]

I
remember that adapting my programming to using strictures was one of the
harder things I had to get my head around,

Strictures is easy.

Scoping is hard.

Are you sure you've fingered the right culprit?


This will be helpful when you teach scoping in Perl:

"Coping with Scoping":

http://perl.plover.com/FAQs/Namespaces.html

and I wonder if it would have
been easier to have started off by writing all programs under warnings
(+diagnostics) and strict?

Now you've changed it into a 2-pronged question, and I (at least)
would give different answers for the 2 parts.

I would agree to introduce warnings right near the start, after
a "hello world" program or two.

Strictures need to wait until they've seen scoping.

2) How much Perl do you reckon people can comfortably take in one
sitting? I'm in the nice position of being able to spread the training
in short sesssions over several weeks so that people don't get
overloaded

That is indeed a very nice position.

(most will never have done any programming before at all).

That would, in my estimation, double the time needed for getting
to where they can write Perl programs that get their jobs done.

Most technical courses I've seen suffer from throwing too much
information at people which results in them not retaining much of it.

That is very true.

I
was thinking of 1.5 hours at a stretch and maybe 10 sessions in total
(with exercises in between), to give them a good introduction to the
language.

15 hours seems pretty short.

I get 28 contact hours in a typical Stonehenge class, with an
"already programmed in some other language" prerequisite, and
there are _still_ things I want to say but don't have time to say.

(of course, it may be that I'm just a bigmouth...)

 

[Tad McClellan]

JL> I think I'd try to get the students use warnings and
JL> strictures from the start. But this depends on how much things
JL> your students allow as "just do it this way", without
JL> questioning and/or requiring in-depth explanation.

Students tend not to like being told "Just do it this way, because I
said so" -- but they're often willing to put up with "Do it this way
for now; there are times you will want to do something differently,
but I can't explain everything at once, and this is something I'll
explain later." Especially if you actually *do* explain bits of it
later on.

I would agree for "use strict".

For "use warnings" an in-depth explanation shouldn't be needed,
a "what's in it for me?" explanation ought to win them over, so
you can introduce warnings straightaway.

I tell them:

I've programmed in Perl every day for eight years, and _I_
want the help that warnings offers me.

You, as beginners, should want it even more than I do, as
you are even more likely to make the "common mistakes" that
warnings are designed to find.

Then later in the training there are 4 or 5 places where warnings
would have caught the problem being discussed, and I give them:

Without warnings you would have just gotten "strange output",
scratched your head, and launched a debugging session that
could last minutes or hours.

With warnings the problem would have been found in a few milliseconds.

Warnings are optional, you get to choose which way you would
prefer to operate.

 

[Matt Garrish]

15 hours seems pretty short.

I get 28 contact hours in a typical Stonehenge class, with an
"already programmed in some other language" prerequisite, and
there are _still_ things I want to say but don't have time to say.

15 hours should be ample time to begin to get a grasp on regular
expressions, and regexes are so key to Perl (IMHO) it seems almost pointless
to not lay that foundation first. I suppose you have to bear in mind that he
is only proposing an informational session. I suspect that you would be
teaching programmers who need a crash course in the language, whereas his
audience might be happy if they can open files and modify the contents at
the end.

To the OP, I would try and establish what it is your users would most
benefit from learning (be it regexes, Perl for cgi, or whatever) and just
focus on that particular aspect. Once they're up and running they'll
hopefully do the research necessary to build on the foundation.

Matt

 

[Helgi Briem]

From the outset put the shebang line, "use strict" and "use warnings"
at the top of all your programs. Mention in passing that use strict
"disables some feature that are mostly for Perl4 backward
compatability" and maybe add that "in the advanced course you will
encounter a few situations when you still want to use some of these
features".

Now that's the correct way to introduce strictures and warnings.

Way to go, Brian.

Now, if only that made it's way into the FAQ.

 

[Mark Jason Dominus]

1) When do you think it's best to introduce strictures into the programs
people write.

When I do three-day intro classes, I introduce subroutines early in
the afternoon of day 2. The next section of the class is about 'my'
variables, because there's no use for 'my' variables until your
programs are big enough to need to have subroutines. The section of
'my' variables discusses 'strict vars', but not either of the other
strictures, which are less useful.

The motivation for all three features is similar. You want
subroutines for modularity and reusability. Subroutines that refer to
global variables are neither modular nor reusable, so you need 'my'
variables. And 'strict vars' helps you remember to declare the
variables.

I don't cover 'strict refs' until the following afternoon, after we've
seen references; then I can discuss the serious and untraceable
problems that can be caused by accidental use of symbolic references.

I never discuss 'strict subs' at all. It's not worth the time.

I think the philosophy that says that you should always have 'use
strict' at the top of every program from the start of day one is
misguided. The theory is that you're training people to follow good
programming practices. But this theory somehow manages to forget that
putting stuff into your program when you don't know what it does is
the very worst of all possible programming practices.

The folks who piss and moan the loudest about cargo-cult programming
practices and Matt's Script Archive and soforth are always the ones
who are proclaiming most loudly that you Must Always Use Strict. It
seems that what they really want is for people to join *their* cargo cult.

More generally, I have a philosophical problem with commanding people
to do things when they don't understand why. I don't think people
should be trained to follow instructions without understanding the
policy, and I don't want to participate in doing it. My job, as a
teacher, is to make people wise and powerful, and saying "just do this
all the time even though you don't know what it's for" is a the way to
make them weak and stupid.

 

[Sherm Pendley]

From the outset put the shebang line, "use strict" and "use warnings"
at the top of all your programs. Mention in passing that use strict
"disables some feature that are mostly for Perl4 backward
compatability"

That's a great way to describe what strict does.

I've often wondered whether newbies' reluctance towards strictures is based
on the negative connotations of the word "strict." The word implies a harsh
taskmaster who won't let his students have any fun. So newbies avoid it and
feel like they're getting away with something.

Perhaps something that helped portray strictures in a positive light, like
"use modern" or "more help", would have been a better choice.

sherm--

 

[Robert]

Brian McCauley wrote:




That's a great way to describe what strict does.

I've often wondered whether newbies' reluctance towards strictures is based
on the negative connotations of the word "strict." The word implies a harsh
taskmaster who won't let his students have any fun. So newbies avoid it and
feel like they're getting away with something.

Perhaps something that helped portray strictures in a positive light, like
"use modern" or "more help", would have been a better choice.

sherm--

I am a newbie and I definately use both "strict" and "warnings". I
lurked in the newsgroups (you all said use 'em) and I am going through
the "Elements of Programming" book by Johnson and he said use them.

 

[Robert]

Hmmm.... Not a Perl trainer, though I am certified (-able?)
in a few other subjects.

But, I'd think something along the lines of:


Excercise #1

#! /usr/bin/perl

print "Hello World!\n";

exit;


Excercise #2

#! /usr/bin/perl

my $string = 'Hello World!';

print "$string\n";

exit;


Excercise #3

#! /usr/bin/perl

my $string = 'Hello World!';

print "$striing\n";

exit;


Excercise #4

#! /usr/bin/perl -w
use strict;

my $string = 'Hello World!';

print "$striing\n";

exit;


#4 lets students see for themselves the advantage
of Perl doing the drudge work.....

Just a thought....


s.

Ah...as a newbie looking at code I don't see "exit;" used much. Could
you enlighten me on the "why"?

 

[Tad McClellan]

Ah...as a newbie looking at code I don't see "exit;" used much. Could
you enlighten me on the "why"?

Sure, if you could enlighten us as to why you think it should be "used much".




perl will call exit( 0 ) when it "falls off" the end of your program.

perl will call exit( !0 ) when you call die().

It isn't _needed_ much, so it isn't used much.

 

[Ben Morrow]

Ah...as a newbie looking at code I don't see "exit;" used much. Could
you enlighten me on the "why"?

It's useless there: dropping off the end is a perfectly acceptable way
to exit a Perl program. It's mostly used by C programmers, where
things are done differently...

Ben

 

[Ben Morrow]

I never discuss 'strict subs' at all. It's not worth the time.

Many's the time I've wished for a sort-of 'inverse no strict 'subs'',
which treats barewords as calls to undeclared subroutines rather than
stringifying them. Inventing subs that don't exist is much less
dangerous than inventing variables, because you can't call a sub
unless it's there.

Ben

 

[Peter Scott]

I'm thinking about putting together a a series of evening classes at
work for a group of people who are interested in learning Perl. I'm
just thinking about how to split things up and the best approaches to
take. A couple of quetions presented themselves and I though I'd
solicit opinions from others who have done this sort of thing before.

1) When do you think it's best to introduce strictures into the programs
people write.

I put them in every program, starting with the first one. Even though the
first one is Hello World, and I'm explaining how to print a string, I say,
"These lines at the top go in every program, and I'll explain them later."
And later on, I do, at a time when I can also show the devastating
consequences for development of leaving them out. The very first thing people
need to know is not how a shebang line works, nor what strict does, but
I'm tired of seeing people leave strict/warnings out because they've seen
programs without them and figured they didn't need to learn what they were for.

And I don't buy the argument that you shouldn't tell people to use strict/warnings
unless you also explain everything they do down to symbolic vs hard references.
I don't need to know how my airbag works in order to be protected by it. I can
learn that later at an appropriate time.

2) How much Perl do you reckon people can comfortably take in one
sitting?

This of course varies considerably depending on the people, the instructor,
the material...

I was thinking of 1.5 hours at a stretch and maybe 10 sessions in total
(with exercises in between), to give them a good introduction to the
language.

Sounds highly reasonable.

 

[Uri Guttman]

TM> Sure, if you could enlighten us as to why you think it should be
TM> "used much".

TM> It isn't _needed_ much, so it isn't used much.

i like to use it in some shorter scripts to mark the end of the main
code. i organize them like this:

declarations and stuff

handle args

call top level subs (only a few calls. if more, wrap that in a sub!)

exit - mainline logic is done. the rest is subs.

sub code ....


that makes it very easy to see and modify the top level logic.

i have seen too many scripts which have no subs and are so hard to
follow and modify. even though the top level (and some other) subs are
called only once, they are useful just as an organizing technique.

so i use exit there to tell the reader that the main line code is done.

uri

 

[Uri Guttman]

PS> And I don't buy the argument that you shouldn't tell people to use
PS> strict/warnings unless you also explain everything they do down to
PS> symbolic vs hard references. I don't need to know how my airbag
PS> works in order to be protected by it. I can learn that later at
PS> an appropriate time.

i agree there. sometimes 'cargo cult' without full explanation is proper
as instilling a good habit like strict is important. sure it does need
explanation but it can wait until they know enough perl that they can
understand the issues involved.

uri