I've looked into the source code of DBIx::Class recently and found that I don't understand a thing (though I mastered a couple tricks while trying to).
So my question is: which CPAN modules are a must read for someone who wants to learn, and in what order?
If I were doing the same I’d probably start with the ::Tiny space. I’d expect it to be less distracting—fewer edge cases cluttering things—and more idiomatic—terseness lends itself to Perl idiom—in general.
Then I’d attack the medium–large nodes from this excellent document—Map of the CPAN’s authors (large PDF). Update: Web version. Zoom into the bigger nodes then search on search.cpan.org for them. The largest nodes sometimes represent old-school and while exceptional code exists in the old school, not a lot of good teaching examples do (so I say). Authors like Miyagawa, Kennedy, and Kogman come to mind immediately as worth reviewing. There are plenty of others. Basically any module you see recommended here often, look up the author and poke around his or her other packages, as it were.
I learned quite a bit (tie-ing, platform independent filesystem access, etc) by reading the code for File::chdir. It is also a very handy module to use in your scripts, I use it all the time.
I would also add to bvr's list: read the source for modules that you use frequently, since you are already familiar with their expected behavior, you can more clearly see what is being done to achieve that result.
The question is what you want to learn, but it is certainly good idea to study various modules, because you learn to read other people code and learn various tricks. Some random recommendations I can think of
start with smaller modules with clear interface you know and are interested in
once you feel familiar with organization of modules and basics, try something larger
try rather newer modules
look into test suite and into examples
if you don't understand specific piece, try to make reduced example a play with it
It is hard to recommend something specific, but I liked my recent look into Web::Scraper module.
If you're fluent in perl - if don't perldoc ;) - , sugest learn the packages Task::Kensho or Modern::Perl.
These packages do cover comprehensive in culture Perl, since tests until hacks, passing by crawling, modules to developers, e-mail, dates, modern oriented obejct in Perl.
Participe of discussion lists, read the history of list, irc.
Perl have many tricks, the community always responds with enthusiasm =)
Related
Many standard modules are all using straight up perl -- problem is these guys arent using Moosey stuff, so I catch myself wrapping them with Moose or reinventing some simple functions in bigger libraries for convenience.
I wondered if there was any general approach to how developers using Moose incorporate other libraries that are non-Moose.
Being new to Perl and Moose I'd like to have a better understanding of how Moose is used in situations like this, or when it is generally preferred to use Moose vs Perl or even MooseX, or some other package, or whether its arbitrary.
Seems like there are different schools of thought, but Perl being as old as it is -- there are too many conflicting sources, so it's hard to navigate to a consistent truth. I'm not sure what to believe!
Anyone have a definitive source they turn to for "modern" usage of perl? Understand I've only been using perl for a month so I'm green to this community.
Updated
I don't want to hurt anybody's feelings by talking about libraries they love in a way they may not appreciate, so I've removed my side commentary about certain libraries Ive used to refocus on the question at hand.
Thanks for your guidance!
While I do not know what others do, I would be very reluctant to create myself extra work. I do not see any general need to Moosify a bunch of modules that already work.
If you want to inherit from non-Moose modules, take a look at MooseX::NonMoose.
If the HTML generation cruft in CGI.pm bothers you, you can use CGI::Simple.
About Reinventing CGI
CGI is a library which has been thoroughly tried and tested and if it needs improvement, you could build an extension, or contribute/contact the maintainers. You have to remember that modules are only as good as their track record (reliability) and their upkeep. Many people created decent modules, but didn't continue maintaining it, so they sort of fell to obscurity.
CGI is a boat all of its own, which if you think there's a lot of overhead, you could use CGI::Simple or CGI::Minimal. CGI.pm does more than parse querystrings, it also has cookie management (sessions), HTML generation, and other useful functions.
Others have had some criticisms of the overhead with CGI.pm, but that's why they developed FastCGI, which is modifying the server to use a persistent state of the script, thus loading the overhead once, rather than on every page load.
It is possible for you to create another (even better) version, but why bother? Many people may probably tell you, you shouldn't reinvent the wheel, with good reason. CGI has been around for almost 2 decades, with so many users testing it, finding holes, and having patched the holes; however, I'm never a big fan of saying "you shouldn't do something." If you think something could be better, make it better. There are many OSes that exist today just because of that reason, why settle for something that does 95% of what you need, if you need that other 5% too? But I also say, weigh your costs vs. benefits and determine if you want to devote your time to this, or if maybe there's another problem out there that has yet to be solved, that could use a little more manpower. To have something successful, you're going to need to test it thoroughly, and will most likely need to create something that other people would want and (at this point) there isn't much of a reason for CGI-users to be motivated to switch.
About Modern Perl
I think "modern Perl" is an oxymoron. I would jokingly call modern Perl; Ruby or Python.
That isn't to say that Perl isn't useful, because it is, but it's been around a long time. While it has had its significant share of changes from version to version, the most popular, Perl5, hasn't changed all that much; mind you, my definition of change is not adding to the language (new operators and functionality), but deprecating/replacing old features or changing the behavior of existing ones (like for/foreach loops).
Note: Perl6 could be considered modern perl (and does have many significant changes), but it's not widely adopted and was supposed to be released many many years ago (it's the Duke Nukem 4 Ever of programming languages).
About XS
I haven't done much module programming, but if memory serves correct, XS is the interface between Perl and C, which I think allows you to compile your perl modules for faster execution. Consider the PostgreSQL DBI module. There's a DBD::PgPP, which is a pure perl module to interface with Postgres, but there's also DBD::Pg, which I think compiles some of the code using C and takes advantage of some other OS utilities. Compiled modules have the benefit of faster load and execution (there may be some better resource management in there too).
I recently joined a Perl project and I need to start being productive with the codebase fairly quickly. However, I'm finding that I'm getting stuck because I don't know where I need to change or how all the parts of the code fit together.
What are your tips and tools for becoming familiar with a Perl codebase that you have no experience with?
(Note: I realize that there's already a similar question. I'm wondering if there's any Perl-specific strategies.)
First, if the previous maintainers were doing their job well, you should have an extensive test suite and perldoc documentation for each module and script in the codebase. If so, read through the perldoc, and read through the tests. The perldoc should give you an overview of what things do, and the test suite will give you examples of the code being used in context.
Depending on the author, the internal comments may be useful in understanding the intention of the code, so looking through the actual source my provide insights into algorithms, bugs, and intended use as well.
If you don't have any of these, proceed as you would for any badly-maintained codebase: start small, writing programs that try to use the code, and use Test::More and the like to start turning these into a test suite.
In the first case, you may find it to be very simple, in the second, very hard. Peter Scott's Perl Medic can be very useful in assisting you in turning such a codebase into something usable and useful if you're stuck with the second case, and Mike Thomsen's recommendation of Effective Perl Programming is also a good one.
I work on Melody which is written primarily in Perl. It's a rather large code base, and I've found the process of learning the Melody code base is identical to any Java system I've worked on.
It really comes down to just working with it, googling when you see behavior you've never seen before and experimentation.
This book is a great reference for picking up Perl in a serious way. It's not very dense and it will teach you a lot about proper Perl development.
Besides the "similar question", http://perldoc.perl.org/ and an empty test.pl file is a good starting point!
I would like to see a real answer here. The only thing I have is more questions (you don't have to provide answers here, just ask yourself):
Goal
What is the goal of the project, what it is supposed to do?
Who knows the workflow?
Environment
Can you set up the project in a clean test environment?
Does it use a versioning system?
Where are the entry points (i.e. executable files)?
Does it rely on external programs?
Does it require additional system tweaks (i.e. cron scripts)?
Perl code
Is your project using strict and warnings everywhere?
Which CPAN modules are used?
Are there any frameworks used (Moose, Catalyst, probably some ORM, ...)?
Are there any perldocs in the project's modules?
Are there any tests (notably t/*.t)?
I usually start with working on some simple bug report or a simple feature I want to add. While working on code I write comments for code and commit them. Writing tests also helps.
This is more of a use-case type of question... but also generic enough to be more broadly applicable:
In short, I'm working on a module that's more or less a command-line wrapper; OO naturally. Without going into too many details (unless someone wants them), there isn't a crazy amount of complexity to the system, but it did feel natural to have three or four objects in this framework. Finally, it's an open source thing I'll put out there, rather than a module with a few developers in the same firm working on it.
First I implemented the OO using Class::Std, because Perl Best Practices (Conway, 2005) made a good argument for why to use inside-out objects. Full control over what attributes get accessed and so on, proper encapsulation, etc. Also his design is surprisingly simple and clever.
I liked it, but then noticed that no one really uses this; in fact it seems Conway himself doesn't really recommend this anymore?
So I moved to everyone's favorite, Moose. It's easy to use, although way way overkill feature-wise for what I want to do. The big, major downside is: it's got a slew of module dependencies that force users of my module to download them all. A minor downside is it's got way more functionality than I really need.
What are recommendations? Inconvenience fellow developers by forcing them to use a possibly-obsolete module, or force every user of the module to download Moose and all its dependencies?
Is there a third option for a proper Perl OO framework that's popular but neither of these two?
To be perfectly fair, seeing virtually everything interesting these days in Perl world has Moose somewhere as a dependency, I don't see it being much a debt for other "fellow Perl developers".
Chances are they already have it installed as we speak!
Edit: Some statistics:
Moose is currently rated at 65th place on the "Most Depended on" modules list, Aliases top 100, with over 1637 packages depending on it. Thats almost as much as stuff like Time::HiRes , and more than DBI, and I don't think you're as likely to question depending on those would you?
The currently accepted "modern Perl OO framework" is Moose. I'd say make your users download it, or you can bundle it up with your modules in the installation using PAR::Packer.
Quoting from "But I can't use CPAN" (...because my users won't want to install things):
Assuming you're just handling your users a tarball, then Module::Install provides a solution - if you put your script into script/ and then do
install_script(glob 'script/*');
auto_install;
in your Makefile.PL, then not only will 'make install' put your script somewhere useful for you but 'make installdeps' will invoke cpan (or if present, cpanplus) to install all missing dependencies for you.
Well, there's Mouse, which is like Moose but without all the dependencies (and some of the features). It also starts up a bit faster. I haven't tried it myself, but it's generally well thought of.
To add to the existing fine answers...
Some of what was recommended in PBP isn't bad advice, but Perl marches on. When it was written, inside-out objects were the new hotness. Now the Moose has absorbed all. There is MooseX::InsideOut which gives you the power of Moose with the total encapsulation of Class::Std, but unless you work with undisciplined programmers its really not necessary.
Those features of Moose you don't need now, you'll need them eventually. Even if you don't need all of them, with Moose you won't have to use and learn Yet Another OO System every time you need an interesting feature. And god forbid you need TWO features at the SAME TIME!
There is also a Perl Module Object::InsideOut , actively maintained as of 2010.
Kind of a predecessor to Moose, or to be clear: development started independently at the same time as Moose started,
I know it exists but I haven't used it.
After having heard about new parts of the Perl ecosystem, such as Moose, DeclareX, and Catalyst, I thought that it'd be nice to take a look at Perl. Unfortunately, all of the introductory material I can find targets Perl 5.8 or 5.6, and knows nothing about these newer frameworks—let alone features introduced in recent Perl versions, such as the ~~ operator. What resources are available for someone interested in coming to Perl fresh, and wanting to learn the current best-practice way to do things right from the get-go?
While I can read the 3rd edition of the camel book, then work the rest of my way through piles of CPAN documentation and the like, I'd tremendously appreciate a tutorial that doesn't force me to learn a bunch of deprecated ways to do things, just to turn around and unlearn them again when I read a reference manual. Real-world code that's well-documented and uses some of these newer corners of Perl would also be wonderful.
chromatic is in the process of writing a Modern Perl book which is available for preview in his Github account. The recent Catalyst book by Kieren Diment and Matt Trout covers several modern perl practices and the current "Enlightened Stack" as Matt I believe calls it.
There is also work going on for a Moose book, but I doubt it will be available before next summer even if the authors were able to focus on it full time. For learning Best Practices, as long as you take it with a huge grain of salt the discussion in Damian's Perl Best Practices is worth reading. I wouldn't recommend his practices are best, but they illuminate where the conversation points are and you can google around for people's comments on it. The biggest problem I personally had was the OO suggestions it had, and it led me to find Moose which I adore.
Finally, interact with the community. Join a mailing list or three, an irc channel or two, and blog regularly about what you're learning. The Perl community is generally supportive of helping people who really are interested in learning find the tools they need.
Learning Perl, 5th Edition is current up to 5.10. There's even a chapter for the smart match operator, just like you want, in addition to the other new features that a beginner will want. If you want to start learning Perl, that's the book to use. Once you get through it, move onto whatever else you want to do. I'll have Effective Perl Programming, 2nd Edition out around the start of spring too. That will be current up to 5.10.1 (and maybe a little farther since we use at least one 5.12 feature in some code).
You really don't want a book on Catalyst or Moose. Anything you read will be out of date because those projects have a high velocity and the practices change pretty quickly. You're going to need to learn the basics before you dive into the advanced topics, anyway.
To continue as a programmer, you're going to have to get used to not depending on books. I can't write them as fast as stuff changes, so you have to learn from the documentation too. That's just how life is.
There was an excellent talk at OSCON by Paul Fenwick on "Awesome Things You've Missed in Perl" where he gives several code examples and usage tips for using Modern Perl.
The talk was recorded, but it's not on the list of recordings yet:
http://www.oscon.com/oscon2010/public/schedule/proceedings
Here are some other great talks worth checking out that also provide examples of Modern Perl:
Top 10 Perl Performance Tips
Understanding and Optimizing your Code with Devel::NYTProf
Moose is Perl: A Guide to the New Revolution
And finally (not from OSCON):
Larry Wall speaking at Google
Even if this answer is very late, a new book about Modern Perl has came out on 2012. It's called Beginning Perl and is written by Curtis 'Ovid' Poe. It focuses on learning the Perl skills employers are looking for and is for both programming beginners or for experimented programmers who want to learn a new language.
After introduce the language itself, Ovid continue on DBIx::Class, Moose, Catalyst, and more CPAN tools and community's best practices with a lot of real-world examples, demonstrating how you actually use Perl in the workplace, for web development, data processing or system administration. The book was first available for free on the O'Reilly website, but has been removed now (you have to pay for a printed or electronic version).
Hope it will be useful for future readers of this QA.
I would recommend the mentioned Learning Perl 5th Edition followed by Damian Conway's Perl Best Practices (also previously mentioned).
I would like also point you to the PBP Module Recommendation Commentary that discusses the current "community view" of the modules discussed in Perl Best Practices.
Despite what is discussed (or not) at this site, two of my favorite Perl Best Practice recommendations are Data::Alias and Smart::Comments (Even though Smart::Comments is a source filter, you can easily remove it before sending your code to production. It is great for debugging.).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I got into Perl years ago and always found it a fun and expressive language to work with.
I found that programming in Perl makes me quite productive thanks to its low overhead and the outstanding amount of ready-made solutions to common problems on CPAN.
If you're new to Perl, what got you into it?
I was coding PHP for a living, and then heard of their change from :: to \ as a name-space separator. I'm really not joking or being spiteful, but that is really what got the ball rolling.
Not to be elitist, but I suddenly realised that the people I had to collaborate with whom knew PHP understood very little in programming concepts in ways that frustrated me how they could be so blind, the people in the IRC rooms for it were no longer a source of help for my questions, and I usually spent more time answering questions and waiting for somebody to turn up whom could answer mine. Usually I ended up solving it myself.
Most the time I realised was people re-solving the same problems over and over again in increasingly bad ways.
I discovered problematic behaviours in PHP which defied logic and reasoning (like the array_merge_recursive family), and discovered functions that were undocumented in how to use them, and when I reported a bug in the functions, my bug was marked as "Bogus" and I was expected to be psychic.
I had a friend whom was constantly proclaiming the goodness of Perl, so I basically gave it a shot and now am hooked like an addict.
Additionally, my experience in other higher-order dynamically typed languages (JavaScript and Ruby, yes, JavaScript is a more powerful language than PHP in terms of language features) left me a knowledge with many ways to solve types of problems easily, but being restricted in such a way I had no way to use these powerful features. Perl satisfied this need.
Why Perl and not Ruby? I've played with Ruby a bit, but my experience taught me the support and documentation is sparse, the language is slow and immature. Nice it may be, but its still in diminished in capacity against Perl from what I've seen. And it shared PHPs major flaw that it has a huge user base comprised of total novices all doing things the wrong way, and I really wanted to not have to deal with that so much.
It's not nice to be elitist, but once you have tried to explain the same thing to 30 people (and taken an hour to get a simple concept into their heads every time) it reaches a point of frustration. (I can't cope with the 'There is somebody on the internet who is wrong' situation, If I can't SEE it, it doesn't happen)
I started doing Perl during my third year in computer science as a part of 'Scripting languages' course. I have a friend studying biotechnology and I helped her with some data mining scripts for dealing with protein databases (parsing text files, regexps, simple integrity checks). It was all very natural to do in Perl.
Then I got my first part-time job and had to use it professionally. I was responsible for developing set of batch scripts that handled some part of business logic in the company. And it was the task where Perl revealed all its potential. Need to get data from DB? - no problem, just go to CPAN. Need to automate wiki - no problem, go to CPAN. The amount of already created modules is overwhelming and you can be sure you will always find what you need in CPAN.
To sum up. For me, Perl is a swiss army knife of scripting languages. Everything can be done in it and it has huge number of additional modules even for very exotic tasks. And by the way, did I mention REGEXPS?
With Perl (and the expressive power behind TMTOWTDI), programming becomes a creative task. I can write if($expr) { $statement; } if I plan on having many else statements, or I can write $statement if $expr; if that makes more sense (for example, I'm fond of writing:
sub doSomething {
my($toObject, $argument) = #_;
die "No object specified" unless defined($toObject);
die "Object invalid: $toObject" unless $toObject->ISA('Example');
# Do stuff
}
but of course that's not always the easiest, and most expressive way of doing it; so I come up with a better way for the task at hand!). People complain because Perl lets you write horrible looking code; I love Perl because it lets me write code which looks pretty to me (and yes, I can see the downside of having a dozen different programmers writing in their own styles; I'll hold to the idea that good writers can be pretty expressive and understandable no matter how different the subject matter).
With other programming languages, I end up having to think my way through abstraction layers (how will this Map give me Collections whose Iterators I can use to ... and so on). With Perl, I'm usually only one abstraction level above basic Perl. For instance, DBI will give me database results as ordinary, everyday Perl scalars, lists and hashes, so everything I know about these simple, core data structures carries over to every task I put DBI to (Complicated data structures? That's what PostgreSQL is for!).
I've only been using Perl full-time for about a year, but these are the big wins for me, and the reason I first went full-time onto Perl after a year suffering at the hands of Java 1.4's Collections model (don't ask). Other programming languages make me feel like I'm putting together a jigsaw puzzle, as you line up all the modules and packages just right; Perl feels like a box full of Legos, with some "special" bricks (like DBI, CGI.pm and Test::*) thrown in for good measure. There are tons of different ways to solve any problem, and Perl lets you try any of them you like, in any way you like.
I'm still not that long time in the Perl community and what me first brought in was Larry Wall's humor and wisdom. True, Perl has it quirks but the language comes from an understanding of things that is very close to mine so I'm much less comfortable with Python and to a lesser degree Ruby.
I don't do web app's more GUI with WxPerl and it works just fine. I'm very interested in languages also in lesser known like factor, boo, rebol and so on but all in all is Perl my choice. and it's because a mixture of powerful syntax (can be very functional if you like it), the community, CPAN of course, and, like I said before, due to the cosy feeling being in the right place.
Perl is its community, which is the reason to use it both on a social and practical level. (See CPAN and Perlmonks, which likely inspired SO.)
There's a lot of freedom when coding in Perl; you can write some wicked-crazy unreadable hacks, but it doesn't take long once you've gotten a feel for the language (and learned how to use perltidy :-) ) before you realize that well-written perl code can look downright pretty.
It's interesting; I ended up as a full-time Perl programmer after learning it for my sysadmin-type job in college; and now it's my strongest skill. I'm going to stick with Perl for a while because so far the language has been versatile to grow with me. I write a lot of systems software in Perl, and decided to pick up web programming for fun, and Catalyst was there waiting for me. Do I want to try out a new language paradigm? Perl will probably support it. In contrast, when I was coding in PHP for a time, I immediately felt like I was pressing against a glass ceiling.
I work as a technological troubleshooter for a big organization in southern OH. I had to learn Perl to keep some automated network text manipulation systems up and running and eventually got a little excited about it. I eventually thought of myself as a developer and wrote some programs that parsed some database data and made some people’s lives a little easier. But after reading some of the posts on this website and listening to the stackoverflow podcast and even starting to read the book Code Complete from someone’s suggested reading list I no longer have any delusions that I was a developer of Perl or any other language for that matter. However, maybe someday I could be.
I had used awk a few time for shell scripts way, way back in the days. In one ancient project we needed to implement the a TELNET protocol connection, so I wrote a quick version in Perl 4. It worked really well, and I started to really like the language.
Later, I wrote a big full commercial web application in Perl 5, complete with it's own framework and database. I was careful not to use to many of Perl's more esoteric features, so the code looked more like C than Perl. It worked really well, performance was good and the code was easily extended.
Recently I've been working in Java, but I often find myself missing the Perl's loose typing, and its ability to encapsulate things way better than Java. My favorite features were being able to put Perl datastructures (arrays and hashes) and code directly in config files and execute them, and the ability to tie code to syntax like arrays. Both lead to some really slick code.
Paul.
simple syntax, powerful scripting capabilities for win32 and unix systems, and totally powerful regex!
I pickup Perl on my first job where I had to write plenty of automation script for electrical engineers to mine datalogs and format them to Excel and sometimes deal with sql server too. With Perl I could usually get something working rather quickly, so all is good in the manufacturing land. :P
I started using Perl as an enhancement to our build process for embedded development. We needed to develop diverse outputs based on our cross compiled payload and Perl was a great fit.
Our enhancements included floating-point to hexadecimal conversion, S-record post-processing, and checksum modifications.
Not that this kind of work can't be done with many other tools, but I would definitely recommend Perl for build-related work.
What brought me to Perl was when I saw the DBI and realized that I could write the ESQL/C programs I was writing at the time in one fifth the time.
What has kept me using Perl is that the two other languages likely to unseat it are both strongly typed. That is
print "10" + 5;
is a type error rather than 15.
I'm not taking it up. I had to work on a project in Perl a few years ago, and I came to really dislike the language. It has a sometimes-awkward syntax and a lot of crazy gotchas that I found hard to work with. Honestly, I think Ruby has superseded Perl in many respects: it's good at roughly the same things, but has much nicer features and is easier to use.
Perl still has CPAN, though, which even Ruby can't match (although Ruby has a lot of useful libraries, too).
I considered learning Perl last year.
It was the only technologies that I actively decided not to learn. This is nothing directly against the language itself, it just seemed that I would be coming to the party 10 years too late. It is very useful for the shell scripting tasks that it was designed for but for me personally I prefer languages with a stronger coherence.
Perl 6 seems like it's on indefinite hiatus and even when it arrives I don't believe that it will make the language profoundly more compelling.
Also, Larry Wall scares me.
For my situation Perl wasn't the right choice and thats why.
Perl is not as bad as I thought. I used to use it in a couple customer scripts about one year ago, and even grew to like it a bit. Then again, I've never ever missed it since.
The reason? It's mostly a write-only language. Going above a 100 line solution made me be wary of my own code, which is definately not a good outcome. With other languages that bar is considerably higher (maybe 1000 or 10000 lines).
I see no reason to go for Perl in new projects, for new users, in -soon- 2009.