There Is More Than One Way To Do It

How I did it (not necessarily in this order):

• Minored in Comp. Sci. in college. Learned some CS theory, basic algorithms, and a few languages including C and Modula-II.
• A few years later regained the interest and bought the Llama book (merlyn's excellent book, published by O'Reilly & Associates, called "Learning Perl").
• Bought and read the Camel book, the Mouse book, the Ram book, the Alpaca book, the DBI book (can't remember the animal), the Cougar book, the Wolf book, the Owls book and a few others.
• Read every POD in the standard Perl distribution (except some of the OS-specific ones that related to operating systems that I never use)
• Read many if not most of the day to day Seekers of Perl Wisdom questions here at the Monastery over the course of the past twelve months.
• Dug in and researched answers to many questions, and began replying to SoPW questions. Read just about every question/answer ever posted in the Catagorized Questions and Answers section. Read most of the Tutorials listed. Followed most of the current day-to-day Meditations.
• Spent countless hours pouring over the docs for, as well as implementing solutions with the CPAN modules.
• Oh, and tinkered with every part of the language that has attracted my attention, and for which I've found the time thus far.

I still have a long way to go. There are so many different avenues to explore, both within the realm of Perl, and the broader realm of Computer Science. But it's been a thoroughly enjoyable experience. If I've rushed it, it hasn't been with the intent of "getting up to speed quickly", it's been a mad dash of enthusiasm tempered with a desire to be thorough and accurate in my learning; I've enjoyed every minute of it.

There's so much more to be learned... :)

Update: Woops, in my excitement, I just gave you the twelve-month approach. ;) Seriously, start with merlyn's Llama book and the Alpaca book (Learning Perl, and Perl Objects, References & Modules). Then move on to the Camel book and the POD. After that, choose books based on what attracts (or demands) your attention next.

Update 2:One more thing: Thanks for all the encouragement since I first showed up here, everyone!

Does anyone of you know the book by Farid Hajji "Perl" published by Addison&Wesley?? Is it any good? It is the only one i have now, but i don't know what to think of it.

I don't have any feedback on that book, but this is my advice:

I taught myself over a reasonable amount of time by collecting the O'reilly library. Those books get addicting, so watch out. The two best (I'm sure many will agree) are Programming Perl (the Camel) and the Perl Cookbook (the ram). Personally, I think O'reilly writes publishes the best books, but that's just me. Since you are a CS student, those two books should be sufficient to get you well on your way. Beyond that, read davido's post closely. The tutorials on this site are fantastic. Good luck & have fun!

BTW: I get my books from closeout book stores/web sites, so they are very inexpensive.

update: I meant O'reilly PUBLISHES (not writes) the best books, thanks for the catch davorg . And how could I forget -- you need to get Perl Template Toolkit! ;)

I found the book "Perl: The Programmer's Companion" immensely helpful when I started out. It walks you through different areas of functionality that Perl has (regexes, file IO, control statements, etc), and has a style I found very easy to follow.

http://www.amazon.com/exec/obidos/tg/detail/-/047197563X/002-7516171-1500024?v=glance

Perl is about practical. Perl is about getting results fast. Perl is not about correct. There is no one correct way in Perl. As a result it is not necessarily the best language to learn first when you perhaps want a language that trys/forces you learn about structured programming. In some ways Perl is like presenting a 16 year old with a motorbike and encouraging them to play in the traffic. The results may well be spectacular but.....

Thanks for all those hints i guess I can now get on my way to learn Perl and enjoy doing so

That sounds like a good plan. I would also suggest you get some exposure to C.

cheers

tachyon

The OP is a computer science student, so I'm assuming that he/she/it has a fairly good grounding in programming (possibly an unwarranted assumption based on the horror stories I hear about some CS courses, but that's another issue).

With that and a copy of the llama book, I suggest finding a little project where you need some code, then find some perl code somewhere on tha intarweb that claims to do the job, and then learn perl by fixing that code because it's invariably going to be buggy (with insecure being a subset of 'buggy') and/or not a perfect fit for your task. I learnt perl by downloading some of Matt Wright's scripts and fixing their most obvious bugs. This might be a useful exercise, even though there is now the bugfixed NMS versions of them.

IMO, perl code is correct if:

• it works (and you know it works cos you've tested it)
• it is documented
• someone else can understand it
which is exactly the same standard I would apply to code written in any other language.

I guess trying to learn the correct way to code in perl right from the start may actually hamper your progress. Perl is about getting things done. Start by writing Perl code to do basic things and then move on from there. Along the way, expose yourself to other people's code.

It's a bit like learning how to walk (or learning a language). If a child tries to start walking "correctly" when he first learns to walk, he may never learn how to walk, because he'll be preoccupied with doing it right than actually taking small steps towards walking.

Absolutely. Just start writing code. You'll only truly learn by doing. Just like you can study Italian in a classroom, but until you go to Italy you don't really learn how to use it. Studying Perl from a book will give you the rules, the grammar, the parameters. But it's after you sort through a dozen server error messages to make your code work, that you will really learn a computer language.

Having said that, I never really learned Perl until I got to the monastery. Why? Because the books may talk about "use strict" but it's importance doesn't really get emphasized until a dozen experienced monks rip into your code and make it an issue. Take it in stride, they are only watching out for you.

Now, write some code and post it here, we look forward to it.

Update: Typos


—Brad
"Don't ever take a fence down until you know the reason it was put up." G. K. Chesterton

I'm an opponent of the "just write code" approach, mainly because it's how I got started and now I regret it. I wrote some shagnasty code back in my early days (which as you can probably guess was CGI scripts). I think some of my misguided code came from my CS learning being in its infancy as well.

That's why I enjoyed learning Java, it wasn't very tolerant of my misgivings. However, that methodology only goes so far. TIMTOWDI is a great concept, but IMHO there is something to be said for learning to do things in the most efficient or maintainable way (not implying Java enforces either of those two concepts, rather learning would enforce those concepts) And for that reason I don't approve (personally) the "just write" approach, but what I call the workbook approach...write programs and keep reading.. don't stop either, let one guide you in the other. Let your programming interest guide your reading and your reading guide your style. *end of ramble*

---

Grygonos

Check our Tutorials, especially Where and how to start learning Perl by woolfy.

Then you may read How I learned Perl by brian_d_foy.

Welcome on board.

Nobody but yourself can tell you if you are coding "correctly": the only proof is whether it gets the job done "on time, on schedule".

Step by step you will find ways to improve your coding (making your code more maintainable, more efficient, less dependant on wheels you have re-invented).

Does this mean that you were coding incorrectly before? Not at all, just that you have evolved.

Everyone makes errors and this is the way to learn. The important thing is to code, code, code. Soon you will see Perl-code written everywhere (only a few days ago I was thinking how nice it would be if the GPS in my car could be programmed in Perl -- everyone is allowed to daydream!).

"Your mileage may vary" as they say, but just try to collect a lot of miles first.

My personal favorite for teaching the "right" way to learn Perl is Elements of Programming With Perl, by Andrew L. Johnson. I already knew a little bit of Perl when I bought this book, but it taught me a lot more. It also seeks to teach Perl in the context of the classical computer science stuff, so you learn less about scripting, and more about algorithms and development. This book discusses the importance of warnings and strict.

Mind you, Learning Perl will teach you a right way, too. Namely, the one where you get stuff done really quickly. You just won't learn much about the big words of computer science :-)

May I add that of great value are the perl books from Manning. Specifically, I fount Object Orientated Perl by Damian Conway (TheDamian) and Data Munging with Perl by Dave Cross (davorg) useful. The first chapters of these books give great explanations of more general basic perl.

You might also look at the Sams Perl in 21 days book. I had a friend learn Perl via that book and he was quite happy with it. That being said, the O'Reilly books are hands down, IMHO, some of the best to have on your bookshelf to reference.

Good luck!

When I was a CS student in university, I did a lot of programming to fulfill assignments. Of course, these had to use a particular language, a particular style or component or methodology; after all, the assignment is intended to develop understanding of some concept, and to test the student's ability and dedication.

But there were also many programs or program bits which I wrote to determine something for myself. In particular, I remember writing a program to determine the frequency distribution of files of various sizes. I used 'find' to explore the file system and extract the size. In further processing I categorized the size logarithmically: 0, 2^0, 2^1, 2^2, 2^3.... It was 15 years ago, so I don't remember the details exactly, but I definitely verified that well over half all files are under one 4K block .... in fact I believe at least half are under 1K. It would be interesting to repeat this experiment now that I work for a mega-corp, with access to terabytes, maybe even petabytes, of storage. After all, my personal computer has more hard drive than that CS department computer did then.

Whether it's to explore an idea you have, to verify some claim from class, or to implement free study/honours projects, there are many situations where you are free to use the language of your choice. Use Perl to implement simple programs, and gradually you will become more confident in using it.

That's my advice.

However, "just coding" in Perl will lead you down all kinds of dark and vile paths and trying to read other peoples' Perl code will likely make your head explode. There is a reason advocates of other languages refer to Perl as a "write only" language.

However, if you have a quest to "do it right" a lot of what was suggested here will hamper you. Perl's greatest advantage as well as its achilles heel is the infamous TIMTOWTDI (There Is More Than One Way To Do It).

Since you are a Comp Sci student that suggests two things to me. 1. You have little coding experience. 2. You are already supposedly being taught the "right way" to code. Therefore, rather than "do it right" I would suggest two alternative paths.

First, rather than trying to determine what is "right" about Perl, just make Perl do what you **want**. This is a big reason why I like Damian Conway. Perl did not support Design by Contract, so he created a module to make it do so. Perl is so rediculously flexible, trust me, you can make it do what you want and not be constrained by what it currently does, nor by what others currently do with it.

Second, as you gain more experience coding **then** start to really explore what makes Perl unique. If you follow the first path, you will begin to find this out anyway.

Keep in mind, you can do almost anything in almost any language. The only real reason for learning multiple languages is to gain "alternative" view points to solving problems. You don't really have enough experience (I am guessing) just yet to make that a worth while effort. However, by applying what you **do** know to Perl, you can begin building that experience as well as see what it takes to twist Perl into your prefered view point...

Well I already know C C++ Pascal Java Javascript and so on, but I have to use Perl at work and now after just a few days of working I must say I really start to like, love it. So I want to learn it a "good" way not like other languages which might be nice as well but I just learned them in a way that I just can't stand them anymore ( eg C ). (OK my Prof was really bad at that time but still)

Then I would suggest doing some more generic software engineering reading and then applying those concepts to Perl. That's the nice thing about Perl; if it does not support what you want, you can add the support yourself. But thanks to CPAN, it is very likely what you want has already been done for you. Other languages will generally constrain you to the thinking of the time.

Authors I like in this realm include: Robert Martin and Steve McConnell

Others I can think of right off include Martin Fowler, Grady Booch, Ivar Jacobson and Donald Knuth. I could probably list some more but would have to go home and look at my bookshelf.

Concepts you might find interesting include: Literate Programming, Extreme Programming, Aspect Orieinted Programming, Design by Contract and Functional Programming.

You might not agree with all of these but applying them in Perl will certain have some interesting results as well as expanding your skills.

When it comes right down to it, the only thing really **right** about Perl is that it may be the only language in which you can apply ALL software development concepts, good and bad, new and old and those yet to come. Other languages tend to do what they do and that is it. Applying new concepts to the language means either waiting for the language designers to pick up on the idea or corrupting the concept in some way so you can crowbar it into that language.

In otherwords, don't worry so much about learning Perl. Use Perl as a self-learning sandbox to learn generally good programming techniques. Since Perl makes so much of TIMTOWTDI, in the end, as far as Perl is concerned, there is no right way...