Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

What Worked In My 1st Year Of Perl: LOL

by luis.roca (Deacon)
on Nov 14, 2010 at 03:17 UTC ( #871271=perlmeditation: print w/ replies, xml ) Need Help??

A list of lists of what has been the most effective in helping me learn Perl this first year.

Looking back, I wish I had spent more time on a number of these list items and/or discovered them earlier in the year. That said, stumbling around is a big part of the learning process and I feel great just having figured a lot of this out. I'll carry all of this forward with me as a foundation to continue learning Perl for the next year and probably for a while after that.

I realize much of this is pretty specific and some will disagree with a couple of the items. Again, this is just what I find has and continues to work for me. I post this both as a record for myself and just in case one or two people out there relate to what I'm doing and find this course of action helpful.

  1. Getting Over My Discomfort with the Perl Documentation: I have seen this over and over more than anything else with regard to learning, improving and excelling at Perl:

    "Read the documentation."

    At one point I remember thinking I wish someone would say:

    "L E A R N how to read the documentation."

    Then I found this post by brian d foy, began using a GUI POD reader (A nice simple one comes with CamelBones) to help me get a good look at all the docs in one long list and, most importantly, #2 on my list...

  2. Making The Effort to Work in The UNIX Command Line: Honestly this is one of those things that, working on a Mac, I always wanted to learn and do well but never got around to it. Thanks to Perl, I was given a really good reason to begin stumbling my way through the command line, learning how to change and view directories, download modules from CPAN, tools from MacPorts and read the Perldocs.

  3. Books: I bought a TON of books this year. Some in digital, some paperback, quite a few in both forms and some were even videos. I'm not going into what isn't on the list out of respect for the hard work of their authors and the people who have and will continue to find them useful. This is just what worked for me:

    1. Programming Perl: I had seen so many posts all over the web about how this was not a good book for beginners or that it's outdated. I find it to be a pretty approachable book especially when you break it down into sections or chapters like one would the Perldocs. I've been getting in a good rythm of using it alongside the documentation for further reference and the Perl Cookbook for further examples. It's become my blue blanket.

    2. Mastering Regular Expressions: I picked up this book early after seeing how much importance many people placed on regexes and how many people seemed to put off learning them. Having a text editor that supported regexes helped push me to learn them. I have to say that I really love this book along with Programming Perl. The book has a nice balance of technical detail, relevant examples and is written in an approachable style. Not to mention, I think I'm in LOVE with regular expressions which may eventually lead to counseling but that's a small price.

    3. Perl Cookbook: I've had mixed success with the Cookbook titles from O'Reilly. I actually had a little bit of buyer's remorse when I got this and placed it on the bottom shelf of my bookcase in favor of some of the other widely recommended reading. It wasn't until recently that I picked it back up after getting more and more into the documentation and Camel book. I'm really glad I did because it's a great compliment to those two resources as it reinforces the information in nice bite sized chunks without dumbing it down.

    4. Perl Best Practices: I'll admit that I only picked this up a few weeks ago. It seemed like it was reserved for 3rd year Perl students and above. That was a mistake on my part because I've always had success with style books like this one (Designing With Web Standards, Transcending CSS). Like Mastering Regular Expressions it provides some broader conversations about programming that I appreciate and reinforces why I'm glad I chose to learn Perl. Most critically, while I mostly work alone, I would prefer to form good habits now rather than wait a few years down the road.

      --

      Other non-Perl books that provided added skills, insight, inspiration and sometimes all three. Most of these books could (and should!) be their own post and maybe I'll put that together one day. For now, here they are:

    1. Anathem: Monks around the world working together as their planet's intellectual leaders to face off a unique threat. Honestly, Neal Stephenson must secretly be a member of the Monastery because this has to be one of the closest descriptions of what I might imagine it to be in flesh, blood and stone. This book also single handedly got me off my butt and in the bookstore to buy Godel, Eshcer, Bach.

    2. Don Quixote: To me this book exemplifies the spirit of Perl and it's community that I found so appealling from the start. It consistently finds humor in taking life too seriously and says that even at it's most disfunctional, imagination is one of our greatest gifts. I recently read Larry Wall's talk on postmodernism and I think he might agree that Cervantes shows some of those qualities in this book.

    3. Godel, Escher, Bach An Eternal Golden Braid: A friend of mine recommended this book to me a few years ago. He said this book would go a long way to help me understand why I feel so strongly about visual design and programming being one in the same. He was right.

    4. Labyrinths: There aren't too many people in history who valued the pursuit of knowledge more than Jorge Luis Borges. He was heavily influenced by Cervantes, Lewis Caroll and German Literary Postmodernists to name a few. No one has influenced my creative thinking more than this man and his fantastic works (short stories, sonnets, and essays). Everyone should read The Garden Of The Forking Paths and I would also recommend one of my personal favorites: The Zahir.

    5. Learning the vi and Vim editors: The one year I spent in Catholic school, a 4'10" 82 year old (YES 82!) Sister Margharet taught me how to type. Vim just felt very natural from the first time I ran vimtutor. Because it takes a lot more than knowing how to type to feel comfortable in Vim I ordered this book and it's helping me get up to speed quickly. As a nice extra, it reinforces what I learned in the next and final book...

    6. The Mac OSX Command Line: Unix Under the Hood: A pretty non-intimidating but thorough introduction to using the command line, learning many of the UNIX tools and gaining a great appreciation for all of it.

  4. Spending time on PerlMonks.org: Guidebook, reference, lessons and supportive community what can I say about this site that hasn't been said? I come here at least several times a week. I've felt welcome from day one and hope I can give back just a tenth of what this community has already given me.

  5. Writing down code examples in my sketchbook as well as a text editor: This just comes down to practice, practice, practice. Having a good text editor like BBEdit or Vim to write Perl examples then contrasting that utilizing the very same sketchbook I use to draw people eating lunch at the mall has gone a long way towards helping me internalize syntax and theory.

  6. Asking, trying to answer questions and learning the best ways to do both: 100% of the credit for this goes to the Monastery and the many good people who answer and ask questions better than I have seen anywhere else web or in the flesh.

  7. Having a clear list of goals: Everyone has their reasons for learning Perl. My motivations sprung from changes I wanted to see in both my day to day freelance work and a desire to dramatically move my creative abilities in a new direction. In short:

    1. I was tired of reverse engineering Wordpress, Drupal and other PHP content management systems to fit my designs.

    2. I was tired of feeling forced to practice graphic design and illustration using Adobe software (or any major software for that matter).

    I wasn't exactly sure that Perl would be the answer for me on the first problem and less so on the second. I just had a good hunch so I used these problems as my rough draft of what I wanted to accomplish my goals. I have been refining them ever since. I could get rid of everything else on this list EXCEPT this last item. It always seems obvious but somehow goals are the first thing I lose sight of when trouble starts and the one thing that always gets me back on track.


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

Comment on What Worked In My 1st Year Of Perl: LOL
Re: What Worked In My 1st Year Of Perl: LOL
by $h4X4_|=73}{ (Novice) on Nov 14, 2010 at 10:59 UTC
    I bought a TON of books this year.

    At those prices you also wasted your money. Not one of those books are worth more then $20.00USD. For $50.00 I will personally teach you Perl. =D
      Pay peanuts, get monkeys.

      CountZero

      A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

        Sometimes they're even bad monkies! ;-)

        ack Albuquerque, NM
Re: What Worked In My 1st Year Of Perl: LOL
by toolic (Chancellor) on Nov 14, 2010 at 14:12 UTC
Re: What Worked In My 1st Year Of Perl: LOL
by delirium (Chaplain) on Nov 15, 2010 at 02:46 UTC
    Nice meditation, man! Also, it's good to find someone else who enjoyed both Anathem and GEB. Your list of perl books is begging for an addition, though: Data Munging With Perl. Lessons from that book and the fact (which you pointed out) that no one ever learns regular expressions has kept me employed for the last 7 years.

      Thanks delirium. I loved Anathem and I'm planning on reading it again soon. (Although, I think I may read the Baroque Cycle. I read the first chapter of Quicksilver and liked it.) One good measure of a book is if it gets you interested in reading other books. Anathem definitely did that for me.

      Godel, Escher, Bach is like an inspiration reference. I was wary of reading it since math isn't my biggest strength but my friend put me at ease and Anathem gave me the extra push.

      I know we discuss a lot of Perl books here. Obviously that's appropriate for this site but we learn Perl to solve problems and explore ideas. I really think to do that effectively you have to consume all different kinds of information. (Sounds a little obvious but I've been guilty of putting blinders on.) It's a lot of work but well worth it and should be fun right?

      P.S. I checked out a few chapters from Data Munging with Perl. It looks like something I would like to pick up but, and I'm going to contradict myself after what I said regarding Programming Perl, should I be concerned that it's almost ten years old?


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

        Part of my original reason for learning Perl had to do with the need to do some data extraction and analysis from satellite telemetry data streams. Perl was our standard language for doing satellite integration and testing and seemed like a good opportunity to do my tasks and, at the same time, afford the opportunity to integrate my tools with our integration and testing.

        Data Munging with Perl seemed like a natural enough topic directly related to my problem so I got it as my second Perl book (my first, and the one I used to kickoff my Perl was Bioinformatics with Perl which is not one that I suggest for learning Perl...O'Reilly's Learning Perl would have been better for me). It was too advanced for that early few months, but has in retrospect been a wonderful and useful resource (perhaps much like Perl Cookbook is for you and has become for me, too) that I, too, highly recommend.

        I think that delirium's recommendation is good and suggest that at this point in your learning Perl it is a definite recommendation that I, too, would offer.

        I don't think it is as advanced (in terms of utility) as you worry and that you would find it most worthwhile.

        Just my opinion, of course.

        ack Albuquerque, NM

      I haven't read Anthem but these posts are peaking my interest so I'll go hunt for it.

      Read GEB many years ago for an entirely different reason as I was just beginning to explore some topics in complexity and a friend suggested GEB. I got it and loved it!

      Great meditation! I really enjoyed it.

      ack Albuquerque, NM

        I think you'll be disappointed by whichever of the two A titles you end up reading.

Re: What Worked In My 1st Year Of Perl: LOL
by raybies (Chaplain) on Nov 15, 2010 at 16:55 UTC

    Nice meditation. Here's my one addition for a good step missing in this writeup.

    8. Try small code examples before sticking them into complex programs and scripts: It's common sense, but it's amazing how often I find beginning programmers who don't do this. I think mostly it is due to the fact that many languages require a whole skeletal framework, or a ridiculous "project" file with makescripts, or IDE dependent metadata, and gui descriptions, and so forth before they can even run the simplest "Hello, World" program. The end result is that people don't write simple test programs to try out a feature of a language, they just go from the documentation and examples and then wonder why they don't quite get it. Yet, Perl is an ideal language for this practice. In a sentence of perl, one can test most features of the language. And there are shortcuts (easy to pick up if you read Perlmonks, cuz they are in most examples) built into the language to allow for sample data, data dumping, and argument stuffing. So do it.

      This might be a good place to mention test-suites like Test::More.   Get into the habit of building test-suites for your code as you develop it.   It can be rather ridiculous just how many errors creep into “a simple bit of code that you just whipped out.”   I wrote just such a “little module” last week and, wouldn’t ya know it, every one of the methods had one or more bugs in it.

      I also painfully learned this maxim, and so never forgot it during all the many years since:  

      “Code defensively.   Put self-checks into your code as you write it.   Check every parameter, test every assumption.   Keep them there until you are positive that there are no more bugs.   Then, and only then ... keep them there (forever).
      This also works when you are trying to understand someone else's obscure code. Isolate the part you don't understand and wrap it in something simple that lets you poke and prod it to see how it behaves.

      --DrWhy

      "If God had meant for us to think for ourselves he would have given us brains. Oh, wait..."

      I concur completely with vroom.

      Having the ability to try small code examples was an absolutely invaluable part of my learning Perl.

      Having learned many langauages in my career, the most "bang for the buck" always came from writing code...especially little exploratory snippets that would let me more clearly understand and see the nuances of different constructs and strategies.

      But all early ones were compiled languages and involved a lot of work to go from editor, to compiler to linker to running. At the risk of revealing my dinosaur age background, I began with Fortran on an IBM mainframe with punched cards and batch jobs that usually took about 24 hours for turnaround of a job!

      I learned the value of a more interactive approach with Microsoft's early versions of Visual Basic and when I found a freeware Integrated Development Environment (IDE) for Perl, almost immediately found that my learning curve had become nearly vertical.

      I still use that strategy almost every day. It is as valuable to me now as it was almost 7 years ago when I was first learning Perl.

      ack Albuquerque, NM
Re: What Worked In My 1st Year Of Perl: LOL
by mpeever (Friar) on Nov 18, 2010 at 02:27 UTC

    Thanks for posting this... great topic!

    I work as a technical lead on a team that uses a lot of Perl. One of the more fun parts of my job is helping people become productive with the technologies we use, especially Perl.

    One thing I've stressed to my team is, use perlpod liberally. You don't have to be an expert in perlpod to document your code, but having cleanly documented interfaces on everything you write is of immeasurable value.

Re: What Worked In My 1st Year Of Perl: LOL
by DrWhy (Chaplain) on Nov 19, 2010 at 00:11 UTC
    I don't take advantage of #5 nearly often enough. For me writing code down on paper just makes me think differently about the problem. I've been stuck on an algorithmic problems for hours staring at the computer screen and then start writing sample code down on paper and somehow the solution just pops out in a few minutes of chicken scratching.

    Overall excellent post!

    --DrWhy

    "If God had meant for us to think for ourselves he would have given us brains. Oh, wait..."

Re: What Worked In My 1st Year Of Perl: LOL
by elwarren (Curate) on Nov 19, 2010 at 22:20 UTC

    Once you feel comfortable with your code, I strongly suggest picking up a copy of Higher-Order Perl by Mark Jason Dominus. It is an excellent read and helped introduce me to some new concepts and changed my approach to coding. The author has also released the PDF version free to download on his site http://hop.perl.plover.com/book/

    Cheers

           

      Once you feel comfortable with your code, I strongly suggest picking up a copy of Higher-Order Perl by Mark Jason Dominus. It is an excellent read and helped introduce me to some new concepts and changed my approach to coding. The author has also released the PDF version free to download on his site http://hop.perl.plover.com/book/

      ++ Thank you for the tip and link. I've heard Higher-Order Perl get strong mentions before.

      "...the adversities born of well-placed thoughts should be considered mercies rather than misfortunes." Don Quixote
Re: What Worked In My 1st Year Of Perl: LOL
by perl.j (Pilgrim) on Jul 20, 2011 at 18:13 UTC
    I always come back to this post when I don't know what the heck I'm doing. And that happens a lot : )
    perl.j-----A Newbie To Perl
Re: What Worked In My 1st Year Of Perl: LOL
by Anonymous Monk on Mar 18, 2012 at 04:31 UTC
    I've been learning perl for 4 years now. What got me into perl was his 7th point, have a clear list of goals.
    Just over 4 years ago I was at a job interview and they asked if I new perl, and I didn't. I didn't get the job due to funding, but I came out of the interview with a clear goal: to better myself, and become more marketable, Learn Perl.

    I can agree to most of the advice in this thread. The below 7 points have helped me learn and program in Perl:

    1) Make a new script to test new code, or concept, and name it appropriately.
    It is a lot easier to manipulate a small script to understand the concept.

    2) Read documentation, and not just one source.
    Look at their examples and ask why they did it that way.

    3) Document your code. You will come back to it one day and use it as a reference. Anytime you do something strange, use a new function, modification, or break your own style rules, document it. Your documentation should answer the question
    "What have you done and why is this?"
    Don't forget, your documentation should be written not only for the programmer that maintains your script, but user that runs the script. Also use white space in your code & documentation to make it easy to read.

    4) Pseudocode. I make a distinction between documentation and Pseudocode. For larger programs you should write pseudocode, which describes the purpose of the program, and how it accomplishes the task. Program flow. And write pseudocode for subroutines.

    5) "Check every parameter, test every assumption." This can never be stressed enough.

    6) Learn regex's

    7) learn to use the inline perl debugger: perl -d program_name.pl
    This will help you with more complex scripts, or if you are trying to learn a new function, or just don't understand why the script isn't doing what you expect.
    I have just recently been using the debugger, and have found it extremely helpful.
    I am quite shocked that nobody has mentioned this one, especially considering how powerful a tool it is to learn perl.

    hope it helps

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://871271]
Approved by McDarren
Front-paged by planetscape
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (9)
As of 2014-12-17 23:41 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (40 votes), past polls