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.
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...
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.
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:
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. 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. 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. 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:
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. 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. 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. 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.
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...
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.
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.
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.
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.
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:
I was tired of reverse engineering
Wordpress, Drupal and other PHP content management systems to fit my designs. 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
|
Re: What Worked In My 1st Year Of Perl: LOL
by toolic (Bishop) on Nov 14, 2010 at 14:12 UTC
|
| [reply] |
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.
| [reply] |
|
|
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).”
| [reply] |
|
|
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..."
| [reply] |
|
|
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.
| [reply] |
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. | [reply] |
|
|
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
| [reply] |
|
|
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.
| [reply] |
|
|
|
|
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.
| [reply] |
|
|
| [reply] |
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.
| [reply] |
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..."
| [reply] |
Re: What Worked In My 1st Year Of Perl: LOL
by elwarren (Priest) 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
| [reply] |
|
|
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
| [reply] |
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
| [reply] |
Re: What Worked In My 1st Year Of Perl: LOL
by perl.j (Pilgrim) on Jul 20, 2011 at 18:13 UTC
|
| [reply] |
| A reply falls below the community's threshold of quality. You may see it by logging in. |
|
|
