Randal Schwartz's Perls of Wisdom

r3lody (Raymond Lodato) writes "Anyone who has been working on the *nix platform has had a brush with Perl, the scripting language whose acronym (depending on who you ask) could mean Practical Extraction and Report Language, or Pathologically Eclectic Rubbish Lister. In either case, there is a distinct difference between learning to use Perl, and learning to use it well. In my opinion, the best way to learn any language well is to see how others have used it to solve problems. One of the foremost experts in the use of Perl, Randal L. Schwartz, has been writing columns since March of 1995 on the use of Perl in the real world, and has provided us with 6 books and over 200 columns with many examples on how Perl is used." Read on for the rest of Lodato's review. Randal Schwartz's Perls of Wisdom author Randal L. Schwartz pages 350 publisher Apress rating 7/10 reviewer Raymond Lodato (rlodato AT yahoo DOT com) ISBN 1590593235 summary A dated compendium of the best of Randal's Perl columns

Perls of Wisdom is a collection of 65 selected columns from Linux Magazine, Unix Review, and the now-defunct Web Techniques magazines, written between May 1995 and July 2004. In each column, Randal discusses some problem that he had to solve, or that someone else needed help in solving. He carefully discusses the problem, and then shows the Perl code needed to resolve it. Many of the columns are complete applications that can be run (with minor modifications) by the reader. (The listings are also available from the apress.com web site.) Each column has been reproduced as it was written in the original magazine, with "Randal's Note" prepended. Therein lies this book's best feature and greatest flaw. Allow me to explain.

When I first picked up this book, I had only read a couple of Randal's columns (from Web Techniques), and saw that he wrote tutorials of proper Perl usage. He also relies on the wealth of modules submitted to CPAN to leverage a solution. After all, why reinvent the wheel? I expected to see more commentary on the reasons behind choosing one solution over another, or insights into the inner workings of Perl itself. I more or less got what I expected. For example, the first column reproduced in the book (It's All About Context) explains why, when someone used my ($f) = 'fortune'; instead of my $f = 'fortune'; he got in trouble with the law (see the book to understand the legal issue). The first form only retrieves the first line of the output of the fortune program, while the second form retrieves the entire output. Little items such as scalar versus list context can trip many Perl coders.

The first chapter (Advanced Perl Techniques) does give you many tips and insights like the example I just gave. All but two of the twenty columns are little tutorials on the ins and outs of handling the commonplace day-to-day issues that Perl can address with ease. Some delve into more obscure topics, such as the difference between shallow and deep copies of structures, and Perl's Taint mode. Two columns contain complete programs. One extracts the text from the man pages and determines their "fog" index (a measure of readability). The other creates a mirror of files needed by CPAN.pm to install new modules. For each program, Randal gives the entire listing as well as an almost line-by-line description of how it works. Each column is written in a conversational style that is easy to read, yet doesn't talk down to you.

The following chapter is comprised of seven tutorials on the various aspects of searching, sorting, and formatting text. In addition to describing the creation and compilation of regular expressions, Randal also discusses formatting and the nifty "Schwartzian Transform" (Perl's map-sort-map idiom for sorting on almost anything) which was named for him, but not by him. While some of the information is a little long-in-the-tooth (the column on Text-Processing was written shortly after Perl 5 was released), it's all interesting and educational nonetheless.

Chapter 3 starts refocusing the use of Perl to web sites. This chapter discusses HTML and XML processing in six little columns. He shows how to generate a web page index, producing a web page calendar from a file of events, and parsing XML to retrieve the data within. He also includes a lesson on how to use Perl to compare two arrays to create an HTML-formatted difference table.

The next chapter demonstrates that Randal has spent a lot of time working out ways to update and improve his web site. It covers the intricacies of CGI programming in Perl. All but one of the fifteen columns are complete programs (again, available from apress.com) with line-by-line commentary. The programs do implement mostly worthwhile functionality, but each column was pretty much "I had this problem, so I wrote this program. Lines 1-3 do this; lines 4-5 do that, etc." Granted, some of the programs are pretty nifty (check out how he automatically keeps track of the "What's New?" pages), but the reading of one program after another started to become stale.

The final chapter is titled "The Webmaster's Toolkit," consisting of fourteen programs and three tutorials. Randal covers diverse web server background topics such as creating a light-weight load balancer, random links, and forcing users to enter through the "front door." There are also instructive techniques for throttling your web server's usage of the processor (a necessity at the time for Randal, as his web site was co-resident on a server with others), and calculating download times.

In its entirety, Perls of Wisdom contains 65 columns, split roughly half-and-half between tutorials and fully commented programs. More than half of the columns show that Randal uses Perl for web processing more than for general scripting, data reduction and reporting. His tutorial articles are top-notch, but I have a quibble over his program articles, which are somewhat dated. There were a number of prefaced notes to the effect that today he'd do it differently with some new feature or CPAN module. I really wish he had actually updated the column to show the new coding techniques. The original code is interesting in the historical sense, but I wanted to see nuggets of Perl wisdom for me to use in my daily job. The writing style is fine; the bits of insight are useful, but many of the programs are too specific to problems you or I may never see, and were solved in code that's showing its age. I'm glad I got to read the book, but I think it only rates a 7 out of 10.

You can purchase Randal Schwartz's Perls of Wisdom from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

CGI programs

[JaxWeb]

I first learn Perl with the aim of creating dynamics webpages. I learnt from the tutorial Picking Up Perl - this is great and taught my most I needed to know with regard to the language - but it didn't teach me how to use it for websites.

I picked up from code lying about how to read and write files, get post/get data, and so forth, and slowly built up into quite a good Perl programmer (I suppose. Not amazing, but quite fluent). This wasn't easy though and was slow. Why? I never got taught, all in one place, how to do that. I think this is what this book is trying to do - but with a much wider range than just CGI programs (although it doesn't seem to neglect it, either).

I tried to write my own tutorial for using Perl in webpages to try and help. I'm not going to link to it here though, because it is quite terrible (I was 14 when I wrote it).

After learning Perl, and being able to use it, there is always using the standard librarys. For this, PerlDoc has been so helpful to me.

Link to Randal's Articles

[Matt Perry]

Since there wasn't a link to Randal's collection of articles I'm providing one here. There's some excellent stuff in there.

Re:Link to Randal's Articles

[wmshub]

Give it a rest. I was a coworker of Randal at the time that he committed his felonies. My opinion, which was shared by the other coworkers I spoke with ath te time, was that he was guilty of two things: lack of common sense combined with making enemies within the organization.

As an aside, he was probably the best sysadmin I ever worked with. When you wanted something done, he got it done.

Re:Link to Randal's Articles

[merlyn]

Thank you for that. Stupid, yes. Forgot to tell my boss everything I was working on, yes. Perhaps a bit self-serving, looking for unrequested things that'd be "good for the company" so that I'd get hired longer and more often, yes.

But intending harm, no.

"No harm, no foul."

Reading Perl code?

[treerex]

Because of Perl's TIMTOWTDI mantra reading other people's code can be an exercise in frustration, IMHO, because to grok what they have written you may end up delving into some of the more baroque syntax in the language. I've found that many people like writing incredibly terse code which makes its readibility incredibly difficult. While Schwartz may write comprehensible Perl, I expect that the bulk of Perl code in the wild is anything but. This is my biggest peave with the language, and how it can pride itself on this "feature" is beyond me.

Re:Reading Perl code?

[eln]

A good programmer will write readable code in any language he's writing in. Yes, there is a considerable faction who delight in making Perl code as obfuscated as possible, but it certainly doesn't have to be that way. C allows you to write some pretty ugly code too, but that doesn't make it a good idea to do so.

The TIMTOWTDI ethos is ultimately what makes the language as useful as it is. The more ways there are to do things, the more things you can do with a little creativity. The Perl language is abstracted, as all higher level languages are, but it's forgiving enough to allow you to do things that may not be possible in other languages without a great deal of pain.

The myth that all Perl code is unreadable is preposterous. I've written several very complex pieces of code in Perl that are not any more difficult to comprehend than any piece of C code designed to do the same thing, and often much less so. The phenomenon of obfuscated code is a result of poor programmers (and a pervasive subculture), not of the language.

Re:Reading Perl code?

[smallpaul]

A good programmer will write readable code in any language he's writing in.

The world does not break down into three distinct camps: "Non-programmers", "Good programmers" and "bad programmers". Actually there is a spectrum and all programmers live somewhere along it. A language can encourage readability or discourage it. What does Perl do?

The TIMTOWTDI ethos is ultimately what makes the language as useful as it is. The more ways there are to do things, the more things you can do with a little creativity.

I'm sorry, one does not follow from the other at all. If I added a "+++" operator to C that increments by two then I now have at least three (obvious) ways to increment by two. Does that mean that I can now be more creative in C?

The myth that all Perl code is unreadable is preposterous.

Nobody claimed that in this thread.

I've written several very complex pieces of code in Perl that are not any more difficult to comprehend than any piece of C code designed to do the same thing, and often much less so.

Strange that you use C as your benchmark. How about a language designed in the last twenty years with readability as a goal? Perhaps Java, Python, Ruby, O'Caml, Haskell, etc.

Re:Reading Perl code?

[treerex]

I agree with everything you say, though some languages make writing read-only code easier than others. APL comes to mind immediately. I did not intend to convey the fact that Perl was unreadable. Rather I feel that Perl gives you more rope to write unreadable code than other languages, like Python.

Of course you can write some incredibly terse code in Python too, especially with recent language additions.

And I would not include C in a list of languages for writing readable code in.

Re:Reading Perl code?

[jdavidb]

If you think the Perl community describes the Obfuscation contests as an argument for the use of Perl, you are confused about who the community is.

To me, the Perl community is that group of people that does promote readable Perl. Randal Schwartz is a part of that. There is a community out there of very good programmers who love Perl, and plugging into that community has been one of the best moves of my career. The people who actually invented and maintain Perl (Larry Wall, et al) are the real community, and they are very good programmers. The fact that there are a lot of other people out there knocking off quick scripts, running obfuscated contests, and writing ignorant books without reference to the accumulated wisdom of the real Perl community is not in any way a poor reflection on the Perl community and the Perl language.

Yes, the good programmers of the Perl community do occasionally play a round of "Perl golf" or have an obfuscation contest. But noone worth his salt has ever put those forth as if it were a positive reason to use the language.

Good programmers who use Perl use Perl because it is possible to write very good, high quality, modular, readable code in Perl. The people who actually create Perl exemplify and encourage this.

Re:Reading Perl code?

[jdavidb]

• use Perl; is a good place, but very informal and tends to get sidetracked into politics :)
• Your local Perl mongers group may be a great place
• YAPC (Yet Another Perl Conference) and the Perl conference (now part of the Open Source conference) usually have many good presentations by the truly great Perl programmers
• I have the impression that Perlmonks is pretty good, though I don't tend to use it much
• Finally, the Perl5 Porters mailing list is the real original heart of the Perl community, though I think nowadays many of those guys have moved onto Perl6 work

A list of names is also useful: material by Damian Conway, Larry Wall, Randal Schwartz, Mark Jason Dominus, Simon Cozens (Perl involvement now minimal due to career change), and persons associated with them is going to be top notch. Plug their names into Google and see what they have to say. Catch a presentation or read a book by one of them if you can. Meanwhile, there is truly a lot of junk out there. There's an article out there somewhere about "how to tell a good Perl book from a bad Perl book," which I thought was by Mark Jason Dominus, but I can't seem to find it at the moment.

Finally, 90% of the useful modules you'll see recommended for use from CPAN are written by the intelligent lights in the Perl community. The time-tested modules that are now standard solutions are those that were written with high quality by good programmers.

Re:Reading Perl code?

[Anonymous Coward]

By having many ways to do a thing, chances are, one will fit your thought process better than the others... and you'll have a tool you are comfortable with.

This speaks to the developer's experience, not the code maintainer's. The code maintainer is stuck maintaining code idioms not of his choosing: and the more idioms there are, the more idioms the maintainer needs to understand to maintain them all.

Working with tools you are comfortable with... will make you more creative. Because you will spend your energy focusing on the problem, not on how to use your tool.

Again, this balances developer comfort ("I get to choose the best fit of ten expressions! Woot! I'm so comfortable!") against maintainer comfort ( "I have to know ten different ways to maintain ten different developers code. Why can't they all just pick one! *grumble*").

Maintaining someone else's code is usualy harder than writing your own, for the comfort factor you cited. A development culture that accepts esoteric ways to write code can be a nightmare, because the coder's defense is always There's More Than One Way To Do It.

If there's One Way To Do It, and that's what the coder did, then I know exactly what it does. If there's One Way To Do It, and the coder didn't quite do that, then I've found a bug, or the coder wrote something subtle, and didn't comment it clearly. In either case, the fact that the code needs fixing stands out clearly.

If There's More Than One Way To Do It, and what the coder did isn't clear, then I have to think hard to decipher what's going on, and whether it is what it appears to be, or whether it's some subtle little Perl trick.

In short, TMTOWTDI helps developers, but at the expense of maintainers, and QA staff charged with proving code correctness.
--
AC

Re:Reading Perl code?

[SilicaiMan]

If I added a "+++" operator to C that increments by two then I now have at least three (obvious) ways to increment by two. Does that mean that I can now be more creative in C?

You give an extremely naive example. Even Perl doesn't allow you to do that ;-)

But, consider this. Perl allows you to postfix your if() statements, like so:

wave() if $person_seen eq 'Paul';

This is much more naturally readable than:

if ($person_seen eq 'Paul') { wave() }

Similarly, you can use unless to make code easier to read:

buy_food() unless you_forgot_your_wallet();

This allows you to emphasize that buying food is the norm, and you would normally do it unless you forgot your wallet. The equivalent negative-if form does the exact same thing, but does not allow you to express your intent as well as this does.

This is the essence of TMTOWTDI. You don't HAVE to use alternate ways to do things if you don't want to. But it does help most of the time in conveying your intent when you wrote the code, which make it more maintainable.

Once I read someone comparing Perl to the human brain. The brain is a double-edged sword: it can compose the most pleasing melodies and most beautiful literature, but at the same time it can hatch evil plots of large-scale genocide and mass murder. Creativity has a dark side to it. Attempting to suppress that side will severly hinder the creative process. Same thing goes with Perl.

I think Larry got it right.

Re:Reading Perl code?

[ajs]

"A complex list comprehension can lead to some powerful code that does an amazing amount of stuff in a neat little package. To me this is different than the arbitrary line-noise you get with Perl."

There you just lost me. The term "line noise" implies a low signal-to-noise ratio, when in fact Perl presents exactly the opposite. The SIGNAL is in fact, so high that many programmers find it difficult to cope with. That's fine, but let's not confuse that with actuall NOISE.

"So Perl 6 lets you define your own syntax so that someone reading your code neads to figure out what your ideas of the Right Language is?"

No. You wholy misunderstood the concept.

In Perl 6, you will have full access to the grammar, so you could enforce your local stylistic conventions. You would obviously not want to make INCOMPATIBLE changes so that your code is still valid Perl, but you could write your own "strict".

Think of it this way. Imagine a C++ header that caused all uses of operator overloading outside of a limited few "neccessary" to be illegal, or that issued a compiler warning on every use of an iterator initialization outside of a for loop. These are just simple (and not very useful) examples, but they serve to illustrate the point: you can instrument the compiler just as fully as you can instrument your code. Don't like the type checking in Perl 6? Make it stricter.

I'm sure that there will be someone who will publish the "python-like bondage" module 15 minutes after Perl 6 is released. If you're into that sort of thing, then your company can take full advantage of it, while still getting all the value of Perl 6 like LISP-style currying and macros, Ruby-style mixins, cross-langauge bindings through Parrot, boxed and unboxed type constraints on standard Perl scalars, full multi-method dispatch, etc., etc.

"Common LISP and Scheme's macro facilities can be used to define your own language constructs"

Yes, but we're not talking about defining language constructs. We're talking about changing the behavior of the compiler in structured, standardized ways that aren't just implementation hacks. Don't get me wrong. Common LISP is on my list of cool languages to learn more about right below Python and Ruby. I'm just saying that these particular Perl 6 features bear a bit more looking at.

"Or hell, TeX lets you redefine the world if you are so twisted, though to me TeX is more unreadable than Perl."

TeX is actually a good example of what I'm talking about. TeX is very readable for a full typesetting system, but most of us could not care less about typesetting. When you need to do specific tasks that INVOLVE typesetting, but you don't really need all of that power and flexibility, you step up a layer of abstraction and turn TeX into LaTeX. LaTeX is valid TeX, so it's not quite the same, but the idea of limiting a powerful system in order to step back a level of abstraction holds.

Perl 6 will provide all of the power that you need from a modern high-level programming langauge, but let you manage that complexity. You might decide, for example, to restrict Perl 6 in your programs to just the facilities that make sense for scientific calculation. You might even introduce a special syntax/grammar for putting differential equations directly into your program without having to quote around them and hand them off to a seperate processing tool (object, module, what-have-you).

None of this is useful for your average 1000-line CGI program, but for the company that produces tens to millions of lines of structured libraries upon which new software is built and re-factored over time, this will all be a godsend.

Much of what Perl 6 brings to the table, Common LISP has done for years, but some of it is either gathered from other, more recent langauges (e.g. Python, Ruby, Scheme, Java, etc.) or is, as far as I can tell, unique. I hope you give it a try and throw away your naive ideas of "line noise" in favor of considering the value to your productivity and the maintainability of your code base.

$subject

[Anonymous Coward]

I really $feeling $author. His contributions to $language were $adverb $adjective. I really hope he $does_doesnt[int rand(1)] write more books. The are $adverb2 $adjective2.

Tip #1...

[MoeDrippins]

Don't Hack Into Your Employer's Systems

learning languages

[bungley]

In my opinion, the best way to learn any language well is to see how others have used it to solve problems.

Strange, everyone else I've spoken to EVER has said the best way to learn a language is through practice. Then again, I suck at programming.

Perl doesn't kill readability...

[jqh1]

People kill readability (with Perl).

Seriously, choose the right tool for the job. When we've got a sys-admin level scripting task, and someone can go in and knock it out in a half hour (or less) with a few lines of Perl, who can say that's bad? I'm currently wading through a bunch of heavily patternized java that pulls checkin logs from a scm system and updates an issue tracking system as part of the build process. It's taken me *days* to begin to "grok" what's going on in the many associated xml config files and bizarre string handling approaches that were used in this undocumented hack. I'll replace it with probably less than 150 lines of Perl, and someone else will happily (and much more easily) maintain it. So there!

At the same time, we've got > 25 developers distributed around the world working on a big commodities trading app -- java works pretty well for that.

Re:Perl doesn't kill readability...

[m50d]

Yes, but perl is a hair-trigger for you. Obfustucating C or Java takes a bit of effort. Obfustucating Python is pretty hard, your best bet is to lambda over everything and hope the reader isn't a primarily lisp programmer. Obfustucating perl can be done without thinking. Seriously, perl is a tool for quick scripts that will be rewritten rather than edited. It's designed for things which take up less than one page of code to write. It's fast to write short programs, but you should think again before writing a big one in perl, maybe try and chain some small ones together instead.

Re:Perl doesn't kill readability...

[ajs]

"People kill readability (with Perl)."

As they do with C, C++, Java, Snobol, Forth, APL, C#, etc, etc.

Half of the people programming are below-average programmers. Bad programmers can make life HELL in C, and by the same token good programmers can make life quite easy in Perl.

That said, Perl gets a bad rep, not because good code is hard to read, but because a) bad code is more common in any language which is easy to learn and b) Perl has several features which people mistake for non-readability (that is, non- or inexperienced Perl programmers assume that code is hard to read because they don't know Perl and see these things which scare them):

• Regular expressions - This is a common feature in almost all languages these days, but the ease with which they are integrated into Perl syntax makes them more common in Perl programs. Of course, you have to be careful about the amount to which you let such constructs take over your code, but Perl was the one to introduce whitespace formatting and comments into regular expressions for just this reason.
• Typing glyphs - Many programmers from the C/Pascal/Fortran - derived world take exception to the prefix-characters in Perl. Some Perl programmers find it hard to read C code that uses subroutines, complex data structures and simple types without any indication of what's being accesed or how. It's a matter of time and exposure on BOTH sides, and being a programmer in both worlds, I can tell you that both are equally readable with sufficient exposure.
• Context sensitivity - Perl's context sensitivity spans every level from the way the tokenizer works all the way up to the handling of large-scale data structures. This is the nature of a language designed by a linguist. It "reads well", but only when you start trying to read it like a spoken language, and not a mathematical code. Software source code has always been somewhere in the middle-ground between those two extremes, and it's jarring at first that Perl moved the line so much, but give it a while and you find that it's much easier to think and communicate complex ideas (by complex, I mean cognitive complexity, not code complexity) in Perl than in any other programming language.
• Weak typing - This is a matter of religion, but I'll make a footnote of it anyway: Perl is weakly typed, and that frustrates many who are used to strong typing. Neither is better or worse, though the fact that Perl 6 will (as Common LISP has done for quite some time) give you both is a boon, I think.

Re:Perl doesn't kill readability...

[moof1138]

I have had to deal with a lot of Perl, Java, and PHP. The nastiest ugliest code I ever inherited was PHP. I agree that Python tends to be more readable since it has a more limited... expressiveness... than Perl, but PHP with it's endless heap of little functions that do nearly the same thing and its oddly inconsistent namespace can mutate as readily as Perl, especially when wielded by an inexperienced programmer.

TIMTOWTDI acronym expanded

[PornMaster]

For those trying to follow along but not able to immediately expand the acronym, TIMTOWTDI is There Is More Than One Way To Do It.

perlmonks

[Porag_Spliffing]

For anyone getting into perl I can not recomend The Perl Monks Monastery enough. Lurk for a while, use super search to find the answers to almost any perl question you may have and if all else fails post to Seakers Of Perl Wisdom and enlightenment shall surely follow.

Randal is a regular contributor there and many of the other leading lights of perl pop up frequently.

Regards,
A monk.

Re:Perl and work

[gurps_npc]

You made an error that I think a lot of people make.

It is not how long it takes you to understand a perl script of X length that is relevant.

What SHOULD be the important data is: Whether it would take you MORE time to understand a C or Java program that does the same thing.

I have seen cases where people complain that it takes them a week to understand a Perl Script of 500 lines. So they write a new program in C, that does the same thing in 5,000 lines. Which then takes me 8 days to understand.

One of Perl's image problems is that because it does so much with so little, people underestimate what the tiny program does and therefore get frustrated when it takes them more time to understand than a C program of the same size, even though the C program does 1/10 what the Perl one does.

Dear Mr review writer...

[rjshields]

my ($f) = 'fortune';

Should use back ticks instead of single quotes like so:

my ($f) = `fortune`;

Otherwise you assign the string "fortune" rather than the output of the fortune program ;)

Schwartzian Transforms and raised hackles...

[Fahrenheit 450]

Randal also discusses formatting and the nifty "Schwartzian Transform" (Perl's map-sort-map idiom for sorting on almost anything) which was named for him, but not by him.

This is one of the things that's always annoyed me about Perl and its practitioners (well, most programmers, really)...

Given the long history of functional programming (hell, Lisp is closing in on 50 years old), this map/sort/map idiom had to be second nature to any Lisp/Scheme/Haskell/ML/etc. programmer at the time Schwartz wrote about it back in 1996[1]. And the fact that this was such a revelation to the people who read his column that they named the idiom after him just exposes the lack of a diverse programming background for most people. I'm guessing that 50% of the coders out there wouldn't know a map or a fold if it bit them on the ass, and even more wouldn't have a clue as to how to solve something so basic as the missionaries and cannibals problem in a declarative/logical manner (without the help of Dr. Google that is).

Meh... Bitter rant over, I guess...

[1] I could be wrong, I didn't really do much coding before 1995-ish.

Re:Schwartzian Transforms and raised hackles...

[merlyn]

I've actually said your exact point a number of times. In fact, I didn't "invent" anything. I was solving someone's problem, who had posed the problem in the Perl newsgroup, using the knowledge I had at hand. As I'm also a LISP hacker (see my "pretty printer" in the GNU Emacs distribution), I simply relied on my knowledge of simple list manipulation techniques to transform the problem into something workable.

I had no idea it would take on a life of its own as a standard idiom. And it was not originally "for a column". It was a usenet posting and wasn't presented as anything remarkable.

Just trying to set the record straight.

My Sig Says It All

[frank_adrian314159]

You don't learn Perl - it gets absorbed through the blood-brain barrier. Leads to nasty flashbacks, too...

Re:Perl and work

[bani]

that's part of the problem with perl -- the code is often incredibly terse and dense.

you can do incredibly complex things in a few characters in perl, which can be far more difficult to grok than the same thing described in 20 lines of C code.

it's both a blessing and a curse. a blessing because you can beat out very complex things quickly, and a curse because it is a major pita to maintain.

perl also stubbornly avoids some useful language constructs in the name of "language purity". eg case statements. yes i know about Case.pm, but its not stock perl. and yes i know perl6 will have it. only took them ~20 years to get there :-P

About 'my ($f) = `fortune`;'

[Shachaf]

Read more about the issue here.

Re:Not an acronym!

[teknomage1]

From perlfaq

What's the difference between "perl" and "Perl"?

One bit.

Oh, you weren't talking ASCII? :-) Larry now uses "Perl" to signify the language proper and "perl" the implementation of it, i.e. the current interpreter. Hence Tom's quip that "Nothing but perl can parse Perl." You may or may not choose to follow this usage. For example, parallelism means "awk and perl" and "Python and Perl" look OK, while "awk and Perl" and "Python and perl" do not. But never write "PERL", because perl is not an acronym, apocryphal folklore and post- facto expansions notwithstanding.

I like Perl

[Cyno]

I wrote a Perl script yesterday with a bad algorithm using 2 lists. Ran all night and was still running when I got into the office this morning, and it didn't spit out any relevant data.

Rewrote the script using 2 hashes in about 15 minutes. Completed in less than a minute with all the info I was looking for.

So, um, I think an evaluation of most programming languages is more dependant on the programmers than the language itself. Sure some languages lack the proper data types or features, but any modern/complete language is capable of being readable and resource efficient if the programmer knows what they are doing. IMO, of course. I'm not a developer.