• Learning Perl as a First (programming) language
• Fundamentals Of Programming -- In 6 Hours
• Perl Object Oriented Meta-Tutorial if you're interested in OOP
• Basic Input and Output
• pattern-matching examples
• Common Regex Gotchas
• Common Beginner Mistakes
• How to RTFM (for a laugh, check out this redefinition of RTFM:)
• Parsing your script's command line
• Minimal Perl for the Impatient (hmm, I should read that one)
• How (Not) To Ask A Question
• PerlMonks for the Absolute Beginner (why not?)

If you put a little effort into finding the right docs, you'll find that almost everything you want to know about programming is available, either here or elsewhere on the 'net, for free. And if you have some money to spend, you can get some more great docs. Put in a little time searching, and you'll love the results.

"Uhh ... that'll take me three weeks, broken down as follows: 1 day for coding, the rest for meetings to explain why I only need 1 day for coding."

First of all, let me welcome you into the world of perl programming. It is quite a trip-sometimes smooth and serene, sometimes mind-blowing, with at least a few hills and pot-holes you may encounter along the way. In some respects, it might be like an all-terain vehicle with a standard transmission, taking you on almost any journey you can imagine, but the steering and transmission can take some getting use to.

I would be curious which resources you had looked into. One resource you may wish to look at (if you have not looked at it yet) would be Learning Perl. One of the authors of the current edition is Mr. Randal Schwartz, who you may see herein from time to time.

The perl community (and indeed, even herein) has quite a range of individuals, from those just learning to those with considerable years of experience. While we try to be helpful and friendly, sometimes we may forget how it felt when we first entered it, and being a virtual forum, sometimes a response that is meant to be clear and conscise can seem harse due to the lack of context clues (such as the body language we use consciously and unconsciously in the physical world). My advice would be to try not to be afraid to ask questions, or offer suggestions and comments (such as this one). I won't guarantee that you get an answer immediately every time, or that you will never get hit with an RTFM response to a question, but I can guarantee that there are a number of people here who will try to be helpful when they can.

Again, welcome to perl, and I hope your journey into perl may be an enjoyable one.

This is a response to Louis Wu Also, as both of you were asking about what I have already read.


I am in the middle of reading Learning Perl, and it is a great read, not what I expected from a programming tome, I am coing off of reading Perl for Dummies (and yes, I do feel like a dummy for buying it...)


I am going to have a week free (my wife and kids are going to Puerto Rico, I elected to stay home and crack the books, does that make me an even bigger dummy?) and have decided that I will at least be able to understand the concepts that are obvious in Perl by that time.
I bought a number of books to get me started, Learning Perl, Core Perl little black book, Programming Perl,Begining Perl, Perl and CGI (whoops, almost as bad as the dummies book!) and a few others that I have yet to recieve.


I got myself a subscription to Active State and sprung for the Komodo IDE, and I even got a subscription to The Perl Journal. All in the space of a week and a half.


Now I have to start using these resources, I just wondered if instead of spending the $500.00 or so, if there was a simple guide,that held my hand and walked me through the initial learning curve.


I am getting back into programming after a 10 year hiatus (two kids, I am a stay at home Dad), the last programming language I learned (and I knew it inside and out) was a obscure language for a now defunt Bulletin Board System called PCBoard, the language was PPL.


. Thanks for the suggestions guys, I will follow each link, and see what i can squeeze from it, learning Perl is a goal I have to sort of get myself used to not doing the child rearing thing. It has to be easier <s>.


Keep the suggestion coming if you think of anything else, something has to click.

You mention CGI - although perl is very good for developing CGI applications, I would not recommend it until you get a better understanding of how perl works. CGI programs are notoriously difficult to debug. If you throw a beginner's understanding of the language and CGI programming together, you're likely to become extremely frustrated as you try to figure out how to figure out why your program doesn't work. Unless you have a very good understanding of how your webserver and CGIs work and how to debug them, I would recommend putting your efforts into getting things to work from the command line first and only moving on to CGI after becoming comfortable with the language.

90% of every Perl application is already written. ⇒

dragonchild

A couple of comments: Unlike some others I dont think you went that wrong with the Komodo and the AS support. I personally have them and dont use them much, but I've also seen others with some basic familiarity with other languages use them to come up to speed in perl quite quickly. And frankly for learning/debugging regexes the AS stuff rocks big time. However, you should also install a "normal" AS perl longside that. Eventaully you'll probably switch to using it with a text editor, but for the first while the komodo i think will be comforting.

The normal install comes with a great indexed HTML version of all the standard docs (similar to perldoc.com or the CPAN sites or whatnot). I personally often have three or four browsers open to various pages. For you I would suggest reading perlsyn and a quick glance through perlfunc along side a good read of perlboot perltoot and perltootc. Some may wonder at the later, as they are OO oriented, but personally I found them to be excellent general perl documents that shine just enough light in enough corners that you can get moving quite quickly with just reading them. Even if you dont write a module or class for weeks after reading them, the general exposure will do wonders.

Learning perl is meant to be a fairly smooth and gradual process. The language is designed so that "baby-perl" works but "adult-perl" is possible. So considering you probably have a basic idea of program flow control and the like the best thing to do is to write a project. Every time you say to yourself "theres gotta be a better way to do this" have a poke through the docs, odds are you'll find that you were right. OTOH, if it works dont worry about it, move on the next program. :-) Everybody has the horror story about "their first perl program /brrr" :-)

Oh and youve already done IMO one of the best things you could have done to learn Perl. You've showed up here and asked a reasonable question. You'd be suprised how many people dont get that far ;-)

Good luck.


---
demerphq

<Elian> And I do take a kind of perverse pleasure in having an OO assembly language...

---

• Update:  
I also strongly encourage you to read anything in the standard docs that has "tut" or "toot" in it. There are a few, and you should at least be familiar with them and the areas they cover so that when you wonder "how do I do X" you know which document to look into. Simply knowing most of their names helps a great deal :-)

A friend of mine, during an employment hiatus of his own doing, worked through a copy of Perl in 21 Days. He had a good programming background in other languages to start, but said that was a good book for him. Your mileage may vary.

That said, as others have said, there are wonderful tutorials here and wonderful people here who have assisted many, including me, in times of "bang head here over problem".

One book I can heartily recommend is Coriolis's Perl Black Book. Great reference for when you can't remember that niggling little syntax detail.

As far as comparing child rearing and Perl, I can tell you that Perl is easier than getting a cat to do what you say. :)

Good luck!

There is no emoticon for what I'm feeling now.

Hello and welcome back :)

I got myself a subscription to Active State and sprung for the Komodo IDE, and I even got a subscription to The Perl Journal.

I hate to break it to you, but in my humble opinion all of the above are a total waste of money. I don't have a very high opinion of the perl journal, and I can definately say it isn't great for those just getting into Perl. As for fancy IDEs and subscriptions to Active State, you'd be better off without them. All they do is serve as roadblocks to learning.

I just wondered if instead of spending the $500.00 or so, if there was a simple guide,that held my hand and walked me through the initial learning curve.

Definately. In fact there are several extremely good resources. The obvious one is where you're currently posting. As I mentioned elsewhere in this thread, the documentations with Perl is just about the best I've seen with any language (and its free). It may look very overwhelming at first, but break into into bite-sized chunks (start with perlintro, work your way up), and it's easy to swallow. The other excellent resource I can think of is safari, they have an awesome selection of Perl books (all the essentials, and almost all the ones even worth reading) and it's extremely cost-effective, check it out.

Also, I'd recommend against going out and buying 5 books at a time on any subject unless you're an extremely fast speed reader being thrown into solitary for a couple weeks. You'll always end up regretting some of the purchases. Personally out of the over 100 programming books I've bought, I'm glad I bought about 5 of them. Better off to look for online resources, then if necessary pick up a book or two afterwards.

Good luck! :)

I lurked around here as a 'newbie' for a while (too long actually...) before I made my new years resolution to dig in and learn perl as a new language...yep, I'm just an old dog learning some new tricks

I have found the other monks on this site both knowledgeable and in most cases, extremely friendly...check out my home node for my list of monks I have had drinks with.

If you are looking to learn perl as a new concept, then I cannot recommend this site with enough enthusiasm to describe the benefits you will gain from participating here.

The vast array of experience and examples available by search, the camaraderie of the chatterbox, and yes...the XP system which will keep you coming back and wanting to participate so you can see those votes rack up...these are all just a small part of the wonder that makes Perlmonks a great tool for the 'newbie' (as you describe it..and as I am an example of) to use for learning and encouragement.

Keep the faith...and don't forget if you ever get stumped or lost..the best thing about this site is you can always post a question.

Is that Mach 10 or Monk 10 ? Either way, Level 10 seems a long way away ;)

Oh, and I'd like to say that The Perl CD, from my favourite O'Reilly, is one of the best investments I have ever made. I have a background in programming from college, etc, but it has truely helped me out.

>joe

I recently started teaching perl to a friend, and I had to think about this exact concept.

First off, good call on buying that big stack of books. You'll find that you rarely close Programming Perl (The Camel Book) and The Perl Cookbook. I gave up putting my copies back on the shelves because I kept having to take them down again every day.

I've found that the best way to learn perl is to start with something you know a little about. When I taught a Network Admin, I taught him how to parse specific information out of netstat. When I taught a music freak, I showed him how to use MP3::ID3Lib and regular expressions to sort and tag his mp3s.

Learning Perl is a good place to start. Read Chapter 1 and do the exercises. If you get stuck, search the Monastary for an answer. If you can't find an answer, just ask. We're here to help.

Once you get a little more comfortable, pick a project, something that amuses you: translate your phone number to letters, search ebay for stuff, or pull movie listings from the web.

Finally, hang out in the Monastary. You'll find that the people here are friendly and eager to help.

-Logan
"What do I want? I'm an American. I want more."

Hi, which tutorials have you looked at? There's about a million out there, most of them written by people who know nothing about the language (props for trying anyways though :). Have a look at perlintro if you haven't already.

Also remember where the software and all its documentation came from. The best person to fix any problems you come across is yourself. Write short tutorials as you go along, and if in doubt post them to perlmonks for review.

• My ol' daddy used to say (back in the days when I was hassling him to buy me a ZX80) "You don't want to learn BASIC" (which was my justification for him spending the money), "you want to learn programming - that's the hard bit". Having already programmed (no matter how obscure the language), you've got a head-start. Try to think of Perl as 'just-another-language' in which you can solve tasks, rather than a completely new thing.
• Indeed - suffering should never be part of the educational experience (one of the many reasons I home-educate my children). Learning is fun. Do you know of the "Inner Game" series of books? There should be one on programming - how to take a task and turn it into a game that you just try to play better and better as you go along. I (and many others) often refer to 'research periods' as 'playing around'
• Be wary of books / teachers. Even the Camel book (which for me also is never replaced on the shelf, and I sometimes re-read for *fun*) contains the odd typo - and a lot of other books contain sheer rubbish. Remember, whoever wrote the book / is taking the class *themselves* were students (not that long ago for many), and many of them learnt from the poor books / teachers...a self-perpetuating cycle that is difficult to break. The point made earlier about having lots and lots of books / tutorials is sound, as you can then 'average out' the info - if one person's explanation seems poor, you can turn to another. Skim the bits you don't like / understand, rather than get bogged down - next time you come back to them, you'll find it a lot easier.
• Finally, learn by doing. IMHO, the 'best' programmers are the ones that taught themselves to write games in ASM in their bedrooms when they were 12. Pick a task - a fun easy task that (as logan says) you can relate to (I have my 8-yr old writing Power Rangers websites) and write it. Programming is at heart about the analysis of tasks, not syntactical manipulation, which is why the "More Than One Way" philosophy of Perl is so lovely - the language doesn't force you to leverage *your* analysis into *its* framework so much as many others do.

Have a look at Beginning Perl by Simon Cozens. You can either buy it at your favourite bookstore or download it for free (legally) at http://learn.perl.org/library/beginning_perl/.

Juerd
- http://juerd.nl/
- spamcollector_perlmonks@juerd.nl (do not use).

Hi, another comment on books - they aren't necessary, really. Learning Perl is a decent intro book, but if you go through the online tutorials (even if it takes a couple passes) you will be better off in the long run. As for reference books, Programming Perl is great, but so is perldoc. Ideally you shouldn't need to buy any documentation for open source projects, and in Perl's case it comes pretty close to being unecessary.

One other thing to consider is that new development with Perl 5 (the current version) will soon decline dramatically. While Perl 6 will still be Perl, and many Perl 5 concepts will apply, it will also have major differences. If you're just looking to learn a language, I would recommend python or possibly ruby (python has far better documentation then ruby, so it would be my choice).

Before I get flamed into oblivion, have my post reaped, and start receiving death threats, here are a few reasons for my suggestions:

• Object-oriented programming is far, far simpler in Python and Ruby. This is not to say Perl's OO is inferior, but when it comes to someone without any experience on the subject, Perl's OO can be very, very confusing.
• Perl's strength and weakness is in its flexibility. This is arguably good thing for experienced programmers, but is about the worst thing possible for novice ones. When you're reading through an introductory tutorial and it's throwing maps and greps and all sorts of other strangely named fuctions at you, it gets confusing. References and other such intermediate concepts seem to pop up frequently in early Perl programming lessons as well, whereas they remain mostly invisible (for most intents and purposes) in python.
• If you learn a different language now, and put off learning Perl 6 until it is somewhat stable, you'll benefit from being able to compare the languages and choose the most suitable one for each task. You'll also avoid the Paul Graham blind advocate syndrome(</cheapshot>;-). It also looks good on a resume.
• Python is a lot closer to certain other Large Corporate Languages (that shall remained unnamed) and will make learning such languages much easier. It will enable you to easily branch off and learn such languages if the need arises.

So that's some of my reasoning, feel free to flame away now :).

Whether or not this is good advice entirely depends on what someone wants to do. Advantages of Perl include CPAN, widespread availability of good help, and more mindshare. My view is that Python and Perl are about equal on quality but appeal to different personalities. Python also doesn't have CPAN, and doesn't have the same mindshare. Ruby is hands down a better designed language than either Perl or Python, but is so far below critical mass in English-speaking areas that it isn't funny.

Which means that for an infrequent programmer, Perl is better. They can get stuff done, using convenient CPAN modules and with lots of useful assistance. Choosing modules can be confusing, but they can ask somewhere like here. For a more frequent programmer, well if you tackle lots of different things, then CPAN pays off again, and again, and again. A better language only beats a better library if the language is quite a bit better, you are better and library design than the library author, and you can amortize the cost of writing that library over a lot of further work. You will note that Paul Graham used Common Lisp (in his opinion a much better language) for the core stuff, and then Perl for all of the random bits that needed to get done but not built on (like email).

Oh, and the demise of Perl 5 is often predicted and has yet to come true. The truth is that Perl 6 is unlikely to be released for a good time yet, and after it is, the differences are such that Perl 5 will continue to grow on a separate trajectory. Therefore the possibility of Perl 6 on the horizon shouldn't dissuade people from learning Perl 5 one bit.

Oh, I forgot one point. Whatever language you end up choosing to learn first, for the love of all that is holy get your hands on an Open Source operating system. It will make your life, way, way easier and far more enjoyable. Pick up something like Redhat (other distros) it's dead simple to install and use, and if you want to keep you're existing OS installed, you can (although I'd recommend you ditch it, you'll never want it again :). Even if you're barely into programming, it's worth it.

If you need any help with this, just reply to this post. If you do decide to stick with a different proprietary operating system you can still use all the languages I've listed, but it won't be nearly as fun :). Anyways, best of luck, reply if you need any help :).

Oh, and since I'm going to get it anyways now... Vi sucks, Emacs Rocks! ;-P

This is useless advocacy.

Worse than that, it is stupid useless advocacy.

People need to tackle things one at a time. Telling someone who is learning a language that they also need to use an operating system is counterproductive. Telling someone that they need to tackle an operating system without giving them any solid reasons is just silly. Claiming that learning something new will make their lives easier is iffy in the short term, and given the proliferation of APIs in open source projects, is pretty doubtful in the long term. Suggesting that they immediately ditch their existing systems, which have lots of data that they care about and all of the applications that they know how to use, is a recipe for utter disaster.

Now yes, if you need a certain level of control of your system, then open source is better. I am not adverse to the right people using it for the right reasons. At the moment, in fact, I am typing into Galeon running on a Debian system. If this system was directly facing the Internet, I would set up and run OpenBSD. In comparison to what I am happy with, Red Hat is an insecure piece of proprietary shite that hobbles its basic update and dependency system because they need something to charge businesses a premium for. Have I established that I am not a Windows weenie yet?

OK, then now you know where I am coming from. So listen up. Please don't throw around counter-productive, useless advocacy. People get burned by it and it makes it harder to apply useful, targeted advocacy when there is an opportunity to make a real difference. As the doctors like to say, "First, do no harm." Please.

Perl is a tool for people tired of doing things in asinine & limiting ways.

It's hard to learn if you don't have at least some experience with getting 
work done or solving problems with less appropriate tools.

Ideally, you'd be a former C programmer

Minimally, you could be a win32 batch file writer.

More importantly, you need problems that could be better solved with a heavy 
weight scripting language bursting with creative possibilities rather than 
some silly minimalist engine with the most narrow of scopes predetermined by 
others who think they know what the real world is like.

I too wanted to learn Perl when I first entered the I.T. field, but I was 
discouraged.  Not just by the learning curve, but the audience Perl was 
directed to:  Seasoned admins and power users who knew what they needed to do

Vague ideas about what perl can do didn't give me the Oomph I needed to learn 
and be productive in it.

But after a year of pissy batch files, fussy WSH, and, God help me, Send-keys  
I was able to sit my arse down and plow through the Llama book, and start being 
productive.

Hang in there.

I found Robert's Perl Tutorial to be a very good introduction on Perl: http://www.sthomas.net/roberts-perl-tutorial.htm

It touches on every newbie subject you can think of.
If you want to delve into one of them more deeply, the man pages are a good choice.

Cheers,
MichaelD

It looks like an excellent "Rank-Newbie" page, I will work my way through it tonight and see if it sheds any light on the hash issue, and if it delves into using modules at all. (two things I am stumbling over at the present).

Thank you for taking the time to point this site out.

Modules look imtimidating at first, but they're really cake. Simply load the module at run time. Wow, that doesn't sound simple at all. Here's what I mean:

#!/usr/bin/perl -w 
use MP3::ID3v1Tag;
[download]

This allows your code to access the subroutines in MP3::ID3v1Tag. From there, you call them like any other sub.

use MP3::ID3v1Tag; # Adds the library
  $mp3_file = new MP3::ID3v1Tag("filename.mp3"); # Creates a new objec
+t called $mp3_file. 
  $mp3_file->print_tag(); # calls subroutine print_tag() on the file t
+he $mp3_file object is working on (filename.mp3)
  if($mp3_file->got_tag()) { # calls subroutine got_tag(), which will 
+return 1 if the tag exists, 0 if not.
        $mp3_file->set_title($title); # calls subroutine set_title(), 
+which will set the title to the value $title. In normal practice, you
+ probably would have parsed out of the filename
        $save_status = $mp3_file->save(); # calls subroutine save(), c
+ommitting your changes. 
  }
[download]

Clear as mud? Think of a module as a big bag of subroutines that you don't have to write. Just read the documentation, and you'll have all you need to know about how to use them, and all the dirty work happens behind the scenes.

Over time I've found that a new project begins by searching CPAN for relavent modules. If you can find one, you may find that 90% of your work is already done for you.

One more thing, as you continue coding perl, I can't stress enough how useful The Perl Cookbook will be. It's one book I wish I'd bought on my first day coding.

-Logan
"What do I want? I'm an American. I want more."

And once again, welcome!

In one of your replies I noticed you're learning perl to build a website... One of the most wonderfull things about perl is the availability of tons of modules which can make your life easier...

I can recommend CGI::Debug if you want to do CGI style-development.

If your hosting party is flexible and you can have them add some configuration to your server (hopefully Apache) you can consider using PLP which was created by our fellow monk Juerd.

As for books; I swear by Learning Perl and Programming Perl by O'Reilly. The Cookbook can save you a lot of time, and Advanced Perl Programming is great if you want to learn the really cool stuff...

And a general tip; use us! Post your questions on perlmonks, and visit #perlhelp on irc...

Good luck and have fun...

Update: If this is the first time you'll be building a website application, I'd definitely recommend investing some time in understanding the HTTP protocol and it's mechanics.

My webhost is a compnay out of New Hampshire, WebServePro, great bunch of people, I have actually been with them for about 4 years now (a couple of very small, simple web sites). They have always bent over backwards to help me out.

I have yet to check to see if they are running mod_perl, but if they are, I will ask them to install PLP, after reading the docs on it, it looks like it woudl simplify alot of what I am trying to do.

I have learning Pearl, as I am accustomed to communicating with infants, and the most advanced books I have read inthe past 7 to 8 years all involved a big red dog named Clifford, I am finding it slow going. I tracked down a copy of the SAMs book (Learn Perl in 21 days) locally and am going to run out this afternoo to pick it up.

Thanks for the heads up on the modules, now I have to figure out how to *use* them <s>.

PLP doesn't require mod_perl, but it is recommended if you'll be running any large scripts. Mod_perl sort of 'embeds' a resident perl interpreter in Apache, which in turn caches your perl-scripts in memory. That way perl doesn't have to be loaded on each CGI request, and perl doesn't have to recompile your script on every request.

On the PLP page are instructions for the system administrators on how to use PLP both with and without CGI. After they've done that, you'll be able to 'use' PLP without useing it... It's a module you'll never invoke directly. It is invoked by the webserver and allows you to create .plp scripts instead op .pl scripts.

If you want to see examples of .plp pages, just visit the homepage for PLP (http://plp.juerd.nl/) and on any page click 'Page Source' in the left navigation bar. The main advantage to PLP is that it debugs easier than plain CGI, and it can be used to easily build html-templates, so you don't have to hardcode your html in your scripts.

The benefits of stuff like this will become obvious once you've gotten started using it... :)

Regards, Gilimanjaro...

The Perl Beginners' Site has a good collection of links, many already mentioned above.