Early-2000s Perl Beckons with Plentiful Documentation

June 27, 2011 8:56 PM

I'd like to get my feet wet with Perl. Baby steps, just a little beyond "Hello World." I'd like to create a simple little app. I have a few questions...

There's a lot of great Perl info out there that shows early-2000s CGI methodology. It seems easier than using a framework. I tried Mojolicious but I just don't have the ability to see where the framework ends and Perl begins -- that is, I don't have enough experience to pick up where the documentation leaves off.

So, question 1: Is it a big deal to just use the early-2000s stuff instead of a framework like Mojolicious? I was worried about e.g. clean URLs but it seems like some redirect work in .htaccess could fix that.

Question 2: Assuming it's not a huge mistake to forego frameworks for now, I'd like to make a simple CRUD app with an admin side. My first idea was to create a call log. Where to start with the admin-side part? For example, the Perl tutorial at Tizag.com will show me how to read from a database. How about writing to it, and password-protecting the admin area? Any good tutorials out there?

Thanks!

posted by circular to Computers & Internet (11 answers total)

The learning curve is much easier with the CGI stuff, but when it comes to making an app, even a simple one, what effort takes to learn a web framework pays back almost immediately. However, I'd suggest starting with a simple CGI app, to get some of the fundamentals down and know what the framework is doing behind the scenes.

I can't speak about Mojolicious's features (I'm a Python/Django guy, not a Perl guy), but a good framework will abstract away a lot of the DB stuff for you and may even give you a readymade admin side.
posted by zsazsa at 9:24 PM on June 27, 2011

Just another perl hacker here who switched to Python. Note that a few potential security issues are peculiar to perl and impact even extremely simple apps. The 2000s stuff generally won't inform you about that, though it does matter right off the bat. Maybe Mojolicious, Catalyst, Mason, or Dancer do something to help with that kind of thing in the same way that Django tries to help new users avoid other, more universal security flaws. I wouldn't advocate any particular alternative solution, but you might look at these installers / virtual machines built for common technology stacks as another starting point.
posted by Monsieur Caution at 10:13 PM on June 27, 2011 [1 favorite]

I'll second zsazsa's idea that you start simple with old school cgi just to see how it is done (and you'll hopefully learn also why it is such a PITA). This will make learning a framework that much more enjoyable. You'll also appreciate why the frameworks are built.
posted by mmascolino at 10:18 PM on June 27, 2011

If there isn't a compelling reason to use perl, I'd really go with something else. Anything else. Even PHP. *shudder*
posted by sanko at 10:38 PM on June 27, 2011 [1 favorite]

Please knock off the "perl is dead" / "perl is antiquated" bullshit. Perl is perfectly alive and vibrant at the moment, having made a resurgence in the last 5 or so years. There are a wealth of new features such as the Moose object system that take away all the old pain. Please read up on Modern Perl before spewing nonsense. I'm so tired of reading this in questions asked here about perl.
posted by Rhomboid at 10:59 PM on June 27, 2011 [5 favorites]

Those 'peculiar to perl' issues are why you shouldn't learn era 2000 and before style Perl. Simple things like turning on 'taint' checking will keep you from using any data that came from outside the program in the dangerous system/exec places, you can't even read a regexp from the command line and use it as a regexp without explicitly doing something to un-taint it. The 3 arg open takes care of the '|' problems. Everything else there is just generic security stuff.

There's no harm in using just plain CGI (or lighter weight CGI::Simple) but you'll find it tedious for anything but simple stuff. By the time you split up the request path, use cookies for user sessions, and DBI stuff for database access and juggle HTML generating subroutines and your content... you'll wish you had used a framework that just let you point paths to code to run, handled the session info for you, gave you a nice Class::DBI object to let you read/write to your database, and a templating system that you can hand your calculated results to and be done with it.

Also, since 2000 era CGI, Perl has stolen a bunch of stuff from Python/Ruby. PSGI and Plack for instance. You're more likely to see something like:

my $app = builder {
  mount '/' => sub { [ 200, [ 'Content-Type' => 'text/plain' ], [ 'Hello World!' ] ] }
};
Plack::Runner->new->run($app);

than the old CGI:

print "Content-Type: text/plain\n\n";
print "Hello World!";

You should probably use Class::DBI for your database access, it pretty much abstracts away all the nasties and lets you just use an object to read/write.

# requisite DB setup stuff...
my $result = CallLog->find_or_create({caller => 'bob'});
$result->message('hey! bob called');
$result->time($now);
$result->commit();

I don't do much web stuff, but Dancer is pretty nice. The Dancer Advent Calendar is a good read. Check out PerlMonks for all your Perl questions, also don't forget to check out the module page on CPAN, most have a Tutorial or Cookbook with examples. You definately want to check out Modern Perl like Rhomboid mentioned, Perl really has done fantastic things in the past few years and is back on a 6 month-ish development cycle. Thing are rapidly changing while keeping backwards compatibility unlike Python/Ruby where the newer versions break things and nobody wants to migrate to the newer versions because all of the old modules/libraries haven't been ported (and may never be).

Ruby often changes something every release or so, and if you watch talks given by its creator, he's happy people use it, but sad that people rely on it so much. He has no intention of keeping compatibility, he writes it to suit his usage. Python people are raging because Python 3 turned out to be so unimpressive that many don't want to leave the 2.x branch.

Besides, only a Pythonist would screw up a cron job by doing:

if [ some test ]; then
  if [ some other test ]; then
    do something

We don't need no 'fi's, indentation does it for us! :P

tl;dr learn Modern Perl programming, use any module you like (but frameworks are real time/work savers).
posted by zengargoyle at 11:21 PM on June 27, 2011 [3 favorites]

Zengargoyle might be overstating the fluidity of Ruby or confusing it with Ruby on Rails (a web framework using Ruby). I've got sizeable web apps that have been running for over five years with no changes needed due to Ruby updates. On the other hand I've had to update quite a few times to keep up with Rails changes.

The only significant changes to Ruby have come from stepping up from 1.8.x to 1.9.x.

Old-style CGI is only simpler for tiny projects and even then you'll open yourself up to big risks from making beginners mistakes, especially security problems.

Always use a framework, even if it's a minimalist one. Don't write your own*

* Disclaimer: Everyone seems to end up writing their own web framework at some point, even if they agree with this rule beforehand. Afterwards most of them agree with it even more.
posted by BinaryApe at 12:59 AM on June 28, 2011

Catalyst is the framework of choice amongst the Perl web coders at work. It seems to give them the flexibility they need.

I can't speak for it personally though, all my Perl coding is none web related.
posted by antiwiggle at 6:12 AM on June 28, 2011

> Note that a few potential security issues are peculiar to perl

That linked article is over a decade old, and covers generic security issues common to any language mindlessly applied. It's also the first half of the article, and the second part deals with many of the issues raised: Security Issues in Perl Scripts: Perl Taint Mode.
posted by scruss at 6:22 AM on June 28, 2011

Response by poster: Thank you for all of the wonderful answers to my first question. I should probably mention that my interest in Perl was piqued by this podcast episode, but I've always been interested in trying new languages.

And I guess I understand why it's important to start with a framework. It just adds an extra layer of administravia that isn't terribly exciting to set up. I almost gave up on Python frameworks because of this. You can forget using your package manager's easy-install version if you want to get help from the community...

Dancer looks like it has a nice little tutorial on building a simple blog. I guess I'll start there, but any further assistance with question #2 would be appreciated!
posted by circular at 7:47 AM on June 28, 2011

As far as the second question, there's a very nice Catalyst book called "The Definitive Guide to Catalyst" that will walk you through the layout and design of a simple CRUD app using Perl and Catalyst.

Additionally, If you use IRC, the people in #catalyst and #perl-help on irc.perl.org are very helpful and newbie friendly.

As far as "Perl is dead" -- I'm just back from YAPC::NA 2011, the annual North American Perl conference. There were easily a dozen companies looking to hire Perl people, many of them willing to accept telecommuters. If you need a job, it's a pretty good time to be learning Perl.
posted by genehack at 12:27 PM on July 2, 2011