Need Perl book advice

[phobia]

I have been working on perl for about 2 -4 months. I have read several books including Introduction to perl, Sams Teach Yourself Perl in 21 days(Which is a crappy book, IMHO), and Perl in a Nutshell, my question is what's next. I have Programming Perl, Mastering Algorithms in Perl, and Advance Perl Programming.

What I want to know, is what to do next, I mean I can only write basic programs, like a bot, or a program to search through directories. I am completely lost as to what to do, so I can write some of the sweet programs I have seen.

Any help would be apperciated.

--LostMonk

Janitored by davido: Retitled per consideration from "Lost."

[xdg]

PM has a good list of references in outside links - reference material you should look at, and you should search PM for articles on best perl books.

Clearly missing from your reference shelf, in my opinion, is the Perl Cookbook which has many, many examples of small, but really useful routines that you can combine and Mastering Regular Expressions which will show you how to use one of the best built-in features of perl.

Beyond that, it largely depends what you mean by "sweet programs" that you've seen.

[doom]

I wanted to second the recommendation for the Perl Cookbook, and to emphasize that it's more than just a bunch of little routines: every one of them is discussed throughly, and gathered together into logical chapters, e.g. the chapter on XML is probably the first thing you should read on the subject of perl and XML.

But I also wanted to say, don't neglect the on-line documentation. Perl comes with a very complete set of reference information, and also quite a few tutorials on different subjects. If you do a "man perl", you'll see a listing of other perl man pages, and right at the top is a section on the tutorials, including subjects like references, data structures, regular expressions and objects...

And once you're through that material, you might try looking at the Perl Design Patterns site.

[b10m]

I've seen this question here and there before. People who want to write something, but don't know what, or basically just want to learn.

The good thing for you, however, is open source :) Just read through some source and try to understand it. If you wish, try to improve it or just add new features (just for fun (and send patches to the author of course ;))

A good thing would also be to look at what some piece of software does, and then immitate it. Write your own app that does the same. Compare it to the other source and learn from it.

Or just join a project over at SourceForge. There is always help needed.

[davidj]

Instead of just diving in headlong into another book, I would suggest that your next step be to apply what you already know and use the books you currently have (and the ones already suggested) as references for when you get stuck. For almost all of the programmers I know, myself included, learning primarily comes by doing, not simply by reading.

Think of little projects to do, regardless of how cheesy they are. They don't have to be grandiose or world-changing. They just have to be opportunities to solidify what you already know and push you to learn what you don't already know. You say you can write a program that traverses a directory? Great! Now, how about a program that traverses a directory and renames files according to a pattern? Has someone else already done it? Absolutely. Does it matter? Hell no. Because it builds on what you already know and pushes you to learn something new. Heck, the first perl program I wrote was a base conversion program. I knew that every other programmer had already written one, but I didn't care. It was new to me, and that's all that mattered. And guess what? I learned something in the process.

One thing you might like doing is writing Perl versions of old games and puzzles. Not only will you learn a lot, but you will also have a lot of fun in the process. What about hangman? Remember MasterMind? What about a program that uses Depth First Search and generates mazes? (Put Mastering Algorithms in Perl to work).

Here's one for ya. Implement Conway's "Doomsday Algorithm" in Perl. In case you don't know, it is a method of determining what day of the week any date in history falls on simply by calculating 5 numbers. It'll be fun and the finished product could be quite useful for a larger program.

Well, you get the idea. I wish you luck in your endeavors.

davidj

[FoxtrotUniform]

Look into software engineering.

Being able to write interesting programs isn't just a matter of knowing how to use your favourite language (although that certainly helps). You also need to know how to manage complexity; otherwise, you'll get bogged down fixing bugs rather than adding features (which is the fun part).

If you can stand buying more books, have a look at The Pragmatic Programmer and The Practice of Programming, both of which are excellent discussions of the practical world of writing code.

[CountZero]

Programming Perl should certainly be your next read. You will come back to it time and time again and always you will find new things and insights.

[TStanley]

I would have to put my two cents in for Learning Perl and Learning Perl Objects, References and Modules, both of which are written by Randal Schwartz and Tom Phoenix.

[ysth]

Tune into the perl Quiz of the Week (http://perl.plover.com/qotw), or go through and work on older ones. It has beginners and expert quizzes (currently alternating weeks), where the beginners ones are theoretically solvable using only perl knowlege from Randal Schwartz's Learning Perl.

Update: s/only using/using only/

[graff]

There are at least three basic approaches, and you'll really get a hold on Perl (and it will get hold of you) when you've done them all:
• Take a Perl application that someone else has written and that is useful to you. Analyze what you do when using that app, and think of a way to improve the process by altering and/or adding to what the perl script does -- e.g. it might be nice if there were more flexibility for handling different inputs or outputs, or maybe there's some part of the usage that seems tedious or inapt and could be optimized. Adapt the script to your preferences, and from that point on, use your own version of the script.
• Similar to the above, but the existing tool is written in some other language (C, shell, awk, BASIC, whatever); maybe you need to port a tool (or game) from an old system to a new one, and/or the original language of the tool might get in the way of porting or maintaining it. (Or maybe, as you port it, you'd like to enhance it so it's better suited to the new environment.) This approach is trickier, but if done with careful attention to the differences in design between Perl and the other language, it's extremely rewarding and instructive.
• Consider some process you do often (for fun or work) that involves several discrete activities that you are handling manually, especially if it requires some tedious, repetitive, predictable steps. Write a script to automate or at least reduce the manual labor involved in the process.

The common theme among all these is that you start with a specific goal: improve a process in particular ways, or provide a new way to do a particular process, based on what is relevant to you in some way.

[Ambidangerous]

The Camel book, hands down.

Most of the experience I have in Perl comes from writing my own utilities. Surely there's some task you do all the time that you'd like to automate.

Here's one of mine: 'anew', a program that does nothing but create new files from a set of templates. You say something like 'anew example.tex' and it creates a new LaTeX file with all the appropriate headers and setup. Right now I can cut out a new perl program, perl module, C program, LaTeX document, HTML document, and even a new GNU Lilypond file--already set up for use as a jazz lead sheet (chords, lyrics, melody).

Now you could do the same basic thing with a shell script. But I added enough bells and whistles onto mine so it performs other useful functions:

You can say anew example.pmo and it will create a new file called example.pm, with the skeleton of an object oriented perl module already in place. Same thing with example.pmf (creates a functional example.pm module).

The program 'anew' itself responds to --help and --version. Handy in case you don't have to use it for a few weeks. The documentation is embedded right into the program using pod.

Whenever I need anew to learn a new type of file to create, all I need to do is 1.) make a template and store it in ~/share/anew and 2.) add one more entry to a hash in ~/bin/anew

So my recommendation would be: find a need. As you work on the program, you will find yourself inventing new features, and learning how to implement them.

[Anonymous Monk]

Your script "anew" sounds nice. care to post it? Also should why do you have to add a hash entry to anew? Should I not be able to just add a template to share/anew? share/anew/tex/ c/ pmf/ pmo/ .../ Then in each subdirectory have module for that template to handle building it. Of course there is alwasy the template toolkit.

[Ambidangerous]

The odd thing about anew is, it was created with anew. Sounds like a chicken & egg sort of deal, but the hint to solve this riddle is in the version number ;-)

Read more... (4 kB)

And, of course, once you post code in public, you become acutely aware of the hacks . . . . but the important thing is, I wrote it and it works.

[johnnywang]

anew sounds great and very useful. I have something similar in emacs, just some simple eLisp. For example, I set up the basic perl module structure when creating a new perl module (use strict, "1;" in the last line, Exporter, @EXPORT_OK, etc.) I do the same thing for creating java classes, getter-setters, a singleton, a servlet, comments, etc., the possiblitites are limitless.

[johnnywang]

One more thing, if the things you're creating are text based, a good module to look at is Template::Toolkit, you can create tempaltes for anything you want. Through Win32::OLE, you can even create Word/Excel templates (well, just a thought, I haven't had the need to do that.)

[Posthumous]

I have to second some of the earlier comments -- Learning Perl and Learning Perl Objects, References & Modules are excellent.

I've found Elements of Programming with Perl by Andrew Johnson the single most helpful volume I own.

The really nice thing about Perl is this: with only a basic knowledge, you can create solutions to very difficult problems. When you get that solution down, you've learned something. As you learn more, go back and revise your first solution to make it more efficient, more elegant.

What kind of problems can you tackle? Think of how you use your PC, and some small tasks you'd like to automate. Maybe reading some log files and generating summaries, creating a backup utility, reporting on old or large files. Maybe you want to send yourself an e-mail reminder of an important date.

I started using Perl at work to extract data out of very large log files and create simple reports. As I learned more about what I could do, more projects came to mind. Get that first project finished and the ideas will start bubbling up. And you'll be learning Perl.

[perldragon80]

I completely agree with the last post!
The key to moving forward and becoming a better programmer is projects, not projects that are within the realm of your current capabilities, but projects that are slightly outside of that scope.

Having such a project or task will force you to use all the resources you can to figure out solutions to the problems you find (which you can't immediately solve). I have found no faster way to learn than to be presented with a programming task that I wanted to find a solution to.

Step 1, and perhaps the key to all of this, is finding something that you would like to have automated or completed by a script or program. Don't start with something too big, just start with something fairly simple, perhaps even expand on an example you read in one of the books.

From there just keep trying to set a higher standard and soon you will be doing things you never even thought you could. When you do come to a point where you are having trouble, that's when you start using the forums, the google news groups, CPAN for modules, and although the O'Reilley line of books aren't perfect, I have found that they are very useful for almost any project you might want to tackle. Of course, instead of buying all the books I would search for online references or copies of those books first.

[periapt]

In agreement with/addition to the already great suggestions, I would recommend ...


• Programming Perl This is an indespensible reference
• Perl Cookbook The explanations say a lot about perl programming and philosophy
• Programming Pearls (Jon Bently) This book isn'nt Perl specific but it has a lot of good, solid practical discussions on programming practice and methods. The practice problems are interesting and relevent. Try to get both the 1st and 2nd editions as they have somewhat different content, both are invaluable.

Update: I stand (sit actually) corrected :o)

[davorg]

Programming Perls (Jon Bently) This book isn'nt Perl specific

Which is why it's actually called Programming Pearls (with an 'a') :)

[Jeppe]

Perhaps you can find a Perl project and involve yourself as a bug fixer? You'll be working with (hopefully) both very skilled and quite novice perl hackers.. Just ask for a few rather trivial bugs and spend some time locating and solving them! You'll learn how an advanced perl application actually works and is designed..

[johndageek]

No more book.
find need.
fill need (research if neccesery - book if needed)
feel good.
do again.


oog - me go now!