•Re: Creating an Intermediate Perl Programming Curriculum
by merlyn (Sage) on May 03, 2004 at 21:25 UTC
|
You could follow the model that Stonehenge uses, with the Llama book for the Perl introduction levels, and the Alpaca book for the areas you seem to want to cover. Feel free to steal ideas from that book. Just don't steal the precise words... for that, you'll need to buy a copy. {grin}
| [reply] [Watch: Dir/Any] |
Re: Creating an Intermediate Perl Programming Curriculum
by hv (Prior) on May 03, 2004 at 21:48 UTC
|
| [reply] [Watch: Dir/Any] |
|
<shameless type='plug'>
modules: diagnostics, Carp, Data::Dumper, Devel::Peek
I must admit my hopes are such that one day people will include DDS in that list, especially when that list is intended for debugging. DDS is much more accurate than DD, easier to read, and now that I provide a 'DDS' alias much easier to type too. :-) In addition I'm working right now on a ':Peek" export tag that will include the standard Devel::Peek stuff as well. :-) So that
use DDS ':Peek';
will do more or less the same thing as
use Data::Dumper;
use Devel::Peek;
The only problem is I want to load Devel::Peek dynamically and export Devel::Peek::Dump as Peek(), but i havent worked out how to do it without changing the refcounts of the arguments yet. Ill figure it out soon, and then expect to see v 1.11 with Peek support included.
</shameless>
---
demerphq
First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi
| [reply] [Watch: Dir/Any] [d/l] [select] |
Re: Creating an Intermediate Perl Programming Curriculum
by hardburn (Abbot) on May 03, 2004 at 21:25 UTC
|
- I wouldn't have the ST in there at all, or I would make it one of the finishing things. It's not the easiest thing to get your head around (though once you do, you won't have many problems using it).
- Using modules should come before creating modules
- One vastly overlooked area of Perl tutorials is handling error messages. Error messages that spew out of perl can be quite intimidating, and sometimes completely wrong. Knowing when perl is just plain full of crap is a skill which I doubt anyone has mastered, but the process could be helped along by a few good examples.
----
: () { :|:& };:
Note: All code is untested, unless otherwise stated
| [reply] [Watch: Dir/Any] [d/l] |
Re: Creating an Intermediate Perl Programming Curriculum
by talexb (Chancellor) on May 03, 2004 at 21:44 UTC
|
Having listened to Schwern do a lightning talk at YAPC 2001 about how the AUTOLOAD syntax was broken for a particularly odd case of inheritance (I think my brain started to melt after the first minute), I've generally been successful at avoiding AUTOLOAD. Unless your folks are fairly up to date on OO programming, I'm not sure they'll get AUTOLOAD, which seems to magically instantiate object methods as necessary (shudder).
Instead, I'd recommend something like Class::MethodMaker -- that's pretty cool OO stuff, and it's something they can probably use right off the bat.
I'd also highly recommend some time on Perl one-liners and on the Perl debugger.
Alex / talexb / Toronto
Life is short: get busy!
| [reply] [Watch: Dir/Any] |
Re: Creating an Intermediate Perl Programming Curriculum
by Sandy (Curate) on May 03, 2004 at 22:01 UTC
|
What are the skills of the students with respect to general programming skills?
I have had the misfortune of taking a few too many "C++" courses that focussed on... "how does a for loop work". Having programmed for 20yrs, I know how a for loop works, even if I don't know the C++ syntax.
Then one day, I took a course for C++ aimed at those people who were truly proficient programmers, but who had never touched OO (or C++). That is when I truly learned something.
My moral... before you decide on your curicullum, decide who you want to teach to... perl newbies, but programming 'aware' ... or perl relative newbies and programming 'sorta'.
Sandy | [reply] [Watch: Dir/Any] |
Re: Creating an Intermediate Perl Programming Curriculum
by toma (Vicar) on May 03, 2004 at 22:08 UTC
|
I agree with skipping AUTOLOAD and the
Schwartzian Transform,
and adding something on Data::Dumper and perhaps the
debugger. Using ptkdb results in the fastest
learning. I asked instructors at a conference BOF
meeting why they didn't use ptkdb for teaching, and
the only reason cited was the difficulty of installing
ptkdb on the local machines before the class.
A debugger gives you a chance to step through a
program and quickly
hover over variables to show how they have changed.
They are good for learning and reading code,
even if your own day-to-day coding challenges
don't benefit from using them.
For objects, I would just teach how to create a hash
and bless a reference to it. Then show how
to use references as hash values to make a more
complex object. I struggled with teaching various
automatic-object-creation modules until I found that the
hash explanation works better.
I also like to explain common design antipatterns to
intermediate programmers, since they tend to be
familiar with them! 'The Big Ball of Mud' is a good
story to go along with the learning about object-from-hash-reference.
It should work perfectly the first time! - toma
| [reply] [Watch: Dir/Any] |
Re: Creating an Intermediate Perl Programming Curriculum
by geekgrrl (Pilgrim) on May 04, 2004 at 15:47 UTC
|
Two major things to teach: References and Modules.
I find that one of the most important concepts in Perl is references. So many decent Perl programmers never take it to the next level by getting their heads around this one. Also, writing modules, whether OOP style or not, is an important skill to take the beginning script writer to that of a Perl programmer with mad skills.
I have taken many beginner scripts - the style where they are required in another program, and turned them into simple modules. It makes so much difference and greatly extends the usability of the code.
Also, I second the motion of teaching Data::Dumper. This is the best module in the entire world. Also - it's handy for understanding references. | [reply] [Watch: Dir/Any] |
Re: Creating an Intermediate Perl Programming Curriculum
by cLive ;-) (Prior) on May 04, 2004 at 08:14 UTC
|
# foreach vs. for
Err, and the fact that they are exactly the same, just easier to read, depending on context. For example, these just don't flow through the brain as comfortably:
foreach (my $i=0; $i<10; $i++) {
print "$i\n";
}
for my $i (0..9) {
print "$i\n";
}
But I know what you mean :)
cLive ;-) | [reply] [Watch: Dir/Any] [d/l] |
|
s/foo/nofoo for @array;
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
$ perl -le 'print foreach 1, 2, 3'
1
2
3
| [reply] [Watch: Dir/Any] [d/l] [select] |
Re: Creating an Intermediate Perl Programming Curriculum
by cLive ;-) (Prior) on May 04, 2004 at 08:20 UTC
|
# general rule 1
use strict;
use warnings;
# general rule 2
#!/usr/bin/perl -T
- unless you know you don't need it
# general rule 3
Don't just use -T and then untaint everything with /(.*)/
- unless you know why
# CGI Rule 1
#!/usr/bin/perl -T
use strict;
use warnings;
# CGI Rule 2 (when testing)
use CGI::Carp 'fatalsToBrowser'
cLive ;-) | [reply] [Watch: Dir/Any] [d/l] |
|
# CGI Rule 3 (when in production)
# never ever use CGI::Carp 'fatalsToBrowser';
Jenda
Always code as if the guy who ends up maintaining your code
will be a violent psychopath who knows where you live.
-- Rick Osborne
Edit by castaway: Closed small tag in signature | [reply] [Watch: Dir/Any] [d/l] |
Re: Creating an Intermediate Perl Programming Curriculum
by zentara (Archbishop) on May 04, 2004 at 13:05 UTC
|
I'm probably not the "most qualified" person to tell you how to teach, but from my experience, just show alot of working examples.
Most people are NOT able to grasp details right away, so show them alot of working code, walk thru the code step by step, and tell them where to read about the details. Most people feel they "really gained something", if they have a few code samples which they can take, modify and run. It empowers them, and "wets their pallette" so they want to learn more.
I'm not really a human, but I play one on earth.
flash japh
| [reply] [Watch: Dir/Any] |
Re: Creating an Intermediate Perl Programming Curriculum
by nmcfarl (Pilgrim) on May 04, 2004 at 16:34 UTC
|
So what brings a beginner up to the next level? Well you have the core, better regexs, references, module use and creation, and OO modules.
The one thing that I don't see listed but think is important is list processing. The appropriate use of map and grep can make programs shorter and much more readable. I think it's a core skill that is often overlooked.
I definitely recommend module use be stressed before you move on to module creation. But when you do move on I find it useful, depending on the audience, to mix OO with the modules and packages discussions. The implementation of OO Perl makes it ideal for clarifying, questions on modules and packages. It also allows you to put off dealing Exporter( and it's difficulties), while still getting working, idiomatic perl modules written.
| [reply] [Watch: Dir/Any] |
Re: Creating an Intermediate Perl Programming Curriculum
by bronto (Priest) on May 04, 2004 at 16:58 UTC
|
Nice topic :-)
To all other monks said I'd just add a few things. First, about OOPerl you skip from basics to AUTOLOAD directly. I believe that they should first understand how AUTOLOAD works, even without knowing about objects; when coming to objects it will be clearer what they can do with it and, more important, they will easily get why if they use AUTOLOAD in OOP they also should define a DESTROY method (in general)
Second, I'd teach them when to use objects and when leave them alone. I am dealing with another programmer's script that uses classes as... "configuration objects" (I don't even know how to call them!!!), e.g.: my $dir = MyProg->workdir ; my $login = MyProg->login and so on; those "classes" don't even have a constructor!!! Even if this could be not completely wrong, I personally consider it as really-bad-style, definitely. And when I need objects to get configuration variables I use AppConfig or similar modules (which you could also like to illustrate to your students).
My 2 cents (of Euro:-)
Ciao! --bronto
The very nature of Perl to be like natural language--inconsistant and full of dwim and special cases--makes it impossible to know it all without simply memorizing the documentation (which is not complete or totally correct anyway).
--John M. Dlugosz
| [reply] [Watch: Dir/Any] [d/l] |
Re: Creating an Intermediate Perl Programming Curriculum
by parv (Parson) on May 05, 2004 at 07:31 UTC
|
One thing, not explicitly mentioned, that everybody should learn, i
think, is seeing how a regex is matched and parsed via -Dr switch
(perlrun(1)).
If/When you cover Schwartzian Transform (ST), consider covering a
modified form of ST: Guttman-Rosler Transform. Around those two
transforms, you could (re)introduce (un)pack functions.
After the coverage of references and around coverage of AUTOLOAD,
symbol table manipulation, say for creating methods/subs, does not
seem too much of a stretch.
| [reply] [Watch: Dir/Any] |