Learning by example

[Justin C]

I've been writing perl (poorly) for several years, not an awful lot of
it, but enough that I know how little I know. I pick up a lot here,
especially from the FAQ. I was thinking that it might be a good idea to
actually go over other people code, see how they do it, but more than
the snippets I see here in the newsgroup. My reasoning being that Linux
code improves with peer review, maybe my coding can improve by examining
other real code.

Of course, there is probably worse code out there than mine, and very
likely millions of lines of mediocre code too. I don't want to try and
learn from bad code, or pick up any bad habits so I was wondering if
there is any consensus here that any modules in particular are finely
written, and good examples of perl from which I might learn.

I look forward to your replies.

Justin.

 

[Randal L. Schwartz]

Justin> Of course, there is probably worse code out there than mine, and
Justin> very likely millions of lines of mediocre code too. I don't want
Justin> to try and learn from bad code, or pick up any bad habits so I
Justin> was wondering if there is any consensus here that any modules in
Justin> particular are finely written, and good examples of perl from
Justin> which I might learn.

My 250+ Perl magazine articles are still available online downward from
http://www.stonehenge.com/merlyn/columns.html, although the CSS got
broken a couple of years ago and I haven't had time to fix it.

Beware that many small parts of the information is somewhat dated
now... I keep meaning to drop in a paragraph or two above the more
serious trouble spots but haven't had the tuits.

print "Just another Perl hacker,"; # the original

 

[ccc31807]

I've been writing perl (poorly) for several years, not an awful lot of
it, but enough that I know how little I know. I pick up a lot here,
especially from the FAQ. I was thinking that it might be a good idea to
actually go over other people code, see how they do it, but more than
the snippets I see here in the newsgroup.

The best way to learn anything, Perl included, is to use it for useful
work. If you don't have a task that needs doing, you aren't going to
do it, but if it needs doing, then you will be motivated to do it.
This may sound trite, but it's absolutely true. Even using a tool
(like Perl) 15 minutes a day will increase your skills, so the task
may not be large ... it's enough if the task is real and you use the
tool (like Perl) to do it.

By the same token, looking at other people's code won't do much good
unless you have struggled with it yourself. Looking at the 'right
answers' won't help unless you know the right questions. Once you know
the right questions, you can make sense of the answers.

I'll also suggest that there isn't any mass of Perl (or anything else)
that you should know, once you get past the basics. When you know how
to do something well, it's a lot easier to add to it and learn how to
do other things well. In my case, I started writing Perl about 11
years ago in connection with developing web sites, and got pretty good
at CGI. As time went on, I changed jobs (several times) and learned
how to do new things.

Bottom line: use Perl daily, writing real solutions to real tasks.

(I recently had the opportunity to learn R. It helps that R is a
simple, small language, but it hurts that R requires substantial
domain knowledge in statistics. As it turned out, in about a week of
pretty heavy immersion I gained the ability to write programs (in
Perl) that spit out R objects. The motivation was directly job
related, and this motivation probably cut the time I spent learning R
by a couple of years. No joke! You can learn a lot with some time and
effort, and a lot of motivation.)

CC.

 

[Willem]

Justin C wrote:
) I've been writing perl (poorly) for several years, not an awful lot of
) it, but enough that I know how little I know. I pick up a lot here,
) especially from the FAQ. I was thinking that it might be a good idea to
) actually go over other people code, see how they do it, but more than
) the snippets I see here in the newsgroup. My reasoning being that Linux
) code improves with peer review, maybe my coding can improve by examining
) other real code.

Yes and no. Perl is one of those languages where there are lots of
different methods, and most of the perl code out there isn't that good.

One suggestion would be that, whenever you come up with a solution in
Perl to some interesting problem, to try and find a better one.
And in that case, this NG is a very good place to ask for better ways
to do something.

) Of course, there is probably worse code out there than mine, and very
) likely millions of lines of mediocre code too. I don't want to try and
) learn from bad code, or pick up any bad habits so I was wondering if
) there is any consensus here that any modules in particular are finely
) written, and good examples of perl from which I might learn.

A lot of modules tend to contain hairy code, which is there to make
the use of the module easier. In other words, the complex, iffy,
nasty, hairy stuff is hidden in a module and from the outside it's
all peachy. So I wouldn't recommend looking at most modules.


And anyway, as another poster said, you learn the most from solving your
own problems, and also from learning new and better solutions to those same
problems.

Example: how to parse a simple ini-file (only 'key=value' pairs)

PS: This is just an example, so it's oversimplified.

Simple way:
my %keys;
for my $line (split "\n", $file) {
if (my ($key, $val) = $line =~ /^(.*)=(.*)$/) {
$keys{$key} = $val;
}
}

Clever way:
my %keys = $file =~ /^(.*)=(.*)$/gm;


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Randal L. Schwartz]

Willem> Example: how to parse a simple ini-file (only 'key=value' pairs)

Willem> PS: This is just an example, so it's oversimplified.

Willem> Simple way:
Willem> my %keys;
Willem> for my $line (split "\n", $file) {
Willem> if (my ($key, $val) = $line =~ /^(.*)=(.*)$/) {
Willem> $keys{$key} = $val;
Willem> }
Willem> }

That would parse a line with "a=b=c" to be key "a=b" value "c".
I would think you'd prefer that as key "a", value "b=c", which suggests
a lazy match:

if (my ($key, $val) = $line =~ /^(.*?)=(.*)$/) {

print "Just another Perl hacker,"; # the original

 

[Justin C]

Justin> Of course, there is probably worse code out there than mine, and
Justin> very likely millions of lines of mediocre code too. I don't want
Justin> to try and learn from bad code, or pick up any bad habits so I
Justin> was wondering if there is any consensus here that any modules in
Justin> particular are finely written, and good examples of perl from
Justin> which I might learn.

My 250+ Perl magazine articles are still available online downward from
http://www.stonehenge.com/merlyn/columns.html, although the CSS got
broken a couple of years ago and I haven't had time to fix it.

C'mon Randal, I've done every exercise in the Llama, I'm working on the
Alpaca, haven't I picked up enough of your bad habits already?!

Beware that many small parts of the information is somewhat dated
now... I keep meaning to drop in a paragraph or two above the more
serious trouble spots but haven't had the tuits.

I do wonder how 'best practice' has evolved since you wrote those. I'll
take another look at them.


Justin.

 

[Justin C]

[snip]

Bottom line: use Perl daily, writing real solutions to real tasks.

I don't have enough tasks for which I can use Perl. I do, though, have a
lot of Perl I've written over the last however many years, and I know I
can improve on some of the early stuff. Perhaps that's what I should
tackle, a re-write of my previous work (no, work isn't as busy as it
could be).

Thank you for the suggestion.

Justin.

 

[Justin C]

A lot of modules tend to contain hairy code, which is there to make
the use of the module easier. In other words, the complex, iffy,
nasty, hairy stuff is hidden in a module and from the outside it's
all peachy. So I wouldn't recommend looking at most modules.

Point taken.


Justin.

 

[ccc31807]

I don't have enough tasks for which I can use Perl.

I have exactly the same problem with two languages that I've been
attempting to learn for years: Prolog and Common Lisp. What I said
about having a reason to use the technology I've learned by hard
personal experience.

I do, though, have a
lot of Perl I've written over the last however many years, and I know I
can improve on some of the early stuff.

Bingo! Every time I run a process that I've developed, I review the
code and REWRITE it. I have a lot of stuff that I do four or five
times a year, and this is long enough to forget what you've written
(and why in some cases) but short enough so that you can understand
the requirements. It also helps if you upgrade your Perl with the new
versions.

Unfortunately, 'management' seems to have the attitude that, if it
ain't broke, you shouldn't fix it. I have a corpus of scripts that
I've written for managers over the years that break from time to time,
and I cringe every time I look at one. ;-)

CC.

 

[Juan Wei]

Justin C has written on 4/19/2011 5:04 AM:

[snip]

Bottom line: use Perl daily, writing real solutions to real tasks.

I don't have enough tasks for which I can use Perl. I do, though, have a
lot of Perl I've written over the last however many years, and I know I
can improve on some of the early stuff. Perhaps that's what I should
tackle, a re-write of my previous work (no, work isn't as busy as it
could be).

I'm not a programmer but I need a simple script. Perhaps you might find
this interesting enough to tackle.

I have a bunch of files with names like text123.txt that I would like to
change to something more meaningful.

Fortunately, each of them has the desired filename as their first line.
For example, the file text197.txt consists of these three lines:

HD TESTERS

See manufacturer's website.

I'd like the name to become HD TESTERS.txt or HD_TESTERS.txt (lowercase
is OK, too)

Thanks.

 

[J. Gleixner]

Juan Wei wrote:
[...]

I'm not a programmer but I need a simple script. Perhaps you might find
this interesting enough to tackle.

Perhaps you might find this site interesting enough:

http://jobs.perl.org/

 

[John Bokma]

Juan Wei wrote:
[...]

I'm not a programmer but I need a simple script. Perhaps you might find
this interesting enough to tackle.

Perhaps you might find this site interesting enough:

http://jobs.perl.org/

Or: http://johnbokma.com/perl/help-in-exchange-for-books.html ;-).

As for learning more Perl I can highly recommend the following books:

* Modern Perl
* Mastering Perl
* Perl Hacks
* Intermediate Perl
* Higher-Order Perl
* Perl Cookbook

I recommend to start with Modern Perl first. You can download it as a
pdf, but IMO the printed book is well worth the money.

 

[Marc Girod]

(you better make backups before trying this...)

    perl -lne 'close ARGV; tr/ /_/; s/$/.txt/; rename $ARGV, $_' *.txt

So... What could happen?
- empty file; no first line
- first line contains illegal characters, for use as file names
- collisions:
- several files with first lines resulting in the same names
- first line resulting in an existing file name
- protection issues:
- non writable directory
- non readable files
Marc

 

[Marc Girod]

The poster said:

....

Sorry: there was no critique implied in my comments!
You warned about taking a backup, and rightly so,
even if the script as is will work perfectly most of
the time!

And sure: the assumptions taken were based on the
poster's task descripton!

Marc