When to "use strict" when teaching?

Discussion in 'Perl Misc' started by Simon Andrews, Feb 2, 2004.

  1. 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.
    Simon Andrews, Feb 2, 2004
    #1
    1. Advertising

  2. Simon Andrews <> writes:

    > 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.
    Brian McCauley, Feb 2, 2004
    #2
    1. Advertising

  3. Simon Andrews

    Juha Laiho Guest

    Simon Andrews <> said:
    >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.
    --
    Wolf a.k.a. Juha Laiho Espoo, Finland
    (GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
    PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
    "...cancel my subscription to the resurrection!" (Jim Morrison)
    Juha Laiho, Feb 2, 2004
    #3
  4. Simon Andrews

    Paul Lalli Guest

    On Mon, 2 Feb 2004, Simon Andrews wrote:

    > 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
    Paul Lalli, Feb 2, 2004
    #4
  5. >>>>> "JL" == Juha Laiho <> writes:

    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


    --
    cwilbur at chromatico dot net
    cwilbur at mac dot com
    Charlton Wilbur, Feb 2, 2004
    #5
  6. Simon Andrews

    Jim Keenan Guest

    "Simon Andrews" <> wrote in message
    news:bvlvj6$36g$...
    > 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
    Jim Keenan, Feb 2, 2004
    #6
  7. Simon Andrews <> wrote:
    > 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 SGML consulting
    Perl programming
    Fort Worth, Texas
    Tad McClellan, Feb 2, 2004
    #7
  8. Charlton Wilbur <> wrote:
    >>>>>> "JL" == Juha Laiho <> writes:

    >
    > 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.

    :)


    --
    Tad McClellan SGML consulting
    Perl programming
    Fort Worth, Texas
    Tad McClellan, Feb 2, 2004
    #8
  9. Simon Andrews

    Matt Garrish Guest

    "Tad McClellan" <> wrote in message
    news:...
    > Simon Andrews <> wrote:
    > > 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.
    >


    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
    Matt Garrish, Feb 3, 2004
    #9
  10. Simon Andrews

    Helgi Briem Guest

    On 02 Feb 2004 18:01:04 +0000, Brian McCauley <> wrote:

    >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.
    Helgi Briem, Feb 3, 2004
    #10
  11. In article <bvlvj6$36g$>,
    Simon Andrews <> wrote:
    >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.
    Mark Jason Dominus, Feb 3, 2004
    #11
  12. Brian McCauley wrote:

    > 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--
    Sherm Pendley, Feb 3, 2004
    #12
  13. Simon Andrews

    Robert Guest

    Sherm Pendley wrote:
    > Brian McCauley wrote:
    >
    >
    >>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--
    >

    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, Feb 3, 2004
    #13
  14. Simon Andrews

    Robert Guest

    Steve May wrote:

    > Tad McClellan wrote:
    >
    >>
    >>
    >> 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.
    >>
    >>
    >>

    >
    > 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"?
    Robert, Feb 3, 2004
    #14
  15. Robert <> wrote:

    > 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.


    --
    Tad McClellan SGML consulting
    Perl programming
    Fort Worth, Texas
    Tad McClellan, Feb 3, 2004
    #15
  16. Simon Andrews

    Ben Morrow Guest

    Robert <> wrote:
    > Steve May wrote:
    > >
    > > #! /usr/bin/perl
    > >
    > > print "Hello World!\n";
    > >
    > > exit;

    >
    > 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

    --
    Heracles: Vulture! Here's a titbit for you / A few dried molecules of the gall
    From the liver of a friend of yours. / Excuse the arrow but I have no spoon.
    (Ted Hughes, [ Heracles shoots Vulture with arrow. Vulture bursts into ]
    /Alcestis/) [ flame, and falls out of sight. ]
    Ben Morrow, Feb 3, 2004
    #16
  17. Simon Andrews

    Ben Morrow Guest

    (Mark Jason Dominus) wrote:
    > 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

    --
    don't get my sympathy hanging out the 15th floor. you've changed the locks 3
    times, he still comes reeling though the door, and soon he'll get to you, teach
    you how to get to purest hell. you do it to yourself and that's what really
    hurts is you do it to yourself just you, you and noone else *
    Ben Morrow, Feb 3, 2004
    #17
  18. Simon Andrews

    Peter Scott Guest

    In article <bvlvj6$36g$>,
    Simon Andrews <> writes:
    >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.

    --
    Peter Scott
    http://www.perldebugged.com/
    *** NEW *** http//www.perlmedic.com/
    Peter Scott, Feb 3, 2004
    #18
  19. Simon Andrews

    Uri Guttman Guest

    >>>>> "TM" == Tad McClellan <> writes:

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



    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 ------ -------- http://www.stemsystems.com
    --Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
    Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
    Uri Guttman, Feb 3, 2004
    #19
  20. Simon Andrews

    Uri Guttman Guest

    >>>>> "PS" == Peter Scott <> writes:

    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

    --
    Uri Guttman ------ -------- http://www.stemsystems.com
    --Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
    Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
    Uri Guttman, Feb 3, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. H. Wade Minter
    Replies:
    8
    Views:
    292
    Robin
    Apr 25, 2004
  2. Martina

    why is important to use : use strict?

    Martina, Sep 19, 2005, in forum: Perl Misc
    Replies:
    6
    Views:
    99
    J├╝rgen Exner
    Sep 20, 2005
  3. Ting Wang
    Replies:
    5
    Views:
    173
    John Bokma
    Oct 6, 2005
  4. Peng Yu

    When to use "use strict;"?

    Peng Yu, Jan 25, 2010, in forum: Perl Misc
    Replies:
    14
    Views:
    176
    John Bokma
    Jan 27, 2010
  5. Stefan Ram

    Teaching Java, teaching what?

    Stefan Ram, Dec 8, 2013, in forum: Java
    Replies:
    57
    Views:
    545
    Ali Sh
    Dec 18, 2013
Loading...

Share This Page