Free eBook

There are a few ways that you can get a free ebook copy of our book:

  • Borrow a co-workers and never bring it back, risking bodily harm
  • Illegally pirate a copy, depriving children of food and shelter
  • Suggest topics that we can write about on this site, maybe being famous for a week or getting a free ebook version of Effective Perl Programming.

Our publisher, Addison-Wesley, would like to give out one free e-book per month to motivated Effective Perler readers who suggest a topic for one of our weekly posts. We had 120 Items in the book, and as of September, we’ve already added about 35 Items to this website. We need your help to find more things to research and present. We’ll try to choose one reader-suggested idea per month, and the first person who suggested that Item gets the free ebook.

It’s really simple. Just comment on this post telling us the topic that you’d like us to write about. It doesn’t have to be purely Perl but it should be related to Perl programming somehow. Ideally it’s a topic that isn’t already covered somewhere else. You don’t have to explain too much (although we might ask you to clarify if we like your idea). If you don’t have a suggestion of your own, chime in to support someone else’s suggestion.

Leave a comment


  1. Strategies for Refactoring Defective Perl Scripts into Effective Perl Modulinos

  2. Something that keeps coming up in the beginners mailing lists and other forums is the lost of precision in floating-point arithmetic. Perhaps you could address this.

  3. I bought a hard-copy of the “Effective Perl Programming” book and absolutely love it! I have been taking it to work every day (because I read it at home and refer to it at work) and it is getting quite beat up – I would love to have the eBook to use at work and save on the wear and tear.

    That being said, here are some topic ideas:

    #1 A quick DBD::Gofer tutorial – there is a half page mention (Item 109) in the book and I’ve read the documentation on CPAN, but I would love to have a real-world walk through.

    #2 A “Getting your feet wet with Moose” guide. I know there are resources out there for Moose – I just haven’t been able to get into it yet :oops: – I would enjoy reading your perspective on an introduction to Moose.

    #3 I read and re-read “Item #55 – Make flexible output”. It was an eye opener for me, so if there are other “Make flexible [something most people hard-code]” topics, I know I would benefit from that.

    Thanks for a great book, and a great blog!

    • Those are all good topics, but someone has already beaten us to the punch on most of them, and they’ve done a much better job than we can do. :)

      If you’re looking for information on DBD::Gofer, the best bet is one of Tim Bunce’s talks. He’s given several at OSCON and other places, and you won’t get a better introduction than that. There might be video of his talks out there too.

      There are also already many Moose tutorials out there, including the stuff that chromatic covers in Modern Perl: The Book, the Moose docs, and the Moose intro I wrote for The Perl Review.

      • I will definitely search for Tim Bunce’s talks – thanks for that tip!

        You persuaded me to subscribe to The Perl Review too (not that I needed much persuading at $5) – I am reading your Moose article now.

        Thanks for pointing me in the right direction!

    • Here’s another flexibility Item: Make your methods know as little as possible. This wins our free eBook for December. Contact me to claim it.

  4. I’m probably never going to get invited to give a talk on Perl, but a couple of idea that might appeal to newer users:
    1 – go through the built-in commands list, explain what and why you would use each with more depth than is usually found. Take 5 at a time maybe.

    2 – find a couple of ‘guest’ posters to talk about what in Perl helps them the most and why. Special ways they’ve used pm or own code to do things that just made them excited about Perl.

    After years, I’m still teaching myself those two things over and over. “oh, you can use that to do that?” cool! I get those moments 15-20 times a year. I’m trying to catch up with 6, but it’s a whole lot of work. I don’t read the dictionary, but word-of-the-day sure helps me in that respect. A Perl of the day would be awesome for the website.

    • Go through perlfunc and redocument every one of them? There might be something in the general idea, but the answer is to know what’s available and use them when you need what they do. So far I think perlfunc does a pretty good job at that. The trick is to know how to use a handful of them together to accomplish something interesting.

  5. I would love to see some info about deploying perl applications. This is a field were we are not at the same levels as other languages (specially java). There are many ways to deploy applications, but we need to supply a default best practice.

    I gave the same suggestion for chromatic’s book. However, I think it’s too late for that book (draft is ready)…

  6. 1. Structured exception classes and try/catch implementations. Which of numerous CPAN modules on the subject is sexiest nowadays, when does it make sense to use one, etc.

    2. Less typical file access (tricks like mmaping, tie::file and similar)

    3. POE (or maybe some other event-based programming toolkit)

    4. Multiprocess communication (recommended modules for remote calls between processes, in both single-machine and multiple-machine cases).

    • This suggestion wins the free PDF version for November. I’m working on a POE Item, but it’s taking a while since there are so many cool things you can do with POE. I’ll get it out eventually, though :)

  7. An overview of the various web platform tools, e.g. Plack, Catalyst, HTTP::Engine, CGI etc would be very useful. I haven’t seen one that covers all of the new developments in this area. Plain old just ain’t sexy anymore!

  8. Perl Golf Tricks.

  9. Effective arguing with a pythonista or rubyist

    • The answer is to not argue. Live and let live is what I say. There’s an interesting quote that I’ve seen attributed to St. Ignatius of Loyola: “To those who believe, proof is unnecessary. To those who don’t believe, no proof is possible”. Or, was it Mark Twain who wrote the bumper sticker “”Never argue with a fool; onlookers may not be able to tell the difference.”? I like General Patton though: “Wars aren’t won by winning battles. Wars are won by choosing battles”.

      I get along very well with people who like to use other languages. I let them do most of the talking. I don’t try to refute what they say, although I do ask questions. I don’t push my Perl on people who aren’t that interested in it. I like the language just fine, but I also like Ruby which is like Perl crossed with Smalltalk (my other favorite language).

      You may have heard of Steve Yegge, an opinionated but entertaining and enlightening techie. I think it’s a huge compliment that despite all of his Perl bashing (some of it deserved), he still admires the Perl programmers:

      As I’ve done for a great many other programming languages, I’ve bashed on Perl’s technical weaknesses at length in the past. To my continued amazement, the Perl folks are the only ones who never get upset. They just say “Haha, yeah, boy, you’re right, it sure is ugly. Heh. Yeah, so, um, anyway, I’m going to get back to work now…” It’s awesome. I’ve gained so much respect for them. It’s almost enough to make me go back to programming in Perl.

      That’s the Effective Perler: the guy who gets the respect of even the people who hate Perl.

  10. Zaphod Beeblebrox

    I would like to see an article on how to draw a graph or chart of data in Perl, also how to draw a flowchart or other kinds of graphical presentation.

  11. Enterprise-y stuff like working with Web Services, JSON

  12. For Windows users, install and configure the Less pager (less.exe) for viewing Perl documentation. Less provides backward movement in documents and search using regular expressions. The search feature actually makes a good platform to test and experiment with regular expressions.

    Download from and copy less.exe to a directory in the PATH.

    Set the PAGER environment variable to point to the path to less.exe so that perldoc will use Less instead of the Windows default more pager. (Python help and documentation will also see the PAGER variable and use Less also)

    Optionally, set the LESS environment variable to any less options commonly used

    Pipe long output of commands to less for backward movement and searching:
    perl -V | less
    parrot_config –dump | less

  13. I would like to see more references to PDL and Regexp-Grammars in books. I understand that like moose they are very specific and they can not be covered in detail in a book like yours, but talking about them is enough for people to try and hopefully to make questions in forums. This will increase the user cases and how-to examples that would help new users googling for it.

    • I’m planning on some PDL articles. Since I haven’t used PDL in a long time, I’ll have to do quite a bit of research to get up to speed with it. Also, since I haven’t done any serious math in a long time either, I might have to relearn that too. Besides the simple stuff, I’m thinking of showing some nice matrix operations or some other things that would be horribly ugly with normal Perl syntax. Thanks, :)

    • Pau Marin wins our free PDF version of Effective Perl Programming for October (but you’re email isn’t working, so you need to contact me). I’m working on a PDL article, but it’s taking longer than I expected. I want to make it really good, so just be patient. It is coming though.

  14. I’m not interested in a free eBook, because it’s already on my desk and in good company :mrgreen:

    However, in my search for “self-reliance and independence”, every now and then I get stuck with something. This time it’s perl bytecode.

    I did my homework, reading RTFMs, and googled often, but never found the whole story: to be more accurate, I was looking for a simple method to get perl bytecode from my programs, in order to use it to skip the compile phase.

    You see, the question is simple, but the answer ain’t.
    I’ve already looked at B::C modules, worried by “higly experimental” disclaimer…

    I would be glad to know something more.

    • The answer is simple too. You can’t reliably do that. Now you can stop looking, or you can wait until Perl 6. :)

      • Thanks brian, I’ll wait.

        A masters of mine once said “you will run into Perl’s limitations”, and he was right :smile:

        However I choose to stay with Perl.

        I’m grateful to that master, because he taught me the most important lesson: to never switch off my thinking cap.

        Talking about masters, in one of my classrooms there was a Leonardo Da Vinci’s quote, written in big capital letters, made of white stone: “tristo è quel discepolo che non avanza il suo maestro”, meaning that “he is a sad disciple who can’t surpass his master”.

        It seems a daunting task this time :wink:

  15. I thing I just struggled with in the last week was how to handle changing a serial program into a threaded program on Windows. I’ve done forking on unix before but I wasn’t grokking threading.

    I asked a question and dug through some other docs and it didn’t quite click until someone mentioned using Thread::Queue to create 2 queues (one for handle file processing and one to handle the data returned).

    What I think it boiled down to was an example that takes a serial program and turns it into a threaded program.


  16. Hi, very useful book. Gave me some good insight. Anyway I find that what I use most in daily practice is “running OS commands”, capturing and parsing their output, checking for return codes and error messages. I’d like to see some advice for this in the book. I already came across some perl programs which use a specialized sub do_command() which uses Proc::Reliable for timeouts and returns return_code, stderr and stdout in different variables when called in list context. Appreciated, greetings


  17. Thanks for the great tips on Perl. Here is what I’d like to see tackled.

    1. Identification of pre-UTF8 encodings (ISO, Windows, Mac, etc.) and conversion into UTF-8.

    2. Recovering UTF-8 encoded text that has been corrupted, e.g. the Greek word δοκιμή appears as δοκιμή or, even worse, Ã?´Ã?¿Ã?ºÃ?¹Ã?¼Ã?®.

    3. Constructing regular expressions to match mixed Right-to-Left and Left-to-Right text.

    4. Turning a perl script into a distributable binary without the Perl Dev Kit.

    Thanks again for your excellent work!

  18. Use of ‘state’ instead of ‘my’ or ‘local’

  19. I would like to see a “maturity hierarchy” of language features. That is, a list of operators and the like that new learners need to master, up to the “Who uses that?” level.

    By way of example, I saw a thread on Perl Monks the other day, where a solution was to use the flipflop operator ‘..’. However, the asker was very new to Perl Monks at least, and judging by the question, probably to Perl, and perhaps even to programming. Since this operator is overloaded, and has multiple forms, it’s often misused by those unprepared to investigate it. I wouldn’t suggest the flipflop operator to a newbie, and perhaps not to anyone — if you are mature enough to find it, you should be mature enough to deal with the behavior, which may be unfamiliar and unusual to you.

    In the same vein, there are lower maturity and higher maturity features across the language. It would be handy to have a well-vetted table as a guide for learning and for advising others, and for thinking about creating maintainable code in a team environment (with a suitable balance between readability and magic incantations).

    • There aren’t that many operators to know, and I’d expect a beginner to know all of them. For the ones you don’t know, there are the docs. As a beginner, when you are using something new, you should read about it.

      The problem comes in when people guess at what features should do based on their experience with other languages. People also think a language should be intuitive, but that’s never going to happen because not everyone thinks the same. I simply read about the features instead of thinking I know what they should do ahead of time.

  20. Guidelines on writing cross-platform Perl. In my shop, we now have Windows and Linux and I would love to have just one set of libraries rather than 2. I suppose it’s more about ensuring you use commands that are usable amongst the platforms or avoiding OS commands altogether by using Perl libraries instead.

  21. Asynchronous GUIs and concurrency.

    1. I’d like to see something exclusively devoted to Moose OO Programming in Perl (a book). This is a big lacunae in this topic as it currently stands, Moose has to be picked up by hit & trial.
    2. Another topic(s) whose need I’ve always felt is the post-code activities topics,viz.,
      • Testing
      • Benchmarking
      • Code Coverage
      • Profiling
      • Logging
      • `An Unashamed’ & thorough treatment: typeglobs,
        package variables, symbol table manipulation.

    in a book of only dealing with the above.

    • There’s already a book for Moose by Dave Rolsky.

      The rest of the topics I’ve covered in either Mastering Perl or Intermediate Perl. Indeed, most of your list is half of the table of contents of Mastering Perl. :)

      • Thank you for your answers. I have the Effective Perl books (both editions) and rate them very highly. I am of the opinion that it should be a compulsory read for all Perl programmers. We wouldnt be seeing the write-only codes :smile: out there. After going though this site, you should bring out a “More Effective …” for the topics you cover here.

        The Moose book suggested is just a re-hash of perldoc Moose. :sad: What about you taking that up :smile: The Intermediate Perl title is unfortunately out of print in India.

  22. v-strings and guidelines for their usage in our code is a much needed topic, on which every author has their own opinion, but alas, no concrete guideline.

    • My advice is to not use v-strings at all. Problem solved. But then, someone else will say something different and you’re back to where you started with the multiple opinions.

      My fundamental principles that feed into this are:

      • Don’t use things that people don’t understand (see David Golden’s Version numbers should be boring).
      • Don’t worry about side concerns until you don’t need any more time to solve the problem your solving.
      • When you start fiddling with the bits that seem like best practices or purity but don’t help solve your problem, go solve some other problem.
      • If you’re problem is software, ask yourself if you’re just inventing problems so you can maintain a hobby.

      There are two things people want to know about versions, and I don’t think v-strings help with either:

      • Is this version bigger than this other version?
      • Is this version the same version?

      I think we can do that will simple strings and move on in life.

  23. Looking at ways to deploy Perl code in Linux/Unix environment. Use a CI to automatically run the unit tests, package and release the perl projects (similar to maven release plugin?) and into a common repo (similar to nexus?)

    The shop I am working in has both Java and Perl. For Java we have the jenkins CI and use maven release plugin to manage cod version and releases. Is there something equivalent for Pel (RPM and carton are available but there seems to be no good literature on best practices for these two tools?)


  24. I bought a hardcopy of EPP in early 2003. I read it regularly, still good tidbits. Love the website too. Wondering if there is enough in the second edition to warrant buying it? What about updating the book to cover all the cool stuff since perl-5.12? In particular working with the various Modern Perl packages: Moo, Mouse, Moose. Clarity into the various new operators and commands.

    • I’ve thought about another edition, but I’m a bit busy with other books. Another edition would not cover meta-object programming, at least until its part of Perl core. I believe that using Moose and friends isn’t effective programming. That there are so many ways to do it is one of the red flags for that sort of thing. There is a Moose book from Dave Rolsky I think.

Leave a Reply

[ Ctrl + Enter ]