Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Get HideMyAss! VPN, PC Mag's Top 10 VPNs of 2016 for 55% off for a Limited Time ×

Wicked Cool Perl Scripts 239

Michael J. Ross writes "Of all the popular programming languages now in use, Perl is perhaps the best suited for writing utilities — for several reasons, such as its text-processing capabilities, ease of addressing system resources, and minimal language overhead for input, output, list processing. It was designed to blend the rapid solution development of shell scripting with the powerful control constructs of third-generation languages. Consequently, Perl quickly became a favorite language for developing programs ranging from system administration utilities to CGI scripts that power Web sites. In fact, Perl has been called the glue that holds the Internet together. The tremendous flexibility and power of Perl is seen in Steve Oualline's book Wicked Cool Perl Scripts: Useful Perl Scripts That Solve Difficult Problems." Read the rest of Michael's review
Wicked Cool Perl Scripts
author Steve Oualline
pages 336
publisher No Starch Press
rating 8
reviewer Michael J. Ross
ISBN 1593270623
summary 47 useful Perl scripts for Web site management or CGI, Linux or Unix system administration, managing pictures, etc.

Published by the cleverly named No Starch Press, Wicked Cool Perl Scripts comprises 336 pages, spanning 11 chapters, with a brief introduction, as well as an index. The book appeared in February 2006, and was published under the ISBN of 1593270623. No Starch Press maintains a Web page for the book, where readers can find a sample chapter (the third one, covering CGI debugging), in PDF format. There is a link for downloading all of the source code.

The book presents 47 scripts, grouped into 11 categories: general-purpose utilities, Web site management, CGI debugging, CGI programs, Internet data mining, Unix system administration, picture utilities, games and learning tools, development tools, mapping, and regular expression graphing. The scripts perform such functions as finding duplicate files on your PC, converting currencies, processing error logs, generating jokes randomly, getting stock quotes, and managing photos and other images. Some of the scripts play games, while others would be invaluable to any Linux or Unix system administrator. For readers with their own Web sites, the book offers scripts for verifying links, locating orphan files, detecting hackers, and locking them out. In addition, there is a script for counting the number of visitors to your site, and even one for presenting a guest book. Software developers will find the material valuable, as there are Perl scripts for generating code, locating dead code, and handling regular expressions — parsing and graphing them.

The scripts themselves are fairly wide ranging in complexity and size, with a few fitting on a single page of the book, while others require more than ten pages. Fortunately, the scripts generally contain enough comments to be clear in how they work to any programmer comfortable with the language. Nonetheless, the author explains how to run each script, what sort of results the reader should see, how the script works, and what modifications one might want to make to it ("hacking the script"). In addition, every one of the scripts contains a POD (Plain Old Documentation) section, though only in the downloadable version — not the version seen in the book, to save space.

It is doubtful that any beginning Perl programmer might mistake this book for a Perl primer or reference. The title alone makes clear that the focus is on the offered scripts themselves, and their ability to help the reader solve common problems. On the other hand, Perl programmers of any level of fluency with the language would benefit from reading through the scripts, as well as the author's explanation of how they address and solve each problem. I myself have been programming in Perl for ages, and yet I spotted CPAN modules that I can use in my own Perl scripts in the future.

The value of the scripts themselves to each individual reader, naturally depends upon what sort of tasks the reader would like to accomplish with Perl. The 11 categories of scripts are varied enough so as likely to be of use to just about anyone who would like to use the "Swiss Army knife of languages" for getting the job done on their computer, or that of their employer (as a system administrator). Personally I found most useful the scripts for detecting changed files, scanning Web sites for dead links, and parsing regular expressions.

There are other aspects to like about this book. It has a RepKover binding, to lay flat when open. The illustrations are clear and not excessive in number. Unlike some technical authors, whose weak attempts at humor simply make their obtuse material more annoying, Oualline is more subtle, such as his reference to the cost of Microsoft Windows CDs in a Hong Kong shop, or "Ingesting a Cheerio nasally." Well, perhaps not always subtle, but invariably welcome in what could otherwise be an extremely dry subject.

Like any book, there are some areas for improvement, perhaps in future editions: In the illustrations that employ rays pointing from one node to the next, some of the curved rays are remarkably jagged, as if they were not computer-generated. Far more importantly, some of the scripts could benefit from more internal comments, as well as having the code broken up into smaller functions, which improves clarity and maintainability. Also, some of the variables and functions could use more descriptive names. For instance, using two examples from a randomly chosen page: $file_name would be more clear than $cur_file (is it the file's name, full path, or contents?). print_file_cell() would be better than do_file() (do what to the file?).

But aside from those weaknesses, Wicked Cool Perl Scripts is a fine book that would be of interest to any Perl programmer, regardless of their expertise. In fact, the administrator of a Web site or a Linux/Unix server, would not even have to know the language in order to download these Perl scripts, and use them to solve problems on the job.

Michael J. Ross is a freelance writer, computer consultant, and the editor of the free newsletter of PristinePlanet.com.

You can purchase Wicked Cool Perl Scripts from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Wicked Cool Perl Scripts

Comments Filter:
  • Solve it (Score:5, Funny)

    by suso ( 153703 ) * on Wednesday June 28, 2006 @03:35PM (#15623381) Homepage Journal

    Useful Perl Scripts That Solve Difficult Problems.

    Heh, Steve Oualline. In his book on Vim, he had this example of code where the program comment went something like this:

    Program -- Solve it -- Solves the worlds problems.
    All of them. At once.
    This will be a great program when I finish it.

  • Good Practice? (Score:2, Insightful)

    In fact, the administrator of a Web site or a Linux/Unix server, would not even have to know the language in order to download these Perl scripts, and use them to solve problems on the job.

    Is these really that good of a practice though? Your pc's will be jam-packed with go you never wrote ... therefore you don't know what's actually going on with your own machines? Write your own scripts script kiddies.
    • Re:Good Practice? (Score:5, Insightful)

      by Cleon ( 471197 ) <cleon42@@@yahoo...com> on Wednesday June 28, 2006 @03:39PM (#15623404) Homepage
      Admins that download scripts off the Net without even checking to see how they work are a danger to themselves and others.
    • yes and no (Score:5, Insightful)

      by JeanBaptiste ( 537955 ) on Wednesday June 28, 2006 @03:40PM (#15623410)
      While it is important that the Admin completely understands what is going on.... theres no need to re-invent the wheel if someone else already went through the trouble of writing and testing it.
      • by finkployd ( 12902 ) on Wednesday June 28, 2006 @04:19PM (#15623676) Homepage
        Personally, I don't think you truly understand how a wheel works until you reinvent one :)

      • Re:yes and no (Score:3, Insightful)

        I agree that an admin need not reinvent the wheel, if pre-built wheels are readily available. But he should inspect it to make sure it's actually a wheel, and not just a pie pan, before he bolts it into the axle. Or at least know what a wheel looks like.

        The grandparent excerpt reads "the administrator of a Web site or a Linux/Unix server, would not even have to know the language in order to download these Perl scripts, and use them to solve problems on the job" -- implying that the admin not only doesn't
    • by iamdrscience ( 541136 ) <michaelmtripp@gm ... m minus language> on Wednesday June 28, 2006 @03:55PM (#15623503) Homepage
      Right, what's with people today, running programs other people have written? How can you be in control of your system if you didn't even write your own Operating System!!
    • Re:Good Practice? (Score:5, Insightful)

      by drinkypoo ( 153816 ) <martin.espinoza@gmail.com> on Wednesday June 28, 2006 @04:11PM (#15623616) Homepage Journal
      In fact, the administrator of a Web site or a Linux/Unix server, would not even have to know the language in order to download these Perl scripts, and use them to solve problems on the job.
      Is these really that good of a practice though? Your pc's will be jam-packed with go you never wrote ... therefore you don't know what's actually going on with your own machines? Write your own scripts script kiddies.

      Let's try this from another angle.

      "In fact, the administrator of a Web site of Unix/Linux server would not even have to know the language in order to download Apache, compile it, and use it to serve pages."

      "Is this really that good of a practice though? Your PCs will be jam-packed with software you never wrote ... therefore you don't really know what's going on with your own machines. Write your own programs, kiddies."

      (I corrected your spelling, grammar, and punctuation errors as well.)

      Basically, your argument amounts to absolutely nothing, because it's no different from other programs. Do you REALLY think that admins typically vet every line of code on their systems? People don't live that long. Know what the difference is between a C program you don't understand, and a perl script you don't understand? The C program is compiled once, and the perl script is JIT-compiled ever time you run it.

      • Guess the difference is the supplier and the code vetting process. MANY people have inspected apaches code and many more have used it sucessfully. While some script you find on the web is about as trustworthy as some shareware program you found on the web, I wouldn't trust either on a production server.
      • Know what the difference is between a C program you don't understand, and a perl script you don't understand?
        If you spend long enough reading the C program, you may come to understand it.
    • Is these really that good of a practice though? Your pc's will be jam-packed with go you never wrote ... therefore you don't know what's actually going on with your own machines? Write your own scripts script kiddies.

      Yeah, no kidding! It's like all those lazy administrators that go installing arbitrary software from random third parties. I mean, do you have any idea what /usr/sbin/apache is actually doing? Write your own web server, I say! And don't get me started on all those so-called 'administrators'
  • Sweet (Score:2, Funny)

    by Rethcir ( 680121 )
    These scripts are wicked friggen' pissah!
  • by necro81 ( 917438 ) on Wednesday June 28, 2006 @03:40PM (#15623408) Journal
    The author must be from Massachusettes, possibly the Cape?
  • Perl glue (Score:3, Funny)

    by Anonymous Coward on Wednesday June 28, 2006 @03:41PM (#15623418)
    Perl has been called the glue that holds the Internet together.

    Hey, wait a minute! That's not glue... ewww... what is that? Larry, have you been touching yourself again?

  • Future wickedness (Score:5, Informative)

    by smittyoneeach ( 243267 ) * on Wednesday June 28, 2006 @03:46PM (#15623449) Homepage Journal
    Audrey Tang thinks that Perl6 may be here before Vista, possibly even by the holidays...
    http://pugs.blogs.com/pugs/2006/06/yapcna_talk.htm l [blogs.com]
    The slide show links show some terrifying code snippets.
    These Perl-merlins are wicked, indeed.
  • by mmell ( 832646 ) <mike.mell@gmail.com> on Wednesday June 28, 2006 @03:48PM (#15623457)
    In this corner - advocates of Perl, the Pathologically Ecclectic Rubbish Collector (or something like that)

    In that corner - advocates of Ruby (I haven't got a clue on this one, folks)

    And in this corner - dinosaurs like myself who still think awk/sed/sh is a pretty neat thing. Wait a minute, that's three corners. Uh . . .

  • Perl? Bah! (Score:5, Funny)

    by Anonymous Coward on Wednesday June 28, 2006 @03:49PM (#15623471)
    Anyone worth their salt would use an AJAX web 2.0 implementation of ruby on rails with a J2EE backend running struts marked up with DXHTML all bound together with an XML-SOAP web service to do their system administration via a proxied web cache. Changing configs would just involve editing a little CSS.
  • by stratjakt ( 596332 ) on Wednesday June 28, 2006 @03:50PM (#15623475) Journal
    Than googling for cool perl scripts?

    I'm asking seriously, because of all of the "cookbooks" and collection books of this sort that I've seen on the shelves at Borders, they're all full of things that a quick bit of googling could come up with. In fact, a little searching usually yields better solutions, and I'm convinced they're written by copy/pasting google results into the author's editor of choice.

    I'm all for good dead-tree reference material, but I've been frustrated trying to find books that don't contain stuff-i-already-know, or stuff-i-can-get-free on the 'net.

    I guess it can't be good for the dead tree tech manual industry, but so long as universities and colleges force students to buy the books (and a new revision of the same book every year), that's all fine and good.

    • by Tankko ( 911999 )
      I have a bunch of "cookbooks", and I don't read them because I'm looking for a specific solution, I read them because it's a great way to learn a lot of tricks and see a lot of code in a concentrated place that covers a bunch of areas.

      I sit on the couch and just read them and learn a lot.
    • That being said let me tell you what a bitch of a time I had googling a script. I needed something to stop brute-force http password hurler attacks in realtime, all it had to do is check the log for multiple 401 errors from an ip and then ban it. My server is getting pounded (one attack - 400,000 tries in 3 hours). Googling led to hotscripts and about a jillion other script sites all referencing scripts that would do the trick - however, the authors sites were all gone by the time I looked. The only ones wo
  • OB Ruby fanboyism (Score:2, Informative)

    by Teach ( 29386 ) *

    You know, I love Perl. I've been using it for CGI stuff, for system-administration stuff, etc, for six or seven years now.

    In fact, the only things I haven't written in Perl during that time have been things that were either too lightweight (five line shell scripts) or too in need of structure (a free/Free clone of Advance Wars in Java).

    That said, every new script I've written so far this summer has been written in Ruby. I hate to sound like a Ruby fanboy, but I think Ruby is really a better perl than

    • However, Ruby is also good at the things that Perl isn't good at. You've got real objects when you want them.

      Hey!! Perl has real objects... you just have to work at it...

      Of course, being a Perl programmer, I am very averse to work, hence all the time I spend reading Slashdot.

      • My understanding is that Perl doesn't have real objects, it just lets you pretend that it has objects, and everything basically works.

        So my question is, what would I want to do with objects that a language like Ruby would let me do (because Ruby has real objects), but I can't do (as easily) in Perl (because Perl doesn't have real objects)? Other than preventing myself from directly accessing an object's internal workings, which breaks the concept of OOP but isn't a problem if I simply choose not to do it.
        • Re:OB Ruby fanboyism (Score:4, Interesting)

          by esper ( 11644 ) on Wednesday June 28, 2006 @06:55PM (#15624683) Homepage
          "Inside-out objects" can give you hard data hiding. Basically, instead of storing the object properties as keys of a blessed hash, you have a file-scoped (my) array for each property. Nothing outside of that file can access the data and the object becomes a blessed integer reference (used as an index into the property arrays) instead of the blessed hash reference that's normally taught. (This can also be implemented with hashes for each property and the blessed reference itself used as the hash key, but I tend to prefer the array version, since the lookups are a good deal faster.)
        • My understanding is that Perl doesn't have real objects, it just lets you pretend that it has objects, and everything basically works.


    • I agree, Ruby looks like a nice language (basically an actually useful Smalltalk workalike... something I can really appreciate). However, when it comes right down to it, I use Perl for two reasons:

      1) CPAN
      2) ubiquity

      'course, you've already mentioned CPAN, but it's an important point to reiterate. The power of Perl, in large part, lies in the massive number of third party libraries available. As for ubiquity, it's rare these days for me to ssh into a machine that doesn't have Perl. The same can't be said
      • by nuzak ( 959558 ) on Wednesday June 28, 2006 @04:47PM (#15623867) Journal
        I have those two reasons, but those are soft factors, nice-to-have, but not necessary. Unfortunately, I have a third:

        3) unicode

        I have to deal with lots of unicode, index it, run regexes on it, and so on. Ruby lacks any real unicode support, which has made it a deal-breaker.

        • Ahhh yeah, I knew there was one major drawback to Ruby, but couldn't recall what it was. Though, it's interesting to note that it wasn't until Perl 5.8.0 (around four years ago) that it really supported Unicode (as in, full regex support). By comparison, Ruby is fairly immature, so it should be interesting how it progresses on this front. OTOH, it's rather surprising surprising to me that, given Ruby's age, Unicode wasn't designed in from the beginning...
    • I agree on all points. I also find the average Ruby script infinitely more readable than most of the Perl I've read (or written). Ruby's syntax is just so perfect and clean. I was pretty skeptical when I first started reading Ruby books, the way everyone always waxed so ridiculously lyrical about how writing Ruby after using other languages was like a walk in a park on a damp spring day with the sun just barely shining through the low wispy fog etc. etc. etc. But it's true. I hope it can maintain its moment
    • by glwtta ( 532858 ) on Wednesday June 28, 2006 @05:14PM (#15624056) Homepage
      You've got real objects when you want them. LISP-like things like iterators and closures. The works.

      I don't want this to degenerate into rabid fanboyism, but it seems the benefits of a "real" (or, real, if you preffer) object system over Perl's are routinely exaggerated. Yes, it could be better, but for 95% of the things you do, it works just fine.

      And of course Perl has iterators and closures (and first order functions, and all that other hard-to-maitain stuff the Functional crowd always goes on about). It's probably one of the things I like best about Perl, it just has features as part of the language, no one makes a huge deal of it.

      I've looked at Ruby (ok, glanced), and I just can't stomach the syntax - it's like writing Java in VB. Entirely subjective, of course. Though, as long as I live I will not understand this recent fad of trying your best not to delimit code blocks clearly - it smells of choosing ideology over utility.

      Definitely agree about the lack of "simple and rigid" struct-like things, I miss those often.

      And of course for anyone who wants a feature that Perl doesn't have, there's Perl 6 - that will have every feature that has existed in any language, ever.
    • I had to write a term paper back in college where I compared two languages assigned to me, mine happened to be Ruby and Python. I knew neither at the time. Since I already knew Perl, I threw in little tidbits about it as well. One of the things that impressed me the most (and this may have changed in the past 3-4 years) was if I wrote something where whether or not a variable had a binding was determined at run-time like

      $blah = ;
      chomp $blah;
      if ($blah eq 'a') {
    • by mangu ( 126918 )
      Ruby has the completely useless "end" statement they borrowed from FORTRAN77 and Ada. Stupid, stupid, stupid, how stupid can you get?

      Every text editor I know and use can match braces. Where does this block end? By clicking one or two keys I immediately know. I have no idea (and I really don't want to know) how do you match a generic "end" with the corresponding block opener in Ruby.

      Do you think this is unimportant? If so, you aren't a professional programmer, and it's OK for you to use that toy language, Ru

      • C and Perl are for professional programmers. Ruby and Python are for people who need to write short programs from time to time, better than VB, of course, but no substitute for professional quality tools.

        I have to call BS on this one. I highly doubt that the parent poster has seen the ubiquitous pile of legacy Perl code lying around, and how bad and bug-ridden it can be because the programmers didn't do enough to control a sloppy language. I think Perl Medic is the only Perl book I'll ever recommend for t
  • Why is it that every scripting book needs a title that sounds like it was written by a 14-year old?
  • ...every one of the scripts contains a POD (Plain Old Documentation) section, though only in the downloadable version -- not the version seen in the book, to save space.

    I thought these people got paid per page?

  • by kisrael ( 134664 ) on Wednesday June 28, 2006 @04:12PM (#15623622) Homepage
    I've been a street-taught Perl hacker since like 1993 or so.

    Only recently, despite having read a lot of the Perl books and hung around online a lot, I found about the history of Perl that I almost couldn't believe...that originally, it was just a glue language for a big honking chunk of Unix system calls, mostly written in C.

    My credulity is because Perl sometimes seems like the anti-C...especially in terms of handling strings, since my memory of C is using chararrays for everything.

    But it makes sense.... C offered blazing speed, and Perl was a great duct tape glue for all that. It's amazing that it had such quality memory management, string handling, associative arrays, and loosey goosey syntax for reg ex etc. But it's great.

    I think it falls apart once you get to the perl 5 object model, which I've never been able to really get my head around... but for anything that should be written programatically rather than structured from objects, it's really great.
    • by Phroggy ( 441 ) * <slashdot3@@@phroggy...com> on Wednesday June 28, 2006 @05:46PM (#15624292) Homepage
      I don't see how you could read any books about Perl and not have any idea where the language came from. This is why PHP is so much more popular than Perl among people who don't already have a familiarity with UNIX and C: a C programmer learning Perl can say "oh hey, perl has a localtime() function, I already know how to use that" while a newbie will say "wtf, why do months start with 0 and the year is 106, and how am I supposed to remember what order all these numbers are in?" A UNIX hacker can say "oh hey, $0 and $$ are exactly the same as they are in shell scripts, and the regex syntax looks just like sed" while a Windows user will say "wtf, what are all these meaningless variables, and what the hell is a regex?"

      My advice for OOP in Perl:
      1) learn how OOP is supposed to work in some other language
      2) pretend that it works that way in Perl, and try not to think about how "bless" actually works.
      • I don't see how you could read any books about Perl and not have any idea where the language came from.

        Well, I was well aware of the "weird UNIXisms" in Perl, but I kind of thought that functions like localtime() were still "weird" in Perl because Wall et al. wrote them to be slantwise compatible with what C programmers on the system new, not that they were all pretty much straight passthroughs.

        It still blows my mind, actually, that such a loosely typed language has straight pass througs to misc. Unix C fun
        • *shrugs* (Score:3, Insightful)

          by Ayanami Rei ( 621112 ) *
          For the most part the POSIX C API uses NUL terminated strings, pointers to structs, and ints (and opaque types that are actually ints). Oh, and small structs made up of that stuff.
          Perl's scalar numbers internally are the same size as the system's ints, so that handles that detail.
          Perl auto-coerces strings to numbers and vice-versa. So it can handle the number and string arguments using built-in API functions that just take whatever perl expression and coerce it down to the appropriate scalar context in the
      • Another note: you bring up the hypothetical C programmer who used localtime() and Unix hacker who used sed... honestly I think both of those people are from an earlier era, in that I think people get exposed to Perl now before they get exposed to Unix system calls and sed.
  • by tinker_taylor ( 618697 ) on Wednesday June 28, 2006 @04:24PM (#15623704) Homepage
    A humble Perl user's thoughts on this brouhaha --


    1) The power of perl is irrefutable -- it helps slap together quick and clean solutions to irritating admin problems. The flip-side of being a perl jockey I guess is that one tends to try and create a solution to many a problem that already has a solution - because searching CPAN can be a pain at times.

    2) Use of the more flexible features of the languages (such as Hashes, hash of hashes etc) data/number munging and organization becomes more manageable.

    3) Using Perl's almost endless modules, a lot of relatively complicated tasks can be simplified.

    4) Annoyance factor of numerous tasks (especially Administrative and reporting) can be reduced drastically with the help of Perl.


    1) The beef I guess is that unlike Python or Perl's other competitors, Perl modules don't come tightly integrated with the core distro. Agreed that Perl probably has a lot more modules than any of those other languages do, but a larger than ordinary de facto distribution (why not include important modules like Digest::MD5, Crypt modules, SSH modules etc?) would be desirable (especially in those situations where you don't have access to the internet directly from within corporate networks and can't install the modules with the "perl -MCPAN -e shell" option) . There might be those Perl veterans who would say -- "build your own distro with your custom modules already packaged" -- and while that might be a very smart thing to do, many a time (when one keeps moving from one environment to another -- some call it job hopping, it helps to be able to download one single perl distro package or rpm or the source+compile and have basic administrative scripts work -- especially those that rely on centralized automation (ssh-based trusts, copies across the network, etc).

    2) Also, perl's syntax can be terse and difficult for noobies to understand (or even older perl-hands for that matter -- when someone has written code without appropriate comments, etc).

    3) Tinkering with Python recently, I found it's simplicity refreshing and it's syntax easier to comprehend (especially when compared with Perl's (imho) complicated "scoping" requirements, etc).

    4) Sometimes (and I guess it depends on the person writing the code) Perl tends to over-complicate things that can be easily handled via Shell scripts.
    • perldoc perlmodlib tells you which modules come with perl.

      In the 5.8 version of, one modules such module is Digest::MD5. The core crypt() function also passes things directly through to the OS's crypt library. However, for portability reasons, you should use Crypt::PasswdMD5 for MD5-base crypted passwords, as some libraries (such as Windows') don't support MD5 hashes.

      Having said that, I have my own list of things I dislike about perl [livejournal.com].

  • NOT Worth While (Score:2, Informative)

    by Anonymous Coward
    If you've hacked Perl for over a year this book is major disapointment. The examples are all largely available elsewhere and relatively uninspired things such as simple CGI web counters. Buy some O'Reilly stuff instead.
  • by Sarusa ( 104047 ) on Wednesday June 28, 2006 @04:40PM (#15623816)
    'Of all the popular programming languages now in use, Perl is perhaps the best suited for writing utilities'. I would probably agree with this - you can very easily hack out a very simple utility to do something with less effort and code than in Ruby or Python. Of course if you ever need to read it again, or god forbid extend it, then the extra effort you put in up front may pay off.

    Yes, I know you can write very readable maintainable perl. In theory. The only example of this I have ever seen is the Calcium web calendar. But whenever our perl guy writes something it looks more like
        ($l=join("",))=~s/.*\n/index($`,$&)>=$[||print$&/g e;
    (stolen from http://www.antipope.org/charlie/attic/perl/one-lin er.html [antipope.org]) and if he has to touch it again a month later it's a dangerous thing.

    • by Wee ( 17189 )
      But whenever our perl guy writes something it looks more like ($l=join("",))=~s/.*\n/index($`,$&)>=$[||print$&/ g e; and if he has to touch it again a month later it's a dangerous thing.

      Fire your perl guy -- he's clearly a menace. And after you fire him, tell him to stop reading perlmonks.org. After a while, he'll start doing things like using foreach() instead of map() when it makes the script clearer. And as an added bonus, he won't waste time trying to find the bug he caused from ov

  • by tedhiltonhead ( 654502 ) on Wednesday June 28, 2006 @04:42PM (#15623832)
    Perl is like my ex-girlfriend... I used to be all over her^H^H^Hit but am now fawning over the knockout redhead Ruby. Unfortunately, I had several children with my ex that still need to be cared for -- feature improvements, bugfixes, restarts. Hopefully one day they'll grow up and leave the house so Ruby can have me all to herself.

    • Re:My Ex-Language (Score:5, Interesting)

      by esconsult1 ( 203878 ) on Wednesday June 28, 2006 @05:24PM (#15624132) Homepage Journal
      So right.

      Look over the perl 6 syntax and the increased punctuation, then compare to Ruby. I've been working with perl now for about 10 years or more, and Ruby has replaced or supplanted all my Perl work over the last several months. No going back. Not even bothering to learn Perl 6. CPAN is sweet, but so much is already built into ruby's standard libs.

      Ruby syntax is clean. Real OOP. Self documenting. No way I'm going back, especially not for Perl 6, which is too much, and too late.

  • Evil Perl (Score:4, Interesting)

    by Michael Woodhams ( 112247 ) on Wednesday June 28, 2006 @04:46PM (#15623859) Journal
    Version 1:

    Version 2:
    while($_=$a=pop){/([a-z])/i?map{($t=$a)=~s/$1/$_/g ;$a!~/$_/&&push@ARGV,"$t

    They do the same thing. I'll post what that is in a follow-up, for the sake of any masochists who want to figure it out for themselves.
    • Re:Evil Perl (Score:5, Informative)

      by Michael Woodhams ( 112247 ) on Wednesday June 28, 2006 @04:53PM (#15623908) Journal
      They are brute-force alphametics solvers. Save either into a file (say "s") then:
      $ perl s send+more==money

      If anyone can shorten either of these programs (even by one byte) please let me know. If you do, and you're geographically close enough, I'll buy you lunch. (Watch for bugs with numbers with leading zeros.)

      Version 1 is 133 bytes, version 2 is 103 bytes. Version 1 is almost entirely my own work, and contains a nifty recursive permutation generator. Version 2 was produced by someone else in response to my challenge, and then further compressed a bit by me.

      Unfortunately, the Obfuscated Perl Contest has disappeared (although these are principally compressed rather than obfuscated.)
    • I just noticed that some /. comment preprocessing mangled a bit of version 1. Here is the correct last line with extra whitespace around &&:
      ",eval"y,$a,@_,",/\b0/)||eval && print;pop}a
  • Perl is VB (Score:2, Interesting)

    by Anonymous Coward
    I'll preface by saying that there's nothing inherently wrong with VB or with Perl. The problem occurs because both *can* foster poor programming practices. Both have an immense library of functions that allow novice scripters to hack together scripts that can perform a function. There may not be any overall design, but for lots of folks, this is more than enough. The problem occurs when you try to maintain that code (either Perl of VB) and you realize that people have pulled together modules (or ActiveX co
  • If Perl is the glue that holds the Internet together, what does a Perl necklace hold together?
  • C is the glue... (Score:3, Insightful)

    by Fleeced ( 585092 ) <[fleeced] [at] [mail.com]> on Wednesday June 28, 2006 @06:23PM (#15624505)
    In fact, Perl has been called the glue that holds the Internet together.

    That's not true. C was considered the glue of the Internet... Perl is the gaffa tape.
  • by Borf ( 18392 ) on Wednesday June 28, 2006 @06:31PM (#15624555)
    I'm giving in this time.

    I work in a shop where we maintain (after last count) 112,002 lines of perl in a single system (which also contains about half a million lines of C).

    Guess what? It's not a problem! Not in the slightest!
    And you know why?

    - Modules
    - Coding conventions
    - Mature programmers

    Two of those three are redundant. Take a guess which ones (the third item isn't part of the anwer set).

    If you take a programmer that writes disciplined, careful, extensible, extendable and professional C - are they going to start generating hacked up crap when they switch to Perl? No. They're not. They split source among modules. They use naming conventions. They use strict. They use the namespaces. They use clear syntax. The end result looks almost like C most of the time. Except when it doesn't, 'cause it's Perl.

    What does C written by hack-job Perl "programmers" look like?

    Rephrasing #37 - "It ain't the arrow, it's the (Native American)".

If God is perfect, why did He create discontinuous functions?