Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

Recommendations for a self-taught Perl programmer

by silent11 (Vicar)
on Nov 16, 2006 at 17:54 UTC ( #584538=perlquestion: print w/replies, xml ) Need Help??

silent11 has asked for the wisdom of the Perl Monks concerning the following question:

I'm a self-taught Perl programmer. For most of my *professional* career I've been either in website operations teams, or I've been a web designer that dabbled in Perl/PHP/Ruby/etc...

I'm now employed by a company that is mostly (90%) a perl shop. It's great -- and I'm surrounded by incredible Perl Ninjas. In discussing technical topics with them I have come to realize that indeed my experience or possibly lack of formal computer science training is limiting my potential as a programmer. (this is not to imply that schooling is the silver bullet or that self-taughts are beneath those with degrees. I'm not attempting to start a flame war.)

Specifically, I notice that co-workers with more experience and those with CS backgrounds approach problems from a different angle as I naturally would. Now to make a long story short, are there books, or possibly online resources or even brain exercises (?) that you experienced Perl/Techie masters would recommend to help me develop the left-most parts of my gray matter?

I'm open to any suggestions. Thanks in advance.

  • Comment on Recommendations for a self-taught Perl programmer

Replies are listed 'Best First'.
Re: Recommendations for a self-taught Perl programmer
by imp (Priest) on Nov 16, 2006 at 18:46 UTC
    Being self-taught is valuable in that it teaches you to be do independent research and solve your own problems, but it can also leave gaps in your understanding. What specific areas are you finding yourself lacking?

    Your peers with a CS background are likely stronger in the algorithm, implementation, and planning/writing departments. The peers with a lot of industry experience likely have more wisdom about what you should do, versus what you can do.

    The Pragmatic Programmer should be required reading in my opinion, as it addresses common areas where people are lacking in wisdom. Some of the most important areas (in my opinion) are revision control and testing.

    If you are looking for perl specific information then I very highly recommend Perl Best Practices.

    I'm very fond of Design Patterns: Elements of Reusable Object-Oriented Software, but recommend against embracing it immediately. There are some very useful patterns covered, but you also need the wisdom to know when to apply each pattern. I have heard good things about the "head first" version of that book, but haven't read it yet.

    One of the best resources when learning more about perl is this community. Taking a passive role and reading the posts each day is valuable in that you can learn about modules and practices that you were not aware of.. but taking an active role is far more informative. There is a big difference between knowing how to do something, and knowing how to explain it. Frequently when you attempt to explain something you discover that you didn't know the topic nearly as well as you had assumed. After you submit your response keep an eye on the thread and see what you can learn from the way other monks approached/solved the problem.

    You might find the following related threads from this site useful:

Re: Recommendations for a self-taught Perl programmer
by perrin (Chancellor) on Nov 16, 2006 at 18:22 UTC
    I suggest two books. First, "Mastering Algorithms with Perl", and second, the first edition of "Advanced Perl Programming" by Sriram Srinivasan (not the second edition, which is a completely different book).

    I also recommend that you learn Java. One reason is that many of the interesting books and articles about programming these days use Java for examples. Another is that Java has a lot of interesting OO design in it's core libraries, which will give you ideas you can use in perl.

      {snip} and second, the first edition of "Advanced Perl Programming" by Sriram Srinivasan (not the second edition, which is a completely different book).

      What are the diffs between the 1st and 2nd editions? Why choose the 1st edition over the 2nd?

        The first edition is the book I read. It introduces generally interesting concepts like database mapping, code generation, the flywieght object pattern, etc. all in code examples. The second edition is a completely different book, which I haven't read.
Re: Recommendations for a self-taught Perl programmer
by kwaping (Priest) on Nov 16, 2006 at 18:46 UTC
    I think Higher-Order Perl: Transforming Programs with Programs by Mark Jason Dominus is exactly what you're looking for. The whole book is about applying advanced computer science theories and techniques in Perl.

    It's all fine and dandy until someone has to look at the code.

      I second the recommendation of Higher Order Perl. If you don't want to learn a different programming language (which you really should, and it should be different in the way how make is different from Perl, or SQL is different from Perl, Higher Order Perl explores concepts from Lisp and how they apply to Perl. This will give you a different perspective on map and grep, for example. Learning a really different language is even better if the language is different enough, because there are important concepts that haven't found a place within Perl, like the concepts of Prolog (or make).

      Knowing different programming languages is important in your ability to choose the right tool for the right job. If the only tool you have is a hammer, every problem looks like a nail.

        I concur that Higher Order Perl is a great resource and that learning to program in a suitably different language like Haskell can also be very useful.

        I've found a nice little book that works through lots of Computer Science/Discrete Math stuff while introducing Haskell. It's The Haskell Road to Logic, Maths and Programming by Doets and van Eijk. A very nice little intro to functional programming and haskell, and a very nice companion to HOP, IMHO. Sort of kills two birds with one stone (intro to discrete math, functional programming, and another programming language)... wait that's three birds... oh well!

Re: Recommendations for a self-taught Perl programmer
by wjw (Priest) on Nov 16, 2006 at 18:38 UTC
    One thing to note. Don't assume that because your co-workers approach problems differently, that it makes their approach 'better'. There are times when the conventional approach used by those who have been trained a certain way gets in the way of 'just getting the job done'.

    That having been said, it is a really good idea to do what you are doing. And I concur with the recommedation of the two books that were pointed out in a previous post.

    ...the majority is always wrong, and always the last to know about it...

Re: Recommendations for a self-taught Perl programmer
by jbert (Priest) on Nov 17, 2006 at 09:30 UTC
    I think the best brain exercise would be to learn a sufficiently different programming language. There is a perlis (Alan Perlis, not a typo for "perlish" :-) quote: "A language that doesn't affect the way you think about programming, is not worth knowing."

    In that sense, perl, ruby, python, c, c++, java and c# are all too similar. (That isn't entirely fair, because they do have distinct idioms and features, but they are all close enough to each other that if you switch from one to another without being embedded in a culture to absorb the idioms, you'll carry over your existing habits too much).

    Try learning scheme, haskell or ocaml and you'll get a very different perception of how to approach programming problems. In particular, follow a book or set of exercises in that language, since you're not just looking to repeat your current patterns of coding in a new syntax, you're looking to learn new programming idioms and ways of approaching and thinking about problems.

    I don't know of suitable ocaml or haskell resources, but there are quite a few good scheme related books, notably the challenging Structure and Interpretation of Computer Programs - which also has downloadable lectures, How to Design Programs - which is more focussed on design/software engineering than computer science.

    I worked through (most of) SICP, doing the exercises and asking for help on a yahoo study group when I needed it. Some of it was mind blowing to me at the time and I think it has helped me look at certain language features (list manipulations, closures, functional programming) in a new light. I don't mean those tools are always the right ones, but now I have those tools as well as my other ones. And the nice thing is that perl is a sufficiently advanced language, so you can apply them all.

    In fact, coming back to perl from scheme, I can see that a lot of "advanced" lisp/scheme ideas were embedded in perl from the start. Clever Larry.

Re: Recommendations for a self-taught Perl programmer
by VSarkiss (Monsignor) on Nov 16, 2006 at 18:46 UTC

    ... are there books, or possibly online resources or even brain exercises (?)
    Well, a college CS course can be a brain exercise -- at least that's what's usually intended.

    I don't know your location, but do you have access to a good university or junior college nearby? You may want to see if they offer a good CS curriculum where you could possibly audit courses. University extension courses are usually strictly "technology" (one specific language or one specific technique), so they may not offer the more broad training you're looking for, but those are a possibility as well.

    My main point is that if you think it could broaden your view to take a "fundamentals" course, avail yourself of it. Don't worry about "It's too late", or "I'm self-taught and proud of it", or labels like that. Money is of course a consideration, but you may be able to finagle an audit-only situation.

    Good luck.

Re: Recommendations for a self-taught Perl programmer
by GrandFather (Saint) on Nov 16, 2006 at 19:49 UTC

    and in addition to all of the above - hang out here. Read the SoPW's. Read the Tutorials. Read the Meditations. Chat with other monks in the CB. Take a wander through the Catacombs and check out some of the Cool Uses For Perl. There is plenty here for an active inquirer to find and learn.

    DWIM is Perl's answer to Gödel
Re: Recommendations for a self-taught Perl programmer
by wojtyk (Friar) on Nov 16, 2006 at 20:35 UTC
    Mastering Regular Expressions is an amazing read. You'll never look at a regex the same way ever again.

    On a more general scale, Perl Cookbook and Perl Best Practices are both incredible books as well (even though I don't totally agree with all of Conway's best practices, it's still an excellent guide to programming like a programmer and not a spaghetti cook)

Re: Recommendations for a self-taught Perl programmer
by j3 (Friar) on Nov 16, 2006 at 20:49 UTC
    I'm now employed by a company that is mostly (90%) a perl shop. It's great -- and I'm surrounded by incredible Perl Ninjas.

    Oooh. You are very fortunate. I suggest you use these ninjas to your greatest advantage (that is, learn as much as you can from them) while you can. Let me give you n more words of advice though: After briefly discussing some topic with one of them, do not remain in their cubicle continuing to ask questions. Bow to your sensei, get back to your dojo, and write some code.

    Only after putting in some of your own effort should you then go back for more help -- if necessary. Helping folks who need it is fun and rewarding, but that fun evaporates very quickly if you sense that the person you're assisting isn't acting on what you've given them.

More than just your Perl skills
by jdrago_999 (Hermit) on Nov 17, 2006 at 00:13 UTC
    Without going into the argument about "Design Patterns Aren't", you need to make yourself familiar with design patterns. Design Patterns are an alphabet used to make up the words which together become a hacker's phrasebook - the vocabulary of hackology.

    Check out Object::PerlDesignPatterns and for an introduction.

    Familiarize yourself with Object-Relational Mapping (ORM) and when to (and not to) use it. Take a look at DBIx::Class, Class::DBI, DBIx::Simple, SQL::Abstract (just to name a few things related to the topic).

    Spend some time breaking down large problems into simple pieces, like a painter converts the vision of a sunset into curves, color and strokes. Look at the code you write this afternoon or tomorrow morning through the eyes of someone 5 years from now. What will that person need to know about your program? That is what you should document now - while it's still fresh in your mind.

    Get comfortable with strict, warnings, Devel::Cover and Test::More. Together they can help you test your code to 100% code coverage.

    Read "J2EE In a Nutshell" from cover to cover, two or three times. It might open your eyes to both the benefits and problems of a large cohesive system designed to work together (this is not my direct opinion of J2EE, just something I gleaned from doing so myself).

    Read up on "State Machines" and the concepts involved in writing them.

    Develop a skill set that allows you to code well in each tier - database, network, business logic, presentation. Read up on Jakarta Struts (O'Reilly has a book on this) and the MVC pattern. This is how web development should be done (not Struts, but MVC). Once you understand MVC, the popular frameworks like Catalyst and Ruby on Rails will make more sense. Your web applications will be predictable and maintainable.

    You will get to a point at which no programming task or challenge intimidates you, no matter how complicated it might appear from the surface. You can do all this using your Perl (and whatever for the presentation layer).

    Learn how to develop a large application. Although some programming is required, it will become apparent that planning, testing, documentation and communication are all very important and - just like coding - cannot be overlooked.

    Read (daily)

    Prepare for Perl6 by reading the synopsis documents:

    Learn how do deal with SOAP as well as ad-hoc web services.

    I could keep going but I won't.
Re: Recommendations for a self-taught Perl programmer
by coreolyn (Parson) on Nov 16, 2006 at 20:04 UTC

    I LOUDY second imp's recommendation of The Pragmatic Programmer. I too am a completely self-taught anaylyst, and what I lacked for in the study of methodologies I seem to have covered my six via reading and re-reading it. I still don't think like the CS types, which drives them crazy, but my solutions have stood the tests of volume, change, and time which makes it hard for them to write me off or to be the target for the corporate axe.

Re: Recommendations for a self-taught Perl programmer
by planetscape (Chancellor) on Nov 17, 2006 at 00:08 UTC

    Being an autodidact is better than being untaught by any means, so don't let anyone put you down! :-)

    The links here may help.


Re: Recommendations for a self-taught Perl programmer
by lin0 (Curate) on Nov 17, 2006 at 06:59 UTC
    are there books, or possibly online resources or even brain exercises (?) that you experienced Perl/Techie masters would recommend to help me develop the left-most parts of my gray matter?

    I am not an experienced Perl/Techie master but I would like to recommend you to have a look at the MIT Open CourseWare. In particular, I would suggest going to the course list on Electrical Engineering and Computer Science. In there, you will find a list of courses taught at MIT. Each course has all the material (lecture notes, assignments, projects, etc.) freely available. For example, if you look at the course Laboratory in Software Engineering, Fall 2005 you will find a wide range of material including: Lecture Notes, Recitations, Assignments, Project, and Description of the Tools used in the course.

    I hope this helps,

Re: Recommendations for a self-taught Perl programmer
by Posthumous (Scribe) on Nov 16, 2006 at 23:05 UTC
    I'd suggest a slightly different approach, being one of those who came to field non-professionally -- learn the same fundamentals a school would require of a CS student:
    1. Logic
    2. Finite Mathematics
    3. Operating system design -- not the MS "Windows XXX" kind, but the real nuts and bolts stuff
    The list could go on, but you begin to see that you're "re-loading" your problem-solving toolkit with some different basic items. These will help you approach programming problems differently.
Re: Recommendations for a self-taught Perl programmer
by artist (Parson) on Nov 16, 2006 at 18:03 UTC
    Specifically, I notice that co-workers with more experience and those with CS backgrounds approach problems from a different angle

    Do you see any pattern here? ie.. Do you see the pattern in the different approaches? Your personal experience itself might be the great factor to give you the direrction, in this case.

Re: Recommendations for a self-taught Perl programmer
by Limbic~Region (Chancellor) on Nov 17, 2006 at 20:20 UTC
    I prefer to say that I lack a formal education rather than say that I am self-taught. I pitched a book idea to $Publisher over a year ago. The target audience was intended to be people like yourself - non CS-degree toting hackers who wanted to become better programmers. Even with "Intermediate Perl", I feel that there is a large void between the elementary learning book such as "Learning Perl" and the advanced topics such as "Mastering Algorithms With Perl". In essence, they focus on features of the language and not how to think about problem solving.

    To make a long story short, life intervened and I had to back out though $Publisher was very interested. I have continued to collect ideas for the book and still intend to go through with it some day. Originally I had intended to give you a few links but have decided to put them over here instead.

    Cheers - L~R

Re: Recommendations for a self-taught Perl programmer
by toma (Vicar) on Nov 17, 2006 at 06:04 UTC
    Think of some problem that you really want to understand, and write a perl module for it on your own time. Keep changing your code, just to experiment with different ideas that are explained in the great books about Perl. Eventually you will create a great module. Then show it to your co-workers, and see if they agree. If they have different ideas, you will be able to try them out in only a few hours because by then you will have so much experience with the problem.

    The idea is this: to be good, you have to be an expert at something.

    The challenge is to choose a problem that you will really enjoy solving. Don't be afraid to take on a few different problems and drop them until you find one that you like.

    Then, do it again in an area of interest that is far from your everyday. This will stimulate your creativity! Repeat forever.

    It should work perfectly the first time! - toma
      The idea is this: to be good, you have to be an expert at something.

      I don't know whether this is right or wrong, as I myself also tend to think this way; but my experience tries to teach me otherwise, and sometimes I can hardly believe it. I keep thinking that I'm sort of a conman in computing, whilst my colleagues and customers tell otherwise.

      I don't have any formal CS education as well, and I am no expert in any field. But I'm a good trouble-shooter. Show me a box I don't know that has some problem, and in half an hour I'll have the general direction of where the problem might be, and maybe also some accurate hints for things to look at. I'm pretty much a generalist, and in each field I try to do my best in, there are experts which I admire and whose knowledge I'll never reach. I know to ask the right questions sometimes, and I'm good at coming up with funny ideas...

      But expertise is not always required, as in the profession I come from - architecture. A good architect has a good handful of half-baked knowledge in everything, and knows which experts to ask for specifics... but they love their profession.

      And that's my point - to be good in something, love for $subject is required (even if it's a love-hate relationship at times). The rest comes along as it likes ;-)


      _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                                    /\_¯/(q    /
      ----------------------------  \__(m.====·.(_("always off the crowd"))."·
      ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
Re: Recommendations for a self-taught Perl programmer
by NovMonk (Chaplain) on Nov 17, 2006 at 13:38 UTC
    Thanks for this topic: ++. You've put it better than I, and saved me the trouble of asking myself. I'm in the same boat, only probably not so advanced.

    The only thing I would add to the above most excellent advice is, find a mentor. If there's a particular ninja in your group whom you really admire and with whom you naturally seem to "click", by all means approach that person and ask if he or she might consider some sort of formal arrangement. The advantage of that is, you have someone who knows how Your mind works, and who can suggest ideas and examples to you from things you are both very familiar with in your own work environment. It needn't be so formal that it takes up tons of time for either of you-- more just, "I'd like your help and advice, and I'd like you to feel free to jump in and suggest new directions I could take my study." You, of course, would still be doing most of the work-- you'd just have somebody to watch your back.

    And I third (or whatever we're on by now) The Pragmatic Programmer. If only to point out how much I still have to learn, it's been great. And the writing is very accessible and clear.


Re: Recommendations for a self-taught Perl programmer
by jwkrahn (Monsignor) on Nov 16, 2006 at 22:51 UTC
Re: Recommendations for a self-taught Perl programmer
by gam3 (Curate) on Nov 20, 2006 at 14:49 UTC
Re: Recommendations for a self-taught Perl programmer
by abhinavvaid (Acolyte) on Nov 20, 2006 at 10:47 UTC
    Pal, I think you are already at the right place. A couple of years back I had posted some questions on this site similar to yours. But later on realized that perlmonks itself is infact the best site and you get the response from so many good fellow monks for specific tailored questions. For others I think the manuals that available in the perl site should be sufficient.
      Pal, I think you are already at the right place.

      I strongly second that. Communities and discussions do not substitute books, but are important. As I've written several times, I've learnt more from clpmisc than from anywhere else. My first questions were very naive, but I got to appreciate the community. It is somewhat harsher than here, but I have no problem with that as long as it keeps the quality of discussions high; also beacuse its behavioural rule are just out of common sense after all. I discovered PerlMonks later, but the same remarks apply more or less unchanged. All in all they are not in competition, but constitute complementary resources, both in philosophy and partecipating people, out of many others, of course.

Re: Recommendations for a self-taught Perl programmer
by andye (Curate) on Nov 22, 2006 at 12:58 UTC
    I'm no master but:

    - the O'Reilly book on regular expressions in Perl is very good indeed,

    - I've worked in many different languages over the years, and I find that helps. Although I don't have the detailed knowledge of Perl's workings that many people here have (and all respect to them!), I sometimes find it helps to think "well, if I was in lisp I'd do this, and if I was in C I'd do that, so maybe in Perl I should do it thusly"


    Best, a.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://584538]
Approved by Corion
Front-paged by kwaping
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (7)
As of 2023-12-07 09:54 GMT
Find Nodes?
    Voting Booth?
    What's your preferred 'use VERSION' for new CPAN modules in 2023?

    Results (32 votes). Check out past polls.