Learning Perl

What Hacker News says

1. sirpiladeJun 2022
   Learning Perl by Randal Schwartz[1] was the funniest programming book I ever read. I must give credit to this book if I enjoyed so much programming perl

   [1] https://en.wikipedia.org/wiki/Learning_Perl

   thread
2. G3rn0tiApr 2022
   > Would you mind listing a few of these?

   Sure:

   I already mentioned

   Mark Jason Dominus: "Higher-Order Perl"

   as it is a great introduction of functional programming and goes into all the gory details of how to implement lazy evaluation on top of closures.

   Damian Conway: "Object Oriented Perl"

   Comes to my mind as well. It's basically an introduction to object oriented programming so kind of similar in spirit to "Higher-Order Perl". It even talks about implementation techniques of OO protocols. Neat stuff.

   These books are great even today as they transcend the Perl language.

   A little outdated but still great to read are:

   Randal L. Schwartz "Learning Perl"

   Randal L. Schwartz "Intermediate Perl"

   Brian D Foy "Mastering Perl" (my personal favorite in this series)

   if you need to learn Perl 5 today.

   I personally also liked

   Tom Christiansen, Nathan Torkington: "Perl Cookbook"

   which was basically just a large collection of programming solution recipes but usually also contained elaborate discussions on the various pros and cons of the corresponding solutions. I think it was in this book I first learned about the Fisher–Yates shuffle algorithm.

   Brian D Foy: "Learning Perl 6" is a great book about Raku and is a more recent example of the great heritage of high quality introductory books about programming in the Perl domain.

   Show morethread
3. jbullock35Apr 2022
   Randal Schwartz's Learning Perl (O'Reilly) also deserves mention here. It was fantastic--exactly what an introductory book for a smart audience should be. It had examples; it was informative and very clear; and it was succinct.

   For the most recent editions of Learning Perl, Randal Schwartz has been joined by brian d foy and Tom Phoenix. I suspect that those editions are good, too, but I haven't checked them out.

   It's instructive to compare Learning Perl, which was (I think) under 300 pages in its early editions, to Learning Python, which is nearly 1600 pages long in its fifth edition. There's a lot of value in the longer book---but these two books exemplify very different ideas about what an intro book should be.

   Show morethread
4. captain_perlSep 2018
   Mojolicious is a mind-blowing framework, doubly so with Mojolicious::Plugin::OpenAPI. Unlike Catalyst, there's very few dependencies.

   For a beginner, I'd recommend reading "Learning Perl" by Randal Schwartz first, then read a couple of the online Mojolicious tutorials/blogs.

   Also, beginners should note that there's 2 framework approaches, Mojolicious::Lite (a wrapper) and the full Mojolicious, and mixing up the examples or documentation will confuse you.

   Show morethread
5. TepixJan 2018
   The Camel book¹ is pretty fantastic.

   I hope the "Learning Perl 6" book by brian d. foy will be as good. -- ¹ https://en.wikipedia.org/wiki/Programming_Perl

   thread
6. dodecaphonicSep 2011
   I was 14 and faced the same questions you do. I was surrounded by all these guys who could bend bits with their thoughts and had pointers and stacks for breakfast. They all used see and did stuff that seemed amazing to me at the time. Add to that the fact I felt more like a 'creative', in the narrowest of senses, so I was not sure how to reconcile both my interests, my friends were no help and I did not know much about the demo scene, nor of people like _why and the Processing guys.

   Somewhere along the way I found Perl, and the way from A to B was not paved with incantations. It took me a copy of Randal Schwartz's "Learning Perl" and a Christmas Holiday to get really hooked — the immediacy of thinking and doing and making mistakes and fixing them was paramount to my believing programming was not only for the initiated.

   While I second all the recommendations for having a mentor and working closely with knowledgeable people, I disagree with putting IDEs in the middle and choosing PROJECTS (more on that on a second). I sincerely think there's a great benefit to shortening the path between you and running code, and I believe dealing with compiler errors and linker spewage can be detrimental to the overall purpose of getting acquainted with code and thinking about programs.

   About projects: having something as a goal is definitely a must; I don't object to that, but to all the baggage the term _project_ carries. Have something around which you'll structure your thought, but allow yourself to tinker and to put it in the backburner if it proves itself to be not challenging enough or too daunting a task for your current knowledge level. If you're neither having fun nor being challenged, you won't improve.

   If you want specific tips on what tech to use, it would perhaps be better if you told us what you want to achieve. Do you want to code for the web, to take your designs to the next step, to code simple workflows?

   Show morethread