[pm-h] Introductory Perl Help

[G. Wade Johnson]

Thanks for responding. There's some gold in these answers.

On Wed, 23 Oct 2013 13:22:30 -0500 (CDT)
rlharris at oplink.net wrote:

> > 1. Would you be willing to get together for another monthly meeting
> > for mentoring and question answering?
> 
> Eagerly.

Glad to hear it.

> > 2. Would you be willing to do a monthly remote session through
> > something like Google Hangouts, where you could get help?
> 
> If I can figure out how to do it, running Linux.
> 
> This is the first time I have heard about Google Hangouts.  I have not
> used conferencing of any kind, aside from email and a few IRC
> sessions.

I run a Linux system at home and I've had no problems getting Google
Hangouts running. This is actually one of the reasons I'm looking at
Hangouts, really good cross-platform support.

> I am helpless on a Window$ system, and, besides, all my files are on a
> Linux machine, so that displaying them in a Window$ environment would
> be difficult.
> 
> 
> 
> 
> > 3. Would you be more inclined to talk to a single person, or one of
> > a few experts?
> 
> To the student, it should not matter; he should be grateful to anyone
> who is willing to teach me.
> 
> However, for the teacher, one-on-one is, in essence, a consulting
> assignment, for which he normally would receive payment.  However, if
> several experts gather, they have the benefit of camaraderie and
> interaction one with the other, so the experience is less of a chore
> than it is a discussion.

I was thinking more in terms of whether people would be more
comfortable with one person helping or multiple people. I can imagine
it being confusing if we had a large number of people in the group.

> > 4. Would you use this session regularly?
> 
> Unless the techniques become so exotic that I cannot envision their
> applicability to my needs.  I would be interested in mastering almost
> any subject covered in, say, in the O'Reilly book "Learning Perl".

At least for the present, "Learning Perl" would probably be the extent
of the material we would aim for. That is, unless someone had a
specific more advanced question.

> Regular attendance is necessary for a semi-formal course, such as
> going chapter-by-chapter through "Learning Perl".
> 
> But a help session is another matter:
> 
>    => If a project is going well, it is difficult to justify spending
>    an evening in a help session, rather than working on the project.
> 
>    => If things are not going well, it is likely that the next help
>    session is a month away, while the need for help is immediate.

That's a really good point. Monthly may be too infrequent. However, any
immediate issue can always be taken to the mailing list. There are many
experts here that can field a question.

I also usually recommend people actively working in Perl check out the
Perl Monastery (http://perlmonks.org) and Stack Overflow. Both are good
resources for specific questions.

> The best time for a help session is when you are actively working on
> the project (so that the details are fresh in mind), encounter a
> problem, and do not know how to proceed.  All things considered, it
> may be difficult to do better than the Perl mail list, assuming that
> one or two Perl experts monitor the list as a matter of routine.

The list is always available, and several of us check the list pretty
regularly.

One of the problems that has been expressed to me by some has been that
they don't know enough to be able to ask an intelligent question. This
makes them reluctant to expose their lack-of-knowledge on the list.

I'm hoping the session could kind of bridge the gap to get people
moving on their problems and to get them more comfortable with
attempting to ask the list.

> > 5. Would you use this session only when you run into a specific
> > problem?
> 
> This would be my tendency.
> 
> But in seeking a solution to a specific problem, I really should be
> paying for the assistance -- and I would be happy to do so.  Perhaps
> everyone who needs help should bring along a pizza as tuition for the
> session.

I don't know about the other senior people on the list, but I
personally don't have any problem with answering some questions for
free. I'm not going to solve your project for you, of course. But, I'm
comfortable with giving suggestions or helping someone become unstuck.

From past experience, sometime this has involved a bit of time
explaining fundamentals to help someone get moving. And I don't see
that as a problem.

> Still, I think that the problems which I need to solve and for which I
> would turn to Perl are common and that the solutions would be of
> general applicability.
> 
> Rather than a solution to a specific problem, what I need is (1)
> guidance as to the proper approach and the tools to use, and (2)
> detailed tutorial instruction in the use of tools and techniques for
> batch processing of multiple files located in multiple directories.

This is actually a fascinating topic that is worth quite a bit of time.
It's also the kind of problem that's really hard to explain without a
real example. (Every time I've tried to teach this approach with a made
up example, it appears hokey and hard to relate to.)

> A primary goal of any Perl tutorial should be to provide perspective,
> so that the student is made aware of the various techniques which
> could be used to address the problem at hand, and (hopefully) develops
> a feel for the most appropriate of the applicable techniques.

Sometimes the problem is that people sometimes have no idea where to
start, or even if code is the right solution for their problem.

At a slightly higher level of skill, the issues you raise become more
important.

I see the sessions as covering both needs.

> ==============
> 
> A not-strictly-Perl problem which I encounter in my applications is
> that of the logistics of Perl scripts and the processed files.
> 
> FOR EXAMPLE.  I am in the process of creating several large documents.
> For each document, I need to process on the order of a thousand text
> files, performing several categories of processing on each.  While the
> categories of processing are similar, the details of the processing
> vary from one document to the next.
> 
> As a Perl novice, my typical approach is to write and debug a Perl
> script for each specific operation, so that I end needing to run a
> dozen or so Perl scripts on each file to transform raw data into
> finished product.  A number of associated files provide data to be
> inserted, index values, file names, and so forth.
> 
> Of course, in the process of running each Perl script on the set of a
> thousand files, it is easy to lose track of the stage of processing.
> I am thinking that the Linux "make" utility might be the best way to
> manage the logistics.

Make is one way to handle it, especially if your intermediate stages
have distinct extensions.

Otherwise, the idea of a series of steps that need to be applied to a
set of files can relatively easily be reduced with a series of shell
scripts or a driver program.

I can think of several ways to handle this, depending on your comfort
with data structures and/or scripting.

> Thanks for your offer.

I really appreciate your input, part of the reason I'm bringing this up
is that I have a vague feeling that we are not really serving all of
our members well. I want to try to do a better job helping the
non-experts. Your input definitely helps with that.

G. Wade
-- 
Okay, that makes sense. I just don't understand it.     -- Dan Muey