1. Perl is a high-powered language with many, many features. It will take you a while to learn all of it. Don't be put off if you only program in Baby Perl, as Larry Wall calls it. Advance features can be learn after you're comfortable with the basics.
2. Don't be afraid to ask dumb questions. We all were dumb once. So, sign up now for the beginners mailing list. Even if you don't have a question, you can learn a lot from other people's questions and their answers.

For Perl in general, and the Monastery (especially SOPW) in particular, learn how to ask questions effectively. There is no such thing as a dumb question, but plenty of ways to ask in a dumb way.

We all started somewhere, and this medium is one of the friendliest and most responsive ones I have stumbled onto (into?) - but don't expect people to do your (home)work, or think for you.

Both before and after, Perl is as much about community as it is about the language itself.

Both before and after, software programming is about intention and not code.

Write the most elegant code in any language, and if you don't have a plan or at least a clear vision of what you would like the code to do and how to prove it does it, your code will be worthless. Without vision and a plan of action, your code won't do anything of value. Even if it does do something of value, without tests or other objective ways of demonstrating that your code does what you claim it does, no one will trust it but yourself.

Above more than one person has pointed out that Perl is not unique and that there are other excellent programming languages. This is true. But Perl excels at something that few other languages achieve: drawing together a community of people who share a passion for learning in all areas of life, not just programming.

Take a look at the conversation in the cb on any given day: it will range from politics to tech talk to quirky science to child care advice to music selections and great places to hike to Perl and back again. It is very true that most Perl programmers have a life out side of Perl, but what makes the Perl community unique is that we know this is true about one another.

Perl becomes a philosophy of life because of the community that surrounds it, not the language.

Best, beth

What you're saying is someone might start programming now, or could go off and learn something different, and then start programming. While the other journey might be interesting, why not just start programming. Better yet, wy not start programming, and learn other stufff at the same time; read blogs about all sorts of stuff, take up rock climbing and sailing.

Hey Tom,
What you're saying is someone might start programming now, or could go off and learn something different, and then start programming.

No, no. I didn't mean it like:
"Hey before you go off into the mountains for a year with nothing but a crate of creamed corn and Tang to learn Perl, here is what you need to know." Although, that would be pretty fun to see what would happen. (For someone else I mean-not me.)

While the other journey might be interesting, why not just start programming. Better yet, wy not start programming, and learn other stufff at the same time; read blogs about all sorts of stuff, take up rock climbing and sailing.

OK, this is somewhat more what I meant.

I have always felt that taking up different things at the same time that — on the surface — don't have much to do with one another can end up having a sort-of cross fertilization effect.

For example:
In this first year I took up learning the blues harmonica at the same time as Perl. (It's not going as well though.) I continue to draw, shoot photos and design since that's my profession. My wife and I have traveled twice which is something we love to do. I have read a bunch of books which mostly didn't have to do with Perl. I also started cooking more again and finally managed NOT to kill a plant. I think on various levels learning Perl can influence and be influenced by all of these.

A direct example of Perl and a life experience helping one another:
My wife and I have been working towards the possibility of adopting a child. It's an intimidating and complicated process. This is not helped by the fact that my wife and I address grown up problems differently at times. We went about researching, brainstorming and doing soul searching both together and individually. At one point I thought "Too bad I don't know Perl a little better. I'd come up with a module for this whole tangled mess." I did, however use the opportunity to take our lists and use them as data to learn hashes and arrays. :-)

So, yes I do think life experiences can help you before and during time spent learning Perl.



"...the adversities born of well-placed thoughts should be considered mercies rather than misfortunes." — Don Quixote

There are several bits of advice that I give any Perl newbie who listens, and which I'd certainly give myself if I could meet my younger self.

• Learn by coding a piece of software that you actually use yourself
• There's an incredible amount of Perl wisdom in the perldoc man pages and on perlmonks. Embrace it!
• If you're unsure about a construct (how a built-in function or some syntax behaves), experiment in a small, autonomous script
• Get involved with the Perl community as early as possible. It's very friendly, and its collected domain knowledge can make your life much easier
• Collaborate with others
• Use the CPAN.
• If nothing you change in a file seems to have any effect, check if you're really editing the same file you're running, and if you're running it on the same host as you're editing (easy to overlook if you have ssh sessions over a fast network)

What do you think someone about to learn Perl should know and/or keep in mind ahead of this awesome journey?

I do not agree on the first part. I don't think there's anything you must have to learn Perl. You don't even have to like Perl. I know people who hate Perl with a passion (and can actually motivate their reasons quite well), but who can still program pretty well in Perl.

As for 2), I think that isn't true for the vast majority of the people who know Perl. For most people programming in Perl, Perl is just another language. Most of them have learned it as part of some job. The average Perl programmer actually has a life outside of his job. In his free time, he takes his dog for a walk, goes with his kids to the playground, and takes his wife out to dinner, instead of writing CPAN modules, hanging out on Perlmonks, or finding himself superior to PHP or Java programmers. The overwhelming majority of Perl programmers is as fond of Perl as most carpenters are of their hammers. Carpenters don't consider their first year of playing with hammers "awesome journeys" either.

"The average Perl programmer actually has a life outside of his job. In his free time, he takes his dog for a walk, goes with his kids to the playground, and takes his wife out to dinner, instead of writing CPAN modules, hanging out on Perlmonks..."

Wait — the Monastery DOESN'T require me to leave my wife and be celibate!?!
"Honey come back. I'm sorry. Apparantly that whole monk thing is just a metaphor!"



"...the adversities born of well-placed thoughts should be considered mercies rather than misfortunes." — Don Quixote

You missed the 'r'. You are supposed to "celebrate" Perl.

--MidLifeXis

After writing professional software in more than twenty programming languages, I lost count.   Every procedural language is fundamentally the same.   The craft of designing and executing successful software applications is what will take a lifetime to (never...) master.   Perl is a very powerful tool indeed, yet, it is but a tool.

Remove the last word from your thread-title, and ponder carefully the omission...

“What should you know before you start to learn?”

If you use just the procedural subset of Perl you may be right.

Jenda
Enoch was right!
Enjoy the last years of Rome.

An open mind and a free spirit!

• First make it Readable, then make it Correct. Pretty comes last.
• Try It And See.
• Keep a temp.pl file open.
• Use prints everywhere to see what happens.
• Be willing to learn independently.
• Only you can do the learning for you. (No pain no gain)
• The amount of time you spend pondering the question and its presentation needs to be greater than or equal to the amount of time you want others to spend answering it.
• If you can't organize the question clearly, then you likely have problems with the problem definition. Recurse.
• Be thankful but not obsequious for help.

Thinking back to the mistakes I made in my first year of perling ...

• Don't use Windows;
• Learn C and/or assembler;
• Learn how to ask questions well

I realise that the first of those may be somewhat controversial, but I found that by using Windows, I didn't learn as quickly as I could all the tools that support a perl user on Unix-a-likes, because by the time I switched to a Unix environment I'd learnt horrible labour-intensive work-arounds. I'm *still*, 15 years later, learning better alternatives to those. Using Windows crippled me as a tool user.

In your second year as a programmer (not necessarily your second year of perl!) you should learn how the OS creates processes, how they talk to each other, how I/O works, and the basics of filesystems - what dirents, files and inodes are and how they're related. MJD has two excellent presentations on this.

With regards to "Don't use Windows", I would change that to "Use at least more than one operating system". Knowing only one (kind of) operating system makes you blind for things that could be different. Very often, I see Perl programmers simply take (and propagate) things as a fact, like "file systems are case sensitive", "you can delete an open file" or "file locking needs cooperation", when they happen to be just quirks of the one operating system they use.

Of course, Perl is more geared towards programmers wanting all the world to be like (some incarnation of) Unix, but across with unixish operating systems ranging from HPUX over Linux to OSX, many assumptions don't hold true. Being able to quickly identify and question your assumptions is a great tool, and being exposed to a diversity of operating systems helps hone that skill.

"Use at least more than one operating system"

Redhat and Debian? ;-)

Of course, Perl is more geared towards programmers wanting all the world to be like (some incarnation of) Unix, but across with unixish operating systems ranging from HPUX over Linux to OSX, many assumptions don't hold true.

Yeah, but don't overdo it. The other extreme (which you find voiced on Perlmonks every now and then) is the assumption that every piece of Perl code should run on every platform under the sun (where "every" often turns out to be "Linux" and "Windows"). I wouldn't be surprised if more than 90% if the code written out there is written to solve a particular problem/requirement/job for a particular machine. It doesn't make sense to spend an effort in making your small script cross-platform if it's going to cost millions to port the environment it runs in to a different platform. It'll be a wasted effort.

While both of you said sane things, we're now diverging from the original answer. If we start giving advice along these lines, we're way more advanced, and giving advice about portable programming and Module-Quality (through testing).

Modules should not only be tested on as many as possible OS's (and versions thereof), but also on as many versions of supported perl versions, threaded and unthreaded, 32bit and 64bit, with or without longdouble and with or without DEBUGGING.


Enjoy, Have FUN! H.Merijn

Ok, english

> Ok, english

Not necessarily, but reading skills certainly help! :)

Cheers Rolf