My first approach would be to see what the young programmer has written already in VB, and find a task that is suitable for a possible conversion to perl. This means to try to avoid using anything GUI (which is really hard to do in VB, but possible). This way, your student already knows what the logic of the code should be and now should be understanding the perl engine instead.

Another possible first task, if this doesn't pan out, would be to determin a much smaller version of code that is typical of the work this person might do in the future. For example, if he's bound to be a CGI/DB programmer, it might be a good idea to aid him in getting a very simple web-based address book up and running. If he'll be doing XML, have him work on simple client-server calls. Sure, the tasks are pointless to some extent, but the idea it to immerse the person in the language rather than take a step-by-step approach. Mind you, you should help the person break down on subtasks within the mini-project so that he doesn't need to focus on too many perl aspects at the same time.

Of course, all this should be done after giving him sufficient time to read Camel and other books and practice on the topics in there. Ideally, when he is learning, you can point him to certain areas to look at closely, and he'll occasionally ask you questions or clarifications; this is counter to you standing over his shoulder at all times, as well as having him constantly at your desk asking questions and not learning on his own. Make sure to point him to other useful sources of perl info, including perl.com, newsgroups, PM (possibly), and other sources.

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain

I know everyone learns differently and at different speeds, but there must be an art of finding how to teach a particular student a particular task.

Unfortunately I'm not sure if anyone can teach that art, any more than they can teach the art of creating programs from post-it notes. It's something you learn by doing a lot (teaching or translating post-its), preferably by simple lessons, positive re-inforcement and not giving up. (Okay, you can give up on some :) This sort of training is much more like piano lessons than class lectures. It depends as much on your perceptiveness of the student as your talent as a programmer; perhaps more so, since good teaching leads the student into self-development.

Go with your first suggestion, of giving the student small tasks that will result in callable code. That will help your project and emphasize good practices in the student -- compartmentalizing both the learning and the tasks. It is much easier to explain what is good and bad in a 15 line routine than in a 200 line script.

Based on that experience, you'll see some lights coming on as the student applies lessons to things he already knows. (If no lights come on after a large number of lessons, proceed with the giving up.) That will clue you in on how to continue.

Part of my previous job was to "modernize" a bunch of FORTRAN programmers into C and Perl. I made varying progress with each of them, because each was different and responded to help and lessons in their own ways. That experience emphasized to me what I'd found on my own, that there is quite a lot to learn in learning Perl, but the student can write useful code while climbing the learning curve if the lessons were short and built on things the student knew how to do.

The most important thing is to pick up the students where they are.
(Masem already noted this in a way.) You should have a look at the code your student wrote in VB and you need to estimate his skills. Probably one could formalize this with a checklist you could got through which would contain points like

• Does he use for-loops only or does he mix different kinds of loops
• does he use "real" data structures like hashes or is he more the "keep 3 arrays synced"-type

Then you might be happy that you're going to teach perl, because you can stay with the language itself and don't need to introduce the compiler or other ugly stuff.

Do you already have some typical quests in mind he will be doing? Well, then just teach those little tricks first. I have found that most people need the

open(IN,"foo") or die "blah\n$!";
while(<IN>) {
  do_something_with_perls_special $_;
  ($probably,$they,$want,$to) = split(/;/);
  $probably =~ s/$change/$somestring/g;
  perform_some_test() and print "The Result\n";
}
close IN;
[download]

The Camel is not only full of knowledge, it's also really _fun_ to read. I made good experiences pointing that out. Though this may not count for an already experienced programmer.

I once managed to teach a 16-year old school girl (who was good at maths but had no computer experience at all) a little perl coding (including the shell basics and some XEmacs) in just three days. At the end of the third day she was programming a little adress-database (yeah, flat file, but HEY! ... ;-) inluding regexp querys!!

Well, then... Best wishes, all success (you won't need to luck ;) and happy teaching...

Regards...

Stefan

Before you get too far into this project, sit down with your would-be student, his manager, and your manager (all together, or separately depending on your brand of office politics). If you're both willing to tackle this as a personal project, above and beyond your normal duties, that's great -- just make sure you understand each other's limits (can he call/email you at home with questions? will you set up regular lunchtime or after-work meetings?) If not, be sure your respective managers understand that teaching and learning take time, and that will impact whatever else you each have on your plate. Be sure you get clear direction on priorities, accounting/billing for the time you spend on this, and what sort of status updates and/or results they expect to see.

About the only thing I can offer as a teaching suggestion is to try and get a feel for where your pupil is in his understanding of basic programming concepts. Make sure he's up to speed on data structures, algorithms (at least the idea of an algorithm and its relationship to code), program flow control, and some general OO stuff.

If he learned VB by rote, copying and pasting and twiddling here and there, you may need to step back to the fundamentals of being a programmer before getting into the details of being a perl programmer. You might even have him do some exercises in VB (if you know any VB) to assess and/or teach some of this. Once he's got those things firmly implanted in his head, the specifics of any new language will come much easier.

• Teach him the Perl syntax
• Teach him the Perl idioms by asking him to code simple tasks (30 lines max) while you stay by his side and WATCH.
• Show him how to do better (or at least more Perlish)
• Try to spot his weaknesses, and give him the proper advice to correct it
  (some people don't catch recursion, some don't factorized the code, some don't use the appropriate data...)
• Try to spot his strengths, and teach him how to have more fun with Perl by going a little more into the details
• Iterate the previous step letting him handle bigger and bigger code...

The code was a complete mess. The program was dead simple in concept. The kinds of activities that it allowed were copying the clipboard to a named buffer (internally a hash), pasting back out, executing a buffer directly against the clipboard, prepending a string (eg "> ") to the beginning or end of each line, stripping off characters from each line, running the typed in code (eg a substitution) directly. That kind of thing.

However it was something I understood and could use. The simple ability to use Perl to do mass edits to VB source-code gave me lots of flexibility that is old hat to anyone who uses emacs but was new to someone using VB. Trying to do mass edits gave me lots of opportunities to learn regular expressions. And all told that little piece of code, despite its faults, is the single program that I have written for myself that I have used the most. Copy text to clipboard, manipulate, and paste back. Comment out this block. Uncomment it. Take a list of items, turn it into the HTML for a dropdown box. And so on.

I am not saying that this is the project you should give this person. But if you want him to learn Perl, it is good to find some way of making sure that that he uses it and continues to use it for a period of time. And the above piece of silliness worked for me when I was a rank beginner.

Personally the first useful thing that I wrote was a simple program that just ... The code was a complete mess. That reminds me of something .... uhm ... It was my third post at the monks and my first programm: crush_data
... plus the first _hard_ lesson in TIMTOWTDI: merlyn showed the one-liner *grin*
Those were the days...

Regards...

Stefan

My example: I have colleague who belives in complete freedom in programming. As a result, her programs have strange indent, naming variables does not make any sense and same database field has name abbreviated differently in different scripts (I have to read her programs and add features sometimes), and she strongly believes that 'use strict' is wrong because it breakes her "correctly working" code.
My advice: is easier to learn correct way, than un-learn wrong way and re-learn correct after.

You have unique opportunity to set some rules/coding guidelines, do not miss it. Let's be concerned about expressing individuality AFTER achieving mastery.

Update: To former Visual Basic user, you need excellent visual debugger, othervise his first impression will be "perl sucks, VB is better". You are right, there is visual debugger for perl, check Open Perl @ sourceforge.net. Like Visual Basic, only for free. Now your student is hooked in.

pmas
To make errors is human. But to make million errors per second, you need a computer.

While teaching and guiding in proper methodologies, be sure to allow your pupil to express his/her individuality. It's part of what make us human.

Good luck, you'll do great.

I don't really have a comment on this, but I did compile some possibly useful threads:

• 86696
• 95204
• 55265
• perlstyle
• 28799

-OzzyOsbourne

Also, learning to read the online documentation and books for perl is important. The chapter on references use of the word "thingie" had me a little puzzled. Odd, considering I'm good with pointers in C, which is sortof kindof related.

Lastly, be willing to answer any question, regardless of how inane it is. Even the best minds are missing gears on some of the wheels ;)

PS. I don't consider myself good as a teacher, but out of about 10 tries at teaching it, I had 2 successes. The 2 successes were the ones that really just wanted to learn it. They taught themselves pretty well :) Come to think of it, I don't think anyone really taught me a whole lot about programming. I think they just kind of pointed me in the right direction.