Slashdot Mirror
Perl 6 Now by Scott Walters
Joseph Brenner writes "Every now and then, a beginning programmer asks if there's
any point in learning to program in Perl 5, when Perl 6 is
going to change everything soon. There are a number of
answers to that: one is to point out that Perl 6 is still
years away, another is to point out that it is promised that
Perl 5 code will run under Perl 6 without modification (a
module that begins with the traditional "package" statement
is Perl 5 code; if it begins with the new "class," then it's
Perl 6)." Read on for the rest of Brenner's review of Scott Walters' Programming in Perl 6 style using Perl 5, a book which answers that question a whole different way.
Perl 6 Now
author
Scott Walters
pages
379
publisher
Apress
rating
7
reviewer
Joseph Brenner
ISBN
1590593952
summary
Programming in Perl 6 style using Perl 5
Scott Walters here pursues what might be thought of as the third answer: you can learn Perl 6 now and immediately begin writing programs in a "Perl6ish" sort of way, using appropriate CPAN modules that have been used to implement approximations of Perl 6 behavior: Perl6::Variables, Perl6::Export, Perl6::Contexts, autobox, Perl6::Classes, Switch, and so on.
There are many caveats about using these tricks in production code, however, and Scott Walters doesn't shy away from warning you about them (e.g. p.43 "Source filters are dangerous" where he discusses their increased start-up overhead and potential bugginess -- though he doesn't mention my own peeve which is that they're very confusing when you try and use the Perl debugger).
So possibly the book is not really quite so well suited to an actual beginner-- who probably should not be told about "use Switch 'Perl6'", but the device of spending the early stages of the book directed toward a beginning audience makes it a very useful review for people like myself who have been reading the Apocalypses, but don't remember every detail.
And on the other hand, the book includes some prominent early warnings about common gotchas that beginning programmers seem to be prone to -- e.g. using dynamically defined variables instead of just using hashes.
The standards for writing English in the Perl world are pretty high -- the core members of the Perl community have always cared a lot about clear writing, and it's arguably the world's best documented language (critics will no doubt add that it needs to be). Unfortunately, I can't say that Perl 6 Now quite lives up to this standard. This is a book that was written in a hurry, and it shows: hasty sentences and minor organizational problems abound (e.g. one or two items seem to be discussed in the wrong place; there are an awful lot of explicit forward references, and yet there's at least one place where something was used in an example before being discussed a few dozen pages later). But then in Scott Walters defense, this is certainly a book that needed to be written in a hurry, because its subject matter is such a moving target.
And where the book really shines is in its code examples: short, clear and to the point; the author repeatedly shows how something can be done in Perl 5 code and how it's expected to work in Perl 6. These examples are always clearly labeled "Perl 5" or "Perl 6" in the comments, so that the two can't be confused.
The subjects of some of the examples are pretty cool: e.g. he talks about using PDL ("Perl Data Language") to crunch audio data in MOD format, which I was completely unfamiliar with. A *.mod file essentially contains the "sheet music" for multiple parts (really, MIDI) plus sound samples that specify how notes will sound for each voice. This is discussed in Chapter 7, which is also the free sample chapter. I also liked random walking Arizona's highways as an example of Graph navigation (Chapter 8, p 159), and I appreciate the fact that he downplays inheritance in favor of delegation in his discussion of objects (Chapter 14, p. 262).
All in all, this book is a fun read for the Perl fanatic.
(Note: the title Perl 6 Now bears a strong resemblance to an emacs package I've been working on called perlnow.el, but there is no relation.)
You can purchase Programming in Perl 6 style using Perl 5 from bn.com; it's also available in eBook format (password protected PDF, using your email as password) for $15. Source code and and a sample chapter are available online: Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Scott Walters here pursues what might be thought of as the third answer: you can learn Perl 6 now and immediately begin writing programs in a "Perl6ish" sort of way, using appropriate CPAN modules that have been used to implement approximations of Perl 6 behavior: Perl6::Variables, Perl6::Export, Perl6::Contexts, autobox, Perl6::Classes, Switch, and so on.
There are many caveats about using these tricks in production code, however, and Scott Walters doesn't shy away from warning you about them (e.g. p.43 "Source filters are dangerous" where he discusses their increased start-up overhead and potential bugginess -- though he doesn't mention my own peeve which is that they're very confusing when you try and use the Perl debugger).
So possibly the book is not really quite so well suited to an actual beginner-- who probably should not be told about "use Switch 'Perl6'", but the device of spending the early stages of the book directed toward a beginning audience makes it a very useful review for people like myself who have been reading the Apocalypses, but don't remember every detail.
And on the other hand, the book includes some prominent early warnings about common gotchas that beginning programmers seem to be prone to -- e.g. using dynamically defined variables instead of just using hashes.
The standards for writing English in the Perl world are pretty high -- the core members of the Perl community have always cared a lot about clear writing, and it's arguably the world's best documented language (critics will no doubt add that it needs to be). Unfortunately, I can't say that Perl 6 Now quite lives up to this standard. This is a book that was written in a hurry, and it shows: hasty sentences and minor organizational problems abound (e.g. one or two items seem to be discussed in the wrong place; there are an awful lot of explicit forward references, and yet there's at least one place where something was used in an example before being discussed a few dozen pages later). But then in Scott Walters defense, this is certainly a book that needed to be written in a hurry, because its subject matter is such a moving target.
And where the book really shines is in its code examples: short, clear and to the point; the author repeatedly shows how something can be done in Perl 5 code and how it's expected to work in Perl 6. These examples are always clearly labeled "Perl 5" or "Perl 6" in the comments, so that the two can't be confused.
The subjects of some of the examples are pretty cool: e.g. he talks about using PDL ("Perl Data Language") to crunch audio data in MOD format, which I was completely unfamiliar with. A *.mod file essentially contains the "sheet music" for multiple parts (really, MIDI) plus sound samples that specify how notes will sound for each voice. This is discussed in Chapter 7, which is also the free sample chapter. I also liked random walking Arizona's highways as an example of Graph navigation (Chapter 8, p 159), and I appreciate the fact that he downplays inheritance in favor of delegation in his discussion of objects (Chapter 14, p. 262).
All in all, this book is a fun read for the Perl fanatic.
(Note: the title Perl 6 Now bears a strong resemblance to an emacs package I've been working on called perlnow.el, but there is no relation.)
You can purchase Programming in Perl 6 style using Perl 5 from bn.com; it's also available in eBook format (password protected PDF, using your email as password) for $15. Source code and and a sample chapter are available online: Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
It's interesting that books on Perl 6 are released when the Perl 6 is still in development. I understand modules for Perl 5 exist that can utlize some Perl 6 features, but still... Someone should release a book on Windows Vista now that a beta is out.
I hate to be Jonny Raincloud, but pretty soon PHP will be able to do whatever perl does, if it's not there already. And anything that it can't do that perl can will be obsolete. So no, don't waste your time learning perl 6. Do the right thing and brush up on your PHP5. I got my site to print in any font I want the time AND date, powered by php, baby!
The standards for writing English in the Perl world are pretty high -- the core members of the Perl community have always cared a lot about clear writing
Yeah, right. Why should one obfuscate English, Perl offers much more possibilities to do so.
What is the output of the following?
"Be Sure To Drink Your Ovaltine." What the...?
Would you care to provide any reasons for switching to Python?
Holy wars such as Perl vs Python are typical but altogether unneccecary. Both Perl and Python are maturing and are now sophisticated languages. Furthermore, they are suited for different things. For example, if I were writing a program that needed advanced string parsing, I would use Perl. If I was writing a graphical game, I would use Python. If I was writing a CGI script, I would use Perl. If I was writing a program that described various objects in space, I would use Python.
There is no reason to get so defensive about these things with the exceptions of Windows vs Linux (Linux) and Emacs vs Vi (Emacs).
I believe that CPAN is one of the major (if not the only) things keeping Perl alive and well.
It is a great language, and has been used successfully by many huge companies (Amazon for one), but I think if those companies had to redo it again today, I don't think they would choose Perl again. I think that purely as a language, it has been surpassed.
Having a large, mature 3rd party library is what is hampering the adoption of some of the up and coming languages.
Where are the Ruby on Rails people? I expected 100 of them to speak up before the traditional "FRIST PSOT!!!"
Well, for one, perl now has a nice framework similar to Rails called Catalyst (http://catalyst.perl.org/). It's a lot closer to Rails than a lot of other languages' attempts to clone Rails. And yet the Catalyst dev team have specifically chosen to diverge from Rails in certain areas, trading a bit of simplicity for complete flexibility, avoiding some limitations you could run into in Rails.
bp
You're joking, it's not PHP that Perl has to compete with, it's Python! PHP will always be slower than mod_perl 2 on Apache2 (bbc.co.uk runs on this and it is a monster), but Perl's primary use is not for server scripting (mod_perl) but as a power tool. Whenever you need to do something with your system beyond the power of shell scripting, use Perl;
I was going to bring this up in the thread about beginning programming the other day, but I came too late to the party. Hopefully someone can offer me some advice.
First, I'm not really a programmer. Not professionally, at least. I've been writing Perl for about four or five years, though. I'm not well-versed in OO and I'd like to be. I've just found it such a stumbling block in Perl and that's probably because I'm doing in Perl in the first place. It's the first language I picked up since I played around with BASIC and Pascal as a little kid.
I run a large auction site. Maybe 40,000 members. I wrote the entire engine (auction, forums - everything) in Perl. But it's getting complex and difficult to maintain as it is. And the performance is not holding up. I could move to mod_perl, but rather than re-writing everything (and possibly doing so in OO), I thought I'd just write it in another language.
I don't want PHP. So that leaves me mostly with Python and Ruby. I've done a lot of reading, but am not sure which would be more appropriate. I think Python might stick me back in the old "easy to do things wrong and blow your foot off" world of Perl. Ruby on the other hand would probably help me gain a better understanding and real-world use of OO.
Performance is an issue. So are available packages. My backend is postgresql and I need whatever language I use to have an extremely capable and flexible and mature postgresql DBI.
At the moment, I have to say I'm leaning toward Ruby. But it does seem that Python might have more mature packages available to it and be a bit more widely used. I'm just skittish because everything I've heard has given me the impression that it's very Perl-ish and if I'm going to be in that world, I might as well just stick with Perl in the first place.
Thoughts?
Everyone attacks Perl code for being unreadable but I don't think I've ever come across real world Perl code that I couldn't manage to deal with (eventually). I've seen some bad code and written some bad code and Perl doesn't have exclusivity in either of those areas. ;)
Does someone have a good example of unreadable, real world Perl code? And I don't mean obfuscated Perl contest entries.
When it comes down to it, other people's code is just freakin' unreadable no matter what they write it in. In fact, my own code looks unreadable and unmanagable if I haven't seen it in awhile. Just the nature of the industry.
Maybe Perl is just a high profile target since the internet is full of small (and useful) pieces of Perl code?
Yow!
there's more than one way to do me.
Please do not moderate parent up, because it's just a guess at most.
Perl6 is actually built from user feedback, for the first time.
From wikipedia: Larry Wall, the creator of Perl, has called Perl 6 "the community's rewrite of Perl", because he has based the changes largely on 361 "requests for comments" submitted by the Perl community in 2000. He is outlining these changes in a series of long essays, called Apocalypses, which are numbered to correspond to chapters in Programming Perl ("The Camel Book"). The current, unfinalized, specification of Perl 6 is encapsulated in design documents called Synopses, which are numbered to correspond to Apocalyses.
Parent is NOT insightful.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
Perl6 has the advantage of starting from the beginning, taking all that was learned from the evolutionary development that lead to Perl5, as well as the lessons learned from other languages like Python and Ruby. Honestly, read through the design commentary for Perl6 by Larry Wall. There are a lot of good ideas there, and Perl6 promises to be a much cleaner, more consistent and more elegnt language than Perl5 - that is, it has learned what was good in Perl5 and thrown away the (vast amounts) of cruft. Looking at what they're proposing, if it actually works as promised then I do think it will compete well with Python - and I'm a Python person myself*. Honestly, read a little of what Perl6 has to offer before you dismiss it out of hand. It looks like it will be a very nice language indeed.
Jedidiah.
* One of the things I like about Python is that they're willing to deprecate and then *remove* features to help combat cruft.
Craft Beer Programming T-shirts
Actually, mod_perl performance beats the pants off everything but raw C modules when doing Apache web applications.
The same goes for Java.
Bash and Awk are not powerful enough to do some of the jobs Perl can do. And Perl is only slow with some things, and in comparison to really serious languages like C/C++.
check out "http://pugscode.org/"
_ p6.html
for a working perl6 compiler. Yeah, it is not yet feature complete, but progress is very rapid.
Perl6 is really amazing. It removes most of the worst parts of perl5 and make things even easier on the programmer. If you do an research at all you can find that.
Some people are even starting to port important CPAN modules to perl6 and discovering how much a pleasure it is to use.
see http://www.perl.com/pub/a/2005/07/28/test_builder
as an example of that.
btw, check out the example code. for all of you who think perl5 looks like static on a tv screen, you will be pleasantly surprised I think.
peace
Peace, or Not?
I love and use Perl. But the grammar is already rich and varied. Throwing incorrect Perl6 code into the mix is going to make Perl5 code even harder to read. I sure hope not too much of this stuff makes it onto CPAN (although I know some of it already has).
Ruby on Rails blows away Perl. I used to code in Perl, but I was working on re-implementing Windows XP as a Firefox extension, and I just wasn't getting the productivity that I wanted out of Perl.
So I switched to Ruby on Rails this morning, and I'm so productive, that its sick. Within 5 hours, I have a Firefox extension running on my AIX workstation that can run most Win32 software... Photoshop, Outlook and Half Life 2 work ok, although I only get 40fps with HL2. (I'm working on that)
After dinner I'm going to reproduce every module in the CPAN library, which I estimate will take approximately 2.25 hours. I can't wait!
Conformity is the jailer of freedom and enemy of growth. -JFK
PERL5 is (relatively) compact. It does what it needs to do. I can quickly write fast and compact programs to do dirty tasks like extracting data from a log file. Moreover, I can easily decipher another person's PERL program.
Attempts to bloat PERL to include every conceivable widget is little more than an ill-advised attempt to morph PERL into a full-blown development language (e.g. C#) for creating million-line programs. Does anyone remember PL/1? It was supposed to be the be-all/end-all language and incorporated so many bells and whistles that few programmers actually learned how the entire language worked.
Remember the wisdom of the ancients: bearded, graying, almost senile UNIX programmers wearing code-bottle-thick eyeglasses. KISS means "Keep It Simple Stupid".
I stopped using Perl over ten years ago, when I had a disagreement with Tom Christiansen and he seriously threatened to blacklist me from the Perl community if I didn't agree with him. I told him to go ahead, because I would simply never write Perl again. He laughed and told me to let him know how that went.
Well, it went just fine. I haven't written a single line of Perl since that day, and I haven't missed it one bit.
These days, with so many options available, I think Perl appeals to a certain kind of developer in much the same way Java does. You don't really NEED it, in the sense that many other things can do the same job... but it's a point of style. Java and Perl now serve primarily as focal points for very small and specific communities that otherwise wouldn't really exist in a coherent fashion, much like APL or Objective-C. Ruby is similar, and I don't really see it going mainstream. These sorts of niche technologies still do the job, and selecting one of them instead of a more "mainstream" language like PHP or C++ identifies you as a particular kind of person.
Microsoft cheerleader, blue flag waving, you got a problem with that?
Every time you post a message to this website, you're using Perl. You'd better stop before you foolish irresponsible behavior catches up with you.
It's a false perception. 5.6 was leaps and bounds above 5.0.5, and 5.8 is a quite a stride past 5.6. :-P There was even a proposal that
Not everyone buys into 1, 2, 3, 95, 98, 2000 type
numbering schemes
perl 6 should be the last major number and the versioning should approach 2pi
Were that I say, pancakes?
So, what happens if I use perl6 to run a script that has neither "package" nor "class" statements in it. How is it going to decide which language is that?
I've been asking myself a lot lately why so many people seem to hate Perl. After spending the last few years going from comfortably familiar to extremely familiar with the syntax and features, I think I have the answer.
When you really get down into the guts of perl, you get to do all kinds of crazy nifty things with XS, AUTOLOAD, regular expressions, etc. Perl's syntax is such that once you're intimately familiar with it, you can be either very expressive or very concise.
A lot of code ends up going the concise route because when you know what you're doing, it's easier to write (less keystrokes). Then perl newbies / passer-byers take a look at it, don't understand it, and freak out and say that perl is crap.
Then perhaps they're threatened because there's a huge community of smart perl programmers that manage to upstage them constantly.
To zoom out on the issue a bit, I'm really sick and tired of this current movement in computer science where so many think that programming should be made into some kind of simple task that anyone can do. Hence you end up with languages like Java that hold your hand really really tight and refuse to let go. Is Grandma writing software really a good thing? Or should we save it for the people who at least have a passing familiarity with computers & networks; hell, someone who might even know a little bit about the basic mechanisms in a typical UNIX kernel?
(I refuse to drive a car built out of legos... I don't care that the technology enabled your three year old to do it... it's a high speed highway, damnit, and my life is on the line!)
Make no mistake - there's still an undergound of brilliant developers that understand their systems inside out and produce amazing, high performance code. Many of them are in the open source community. And we refuse to let go of our power tools. You may use whatever language you like, but expect a well-deserved ass kicking if you get in our face and try to tell us you know better.
So, if you want a language for scripting 9in the sense that most people with little scripting experience think of it), you might want to avoid perl. If you want a language to elegantly encode brilliant ideas in a short space, go for it.
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
never using a programming language again due to an argument you had on the internet identifies you as a particular kind of person.
I still find this funny.
And still use Perl.
First of all some TLC for you Perl Fanboys (and girls) out there: Everybody loves Perl. Perl is cool, fast, delivers fast results in the area it rules and is the grand daddy of OSS languages. Nearly all books on Perl are fun to read and at least a great laugh.
...) and is the best candidate for a Perl successor. It only lacks Perls unmatched regex features. Entry the famous saying:
In fact it's quite amazing how long this quirky relic of ancient Unix paradigms managed to survive. It's 2005 and Perl _still_ is taken for granted as a PL. That's a terrific feat!
The only PL in the same demografic group that is still in use is SQL. And everybody agrees that SQL is a pain in the ass and the people who invented it -if still alive - should be wrapped in brabed wire and shot into the sun. Larry Wall on the other hand still is a hero. Perl is fun. Sort of like riding granddads old bike that has no gearshifts and weighs a metric ton. If you tighten all the screws, fill up the tires and give the chain a good greasing you can feel the raw power.
Yet I choose Python over Perl because of it's better OOP capabilities and the fact that it's code only gets unreadable if you use brute force in making it unreadable. Python enforces good coding habbits making it handy for group projects and n00bs, has a strong foothold in lots of areas where Perl lacks (Gaming, GUI, 3D, large Web frameworks, etc
Perl is executable line noise, Python is executable pseudocode.
However, all academic discussion aside: If you think it's important to be a 'manly' programmer by preferring outdated development habbits over modern and, yes, easyer PLs, you're being silly. Perl being cool or not, there are situations were it is plain irresponsible to use it.
We suffer more in our imagination than in reality. - Seneca
Python is for weenies who want to be told how their source code should be laid out.
Perl is for weenies who want to feel superior because their language can be write-only.
I prefer Perl, myself. The few times I've used Python, I've hated the enforced layout. It seems like it wants to be a verbose LISP without all the parenthesis, but instead turned into a straightjacket.
When I've used Perl, I've felt that I'm in a maze of twisting passages, each of them the same (or *mostly* the same). But it's a better feeling for me, having the Swiss Army knife with six screwdrivers, a garment steamer, compass, knife, knife sharpener, nuclear power cell, and fly swatter. Yeah, it's a mess, but it's a *beautiful* mess.
But, like any cult, it depends on which one you want to join. Me, I joined the one that serves ice-cream on Fridays, because they allow dogs. The decision on which language to go with is almost as arbitrary, and certainly as absurd. Just pick one and code. Or pick both, and code.
Microsoft is to software what Budweiser is to beer.
People who still care about programming languages are wasting their breath.
;-)
Look at the difference between a bad, a good programmer and an excellent programmer. We're talking 1 to 2 to 10 factors in productivity and quality here, easily.
Programming languages? Unless it's a language (or programming paradigm) the programmer doesn't know (in which case it doesn't matter much whether it is Java, C, C++, Perl, Python or ruby) at all, the difference for the same programmer from one to another may exist (depending on how fluent they are), but likely more on the order of 10-20%.
This is much the same like arguing about indentation and whitespace style. None of the common ones is _significantly_ better than the other, and the time spent arguing about them sure ate up any gains they might have ever offered. Pick one and stick to it, amen.
So, the choice of language is almost irrelevant compared to the person (or team) you get to do the job.
For quite some applications, it doesn't even matter whether the interpreter or the compiler is exceptionally fast or produces such code, as long as it gets the job done. (I've seen people tune code for hours, to get it to run 5s faster at a total runtime of 1 minute once per month. While artistically pleasing, it's a waste of time.)
Sure, there's exceptions to this rule. If you want to write a Linux Kernel module, you're essentially forced to write C. Some languages have either special features in the syntax or many libraries available to solve problems in a specific problem field. (Perl really beats C for writing string matching, for example.)
But overall, these don't matter as much as you think they do.
Now, with that said, one exception I'd like to dip into, and why I'm glad that python exists. (Take note I'm a Perl head myself!) Perl allows not one, not two, but several hundreds of ways of doing the same thing. Picking one of the "best" choices to do something is a matter of style, taste and experience. Understanding it is too. So, I'd argue that -good- Perl is slightly beyond the average programmers, because if you had the skills, you'd be at least a good programmer already.
Python/Java, on the other hand, is stricter. (It starts with enforced code formatting and goes from there.) This, to a free-thinker like myself, often feels like an artifical constraint. _I_ want to decide how to do this, damn it! But, if you want to enable average programmers to just get their small hack in quickly and almost cleanly, Python might not be the worst choice, while Perl might rate pretty low.
I still love Perl. And Perl 6 looks like a real improvement, surprisingly both in features as well as in style - that is quite a feat.
End of rant
So, did you switch because you never learned to use perl effectively, or because you're such a crappy programmer that you couldn't remember to use a good coding style unless the compiler barfed when you made a mistake? :) Seriously, perl can be complicated, as there's a lot to learn...
;)
Yes, I'm quite familiar with Python. I prefer perl. My code looks good because I know how to program, not because the language forces me to indent. Changing the name of a hash to a dictionary, an array to a list, and making a distinction between read only arrays and read-write arrays does not make a language better. Replacing semicolons with newlines doesn't make a language better. Removing the ability to coerce types when appropriate doesn't make things better (if I want to treat a number as a string, I shouldn't have to make a big deal about it in a scripting language).
Granted, I have less experience with python thatn with perl, and that drives lots of my preference. But the only thing I've found better about python is the method documentation scheme. That's marginally neat. Then again, I comment my code in perl, and it works fine.
Ignoring my rather facetious comment at the beginning, can you actually give me an example of something python does better than perl, other than really large programs (which I don't think python is all that great for, either) or converting otherwise sane people into frothing zealots?
The problem with any programming language and it's once legacy source code writing style kicks in, this is true for any language, include C, C++ or Perl.
h viz-2.4.tar.gz
t ar.gz
The older the language is, the more chance that you find some unmaintainable legacy source code.
The thing with newer language with Python, Ruby,
PHP, Java and some C++ is that these are "recent" language, therefore, the odds of finding a very old legacy system is smaller.
In 10-15 years from now, you will say that Python, Ruby, PHP or Java is so "unreadable",
because they are no more the "flavor du jour"
and new constructs exists instead. Like most people says about cobol, pascal, scheme, lisp source code.
There is a difference between "unreadable" and "encrypted".
The former was not "expecting" to be unreadable, it is just badly written by mistake or use older construct that nowadays are no more used.
The later was made on purpose, which is the difference.
If you want "unreadable" C source code, take a look at Graphviz Dot, no it's not part of IOCCC and was not make to be part of it, but if you ever try to understand this legacy code, good luck!!!
Disclaimer, Graphviz dot is a nice piece of software, but it cries out loud to be heavily refactored.
In fact, the first two layers were refactored, but the core engine is dated back to the 80's with K&R style and variable/function/struct name being less than 5 characters!
http://www.graphviz.org/pub/graphviz/ARCHIVE/grap
If you want "unreadable" Perl source code,
take a look at any source code, which have:
no "use strict;"
no "use vars qw{};"
use heavily "local"
use heavily "map"
no "return" statement --> $r; == return $r;
use heavily complex non-trivial regexp without documenting them.
no documentation or POD.
use some old perl construct.
Take a look at this one,
clc (gzip'ed tarfile)
Counts total lines, noncomment lines, and statements in C/C++ source.
Written by Brad Appleton in 1995. Implemented in perl.
http://www.chris-lott.org/resources/cmetrics/clc.