The Secret History of Perl

TimToady writes "Many otherwise intelligent people seem to think that Perl just sort of happened by accident. But Linux Magazine has just now put their October issue online, and it includes an article entitled Uncultured Perl: Perl's Creator Shares his Thoughts on a Subversive Lifecycle. It's basically the secret history of how Perl infested the world, intentionally subverting everything in its path including the NSA, Unix, and the GPL. " Reading Larry Wall stuff has to rank as one of my favorite reading experiences.

Comments

Perl Rawks

[Anonymous Coward]

I work for a major American automotive manufacturer, and we use Perl every day to write mission-critical applications. As in "if this doesn't work, we don't make cars"

This isn't CGI-scripting, this is applications development, stuff my peers do in C, C++, Smalltalk, or Java.

We work an order of magnitude or two faster than these other groups, just because Perl is so easy to pick up and work in - and because professionally written Perl is so easy to maintain.

Not to mention that every single deployed Perl application has it's source code _right there_. It is impossible to lose Perl source.

I would not be suprised to see Perl completely replace Java in the next few years, especially if Sun keeps acting the way they are.

Go Perl!

Re:Legos kiddies and professional architects

[Anonymous Coward]

Please endeavour to express whatever sentiments lie behind that outburst using substantiating reasoning rather than emotive expletives. [...]Perl is not a rebellion against `good design'. In many senses, it is an expression of the same, where good design means something organic and adaptive, something tuned more to the wait people think than to the way computers operate.

Ok: I think Perl is a badly designed language that makes programming in it harder than it should be. Here's why.

First, the type system, or more precisely, the lack of one. Values are not type-safe, in the sense that they can change meaning based on the context they show up in (eg, strings and numbers).

Please note that I'm not talking about dynamic versus strong typing: I'm talking about the types of values. Common Lisp and Smalltalk are both dynamically typed, but a value in either language always has a well-defined type. When you want to change the type of a value you do it explicitly.

An example of how this problem complicated the design of Perl is the need for two sets of operators to distinguish whether you are treating a scalar as a string or a number. In a language with well-defined types, it's trivial to overload operators so they do the right thing polymorphically -- look at Cecil's generic function mechanism for an example of how this works.

Dynamic scoping. I'm aware of the existence of 'my', but having two different scoping mechanisms (one of which just shouldn't be used but is nonetheless the default) is an undeniable crock.

Argument list flattening. Again, there are ways around this, but they require fairly sophisticated understanding of the language. To add insult to injury, there's no simple way of naming the parameters of a function. Even Scheme has this -- and it's the sort of language that gives you sand and a fire if you want a wineglass!

The syntax. One of the persistent-but-wrong claims about Perl is that having lots of syntax is an indication of how the Perl culture values having more than one way to do things. In fact, much of Perl's syntax is just pointless complexity. Syntax is helpful when it distinguishes different semantic domains; it is a bad thing when dissimilar ideas are conflated or when there are similar ideas with wildly different spellings. (For example, see how Haskell and ML use syntax to distinguish type specifications from function definitions.)

For example, why is 'eval' used to denote exception handling? Why are references to aggregates prefixed with a '$'? How come packages and classes are defined with the same syntax? There are answers to all of these, but those answers are historical rather than meaningful. Cars used to have reins in the early 20th century, but no one would argue that they belong on a car for the 21st.

In order to properly support having an sophisticated syntax, the right thing to do is to have a facility for syntactic extension like Lisp macros. These can be extended to infix languages, btw -- see Dylan for an example of how.

One last bit: don't denigrate the accidental programmers who've had Perl thrust upon them, or who have turned to it from a starting point of zero knowledge. They're doing the best that they can, given the circumstances, and should be encouraged, not squelched.

I agree with this 100%, and am quoting it just so it will be repeated. The fact that Perl encouraged people to start automating grunt work means that it is a great benefit to humanity, no matter how imperfect it is from a CS standpoint. (The same could be said of Basic, for that matter.)

Larry Wall is a treasure

[jht]

In the whole community, there are a large number of talented programmers, and a smaller number of truly elite hackers who can do most anything.

And then there is a tiny group of people, who could probably be counted with your fingers and toes, who just have that certain "it" that lets them understand their work, the needs it fills, and the larger context into which it all fits.

Larry Wall is close to the top of that list. Unlike most, he understands that what he produces means something in relation to the rest of the world and the community. Perl is the kind of tool that could only come from a mind like Larry's - and there aren't enough of those minds to go around.

Thanks for Perl, Larry - my sysadmins thank you too. Please - look both ways before you cross the street, and every other precaution we can think of. We can't afford to lose you...

- -Josh Turiel

I just LOVE this quote:

[jabber]

It's almost like we're doing Windows users a favor by charging them money for something they could get for free, because they get confused otherwise. --LW

It's free-based Wall.

I nominate the above quote as the new open-source motto. Ha!

Re:Crazy guy, crazy language

[evilpenguin]

I don't think Larry Wall would hold perl up as a paradigm for language design. What he would do is to hold it up as a very useful language for doing what you need done right now as opposed to what you done right now.

It's much eaiser to do C-like things in a bug free manner in perl. Add to this that perl is a "scripting" tool, as opposed to a compiler (yes, the language is "compiled," but not in the same sense as with a true compiler) so you don't have (well, mostly don't have) the make complexities; editing code is also building code, so rapid toolmaking is facilitated.

Sure bad perl is hard to debug, but nowhere nearly as hard as debugging bad C.

There are "purer" languages that are very well designed. Java is certainly easier to write bug free programs in than any other language I personally use, but it isn't all that well suited to the kinds of applications I use perl for: what I lovingly call "suck and puke" applications.

I know that people use perl for end-user applications, but with the exception perhaps of CGI, I wouldn't ever do that.

I also would use Java to write a filter.

I get kind of tired of the search for the "one true language" or the "one true tool," or even "the one true design method."

A rich palette of tools, designs, and methodologies of managable complexity gives you the greatest ability to confront any situation.

Interesting statement[s]

[Pike]

"In particular, we really needed to have a commercially packaged version of Perl for the Windows folks, because many of them were (and still are) clueless about open source. It's almost like we're doing Windows users a favor by charging them money for something they could get for free, because they get confused otherwise."

This is a common misperception among Windows users; that you get what you pay for. Having to shell out some cash makes us think we're actually getting a better deal somehow. Go take a $40 tie from the Daytons place and put it in a Target for buy it. Not a bulletproof metaphor, I know, but illustrative nonetheless.$4.59: somehow people will be far less likely to

Speaking of bulletproof metaphors, I like Larry's comments about the Cathedral and the Bazaar. The Linux kernel is far more like a Cathedral built in full public view by a small crowd of highly skilled volunteers than a bazaar full of dirty tents and shouting people. Perhaps the users in the Linux community at large act as though they are in a bazaar, but the metaphor just doesn't fit, and LW points this out well.

Re: It doesnt have to be this way

[Tom Christiansen]

The most ugly thing in my mind being the

while(<>)

type of construct. It is synonymous with all that is bad about perl syntax. Saving a few characters does not in anyway make it a more powerful language. It just caters to people who are too lazy to write readable code. THIS is the problem with perl.

Excusing your abuse of the word "synonymous", I really must disagree with your use of the word "few". Those "few" characters you just saved are in fact all of this:

if (@ARGV == 0) {
unshift(@ARGV, '-');
}
while (defined($ARGV = shift(@ARGV))) {
if (!open(ARGV, $ARGV)) {
warn "Can't open $ARGV: $!\n";
next;
}
while (defined($_ = <ARGV>)) {
# ...
}
}

You see, while (<>) {} is a standard way of writing a rather complicated but extremely frequent pattern found in virtually all filter programs. Let's call it the `filter pattern', shall we? Now, do you really want to make people write that whole thing out every single time they care to employ the filter pattern? What will that save? Is it somehow clearer to write in low-level than in high-level code? Not necessarily. It depends upon the level of abstraction at which you focus. Is it perhaps less error-prone? By no means! It's more prone to error, not less so. That's because because replacing one line of code with a dozen (or what have you) increases the risk of error that many times as well. It also distracts the reader and the writer from the problem at hand. And it causes synchronization issues if you care to update that bit of code in one place. Wouldn't you like to have it updated in all places instead, all at once, so you don't have to remember to change it in all places? I know I would. And yes, this has actually occurred for that bit of code. Thank goodness we had a pat idiot for a standard pattern.

Of course, there's an even briefer version of that pattern: the -n or -p command-line option, as seen in filter programs such as this one:

#!/usr/bin/perl -p
#
# code2html - convert code to html for posting to slashdot
#
# tchrist@perl.com
# Sunday, December 19th, 1999

BEGIN { print "<TT>\n" }# AND THE SPIRIT OF awk...

# first kill all the tabs
1 while s/\t+/ " " x (length($&) * 8 - length($`) % 8) /e;

# then the four standard naughty bits
s/&/&amp;/g;# must remember to do this one first!
s/</&lt;/g;# this is the most important one
s/>/&gt;/g;# don't close too early
s/"/&quot;/g;# only in embedded tags, i guess

# make lines break where they should
s/^\s*$/<P>/ || s/$/<BR>/;

# make sure spaces aren't squishticated so we
# can do indentation and properly align comments
s/( {2,})/'&nbsp;' x length($1)/ge;

END { print "</TT>\n" }# ...SHALL BE WITH US ALWAYS

Life is too short, and too prone to error, to write all that out in longhand each and every time I care to employ that pattern.

Articles vs Comments

[Tom Christiansen]

After some 255 comments posted, it's pretty clear that nearly everyone is commenting on the comments instead of commenting on the articles.

That's really quite a shame, because the article is rather a good bit better than the comments are.

Re:Crazy guy, crazy language

[Tom Christiansen]

Perl affords too much flexibility.

Kindly explain your premise. Please document which flexibility is wrong, and why. Expound upon precisely which areas you would prefer inflexibility in. Demonstrate why your desired lack of expressivity would help you.

Perl has a finite syntax, one that's infinitely easier (no, that's not hyperbole; it's true) than any natural language. The excuse that there are thinks you will not have time to learn in a ten-minute perusal of the language is no excuse whatsoever.

You'll have to work much harder than you have to justify your position.

Re:Legos kiddies and professional architects

[Tom Christiansen]

By the way, it kind of looks silly when you get all sanctimonious about people who rip on Perl, and then give us an ALL CAPS yell about "Visual Basic Weenies!" (at the same time, demonstrating a mean touch with the HTML bold tag). What is this, a schoolyard bullying chain -- the C jocks beat on the Perl geeks who beat on the VB handicapped kids?

I think to this one I shall respond in code:

@lengs = qw(C C++ Java Pascal Perl Basic FORTRAN COBOL);

for $coder (@lengs) {
for $proggie (@lengs) {
next if $coder eq $proggie;
print "Don't hire $coder hackers to maintain $proggie code!\n";
}
}

print "\n";

for (@lengs) {
print "Hire $_ hackers to maintain $_ code.\n";
}

There. Now the blame is more equally distributed, and the advice hopefully more clear.

Perl and Y2K

[jidar]

Let me just say, ack! I read the Y2K info on perl and was assured that Perl was compliant. When the rollover happened several of my scripts started printing the year as 100 or 19100. I blame myself for not having looked into the problem deeper, I just read the popular opinion information on the net about how Perl is Y2K compliant. Well it turns out it is compliant, but only if you use it 'right'. Here is an example. If you use the localtime class it will return a year in what appears to be a 2 digit format. I say 'appears' to be because it turns out that localtime isn't returning a 2 digit format at all, its actually returning a number which is the number of years elapsed since 1900, which just happens to look like the familiar 2 digit format we all know and love right up until the Y2K rollover happens. Here is what I mean, a month ago the year portion of localtime returned '99', now it returns '100'. According to many perl sites, however, this is Y2K compliant. They would have me believe that everyone has been using it wrong and that if people would have wrote their code correctly in the first place this wouldn't happen.
The solution?
printf("The year is %d\n", 1900 + localtime() -> year);

Thats fine by me, I don't have a problem doing that. I just get pissed off at how arrogantly all the literature on this subject treats the topic. "There is no Y2K problem in perl, you just suck"

Okay.. riigghht. That wasn't a coder problem.
"We are just using an entirely new way to represent the date that isn't more human readable, or more machine friendly, that just happens to look exactly like the standard 2 digit year format until the year 2000 occurs, at which point it still works exactly as planned."

Can you spell denial?

I dont mind putting in workarounds, *shrug* big deal. I just get a bit indignant when my intelligence is insulted this way.
http://language.perl.com/news/y2k.html

Re:Perl and Y2K

[Tom Christiansen]

"We are just using an entirely new way to represent the date that isn't more human readable, or more machine friendly, that just happens to look exactly like the standard 2 digit year format until the year 2000 occurs, at which point it still works exactly as planned."

You aren't going to want to hear this, but listen carefully: you did not RTFM.

It's clearly documented. Always has been. You were just guessing how localtime(3) behaved instead of looking it up and reading the precise behaviour. A library API is a contract. If you sign up to using that library without reading the fine print, then you cannot complain when that fine print bites you in the ass. Stop guessing, and read!

You are incorrect in your assumption that this is somehow peculiar to Perl. Whether it's peculiar in general is another question entirely. :-) I wrote about this in a letter to Dan Gillmor. Essentially, you need to understand a struct tm. Apparently the situation is even worse in Java Script, where it appears that different implementations behave differently.

If you're on the cutting edge of Perl technology, please pay special attention to the new -DPERL_Y2KWARN configuration option. It produces an effect like this:

% perl -we 'printf "Year is 19%d\n", (localtime)[5]'
Possible Y2K bug: %d format string following '19' at -e line 1.
Year is 19100

Interesting, eh? Another option is to use the D'oh::Year module by Michael Schwern. The author wrote about it here in Dej a News. Anyway, here's the README.Y2K file from the 5.005__63 release of Perl:

The following information about Perl and the year 2000 is a modified version of the information that can be found in the Frequently Asked Question (FAQ) documents.

Does Perl have a year 2000 problem? Is Perl Y2K compliant?

Short answer: No, Perl does not have a year 2000 problem. Yes, Perl is Y2K compliant (whatever that means). The programmers you've hired to use it, however, probably are not. If you want perl to complain when your programmers create programs with certain types of possible year 2000 problems, a build option allows you to turn on warnings.

Long answer: The question belies a true understanding of the issue. Perl is just as Y2K compliant as your pencil --no more, and no less. Can you use your pencil to write a non-Y2K-compliant memo? Of course you can. Is that the pencil's fault? Of course it isn't.

The date and time functions supplied with perl (gmtime and localtime) supply adequate information to determine the year well beyond 2000 (2038 is when trouble strikes for 32-bit machines). The year returned by these functions when used in an array context is the year minus 1900. For years between 1910 and 1999 this happens to be a 2-digit decimal number. To avoid the year 2000 problem simply do not treat the year as a 2-digit number. It isn't. When gmtime() and localtime() are used in scalar context they return a timestamp string that contains a fully- expanded year. For example, $timestamp = gmtime(1005613200) sets $timestamp to "Tue Nov 13 01:00:00 2001". There's no year 2000 problem here.

That doesn't mean that Perl can't be used to create non- Y2K compliant programs. It can. But so can your pencil. It's the fault of the user, not the language. At the risk of inflaming the NRA: ``Perl doesn't break Y2K, people do.'' See http://language.perl.com/news/y2k.html for a longer exposition.

If you want perl to warn you when it sees a program which catenates a number with the string "19" -- a common indication of a year 2000 problem -- build perl using the Configure option "-Accflags=-DPERL_Y2KWARN". (See the file INSTALL for more information about building perl.)

We've known about this in C for about twenty years or so. So, let's not pretend you haven't been notified, ok?

Were you correctly insulted?

[tilly]

Let me see.

The localtime() documentation has been part of Perl for years. You will find it repeated in books, Perl's Y2K statement, etc. If you read the documentation rather than use the "try and guess" approach you would have known what that function returned.

As the saying goes, Assume means "Make an Ass of U and Me."

And so, after not reading Perl's documentation, not reading Y2K statements, not testing your own code (despite hearing "Y2K" being chanted for months), you do not think that the existing problem was your fault?

Furthermore if you read the documentation, those Y2K statements, etc, you will find out that the decision was made not in the design of Perl, but in the design of C. Perl chose to imitate what C did a good 10 years ago, and C chose the format for that struct over 20 years ago. Personally I think that a 4 digit year would have made more sense than year-1900. But year-1900 makes a lot more sense than a 2 digit year! (Do you like coding in windowing logic to guess the century? Me neither!)

Oh, and a pointed question. Those scripts that began returning 19100? How many of them would have returned 1900 if the year was returned as a 2 digit year like you asked? Oh really? And you have cause to complain???

Sincerely,
Ben Tilly

PS Your proposed "solution" is not even correct Perl code. I leave conclusions as to your competence to the reader.

Re:Crazy guy, crazy language

[Roundeye]

People seem to think that they have an inalienable right to sit down in front of a program written in a language with which they are vaguely familiar and begin hacking someone else's code - and bitch when the language is not trivial enough to do that. While I am all in favor of languages with simple syntax (C, Python), or languages for morons (VB comes to mind), when I choose to code a project in Perl I don't expect some Perl newbie to maintain my code later -- because I know Perl well and I use the advanced features of the language for their power. If you don't want to take the time to learn Perl then go program in any of the zillion other languages available; but don't claim to be "just another perl hacker" or expect to be able to maintain good Perl code.

Re:Legos kiddies and professional architects

[speek]

Hire x programmer to do x programming, and hire
y programmer to do y programming. That's your mantra? But it doesn't really make sense. Hire a good programmer is really what you want, don't you think? A good x programmer, will learn and create better y code than a bad y programmer.

The question really becomes, what languages are good programmers most likely to _want_ to program in?

Re:Legos kiddies and professional architects

[Tom Christiansen]

Very well, Jordan. I'll answer those particular points. I trust you will be content with my doing this rather than laboriously addressing your own points, since they seemed to be mostly about my not having answered each and every issue that the original poster had raised.

I really do wish, however, that someone else would please write some lengthy and detailed perl apologia sometimes. Truly I do.

Perl code is a mess of obscure control characters which can change the meaning of the code significantly. More to the point, Perl will generally try to "guess" what you want to do even if you don't quite express it correctly (Tom Christiansen's words, not mine). This may initially sound like a good idea, but it makes finding bugs a nightmare.

The first point is with respect to small changes in punctuation (not "control characters") making a large difference in semantics. This is, of course, completely true, and I saw no reason to dispute it. However, it is likewise also true in nearly every language that comes to mind, whether programming or natural.

Consider the tremendous difference in choosing single or double quotes in a C string. Notice how quote choice makes a big difference in shell programming as well, and even more importantly, how this is not the same difference as C manifested! Notice how in C the presence or absence of an asterisk or an ampersand completely changes what happens, just as in Perl the presence of absence of a dollar sign or backslash (to choose corresponding construct) can have tremendous impact. Notice, too, how in C a spurious semicolon can completely change your world.

while (i++ < j);
b[i] = a[i];

And of course, positioning of that ++ matters a lot, too.

I could cite plenty of examples in English, too, such as:

• I dedicate this book to my parents, Mother Theresa and God.
• I dedicate this book to my parents, Mother Theresa, and God.

The place where Perl is particularly heavy on symbolic notation is in regular expressions. Modulo Icon, I don't know of any language or system currently in use that affords so much power. Regular expressions (ok, I know they're not truly regular by the proper language-theory definition) are an extremely compact but user-friendly interface to various sorts of FAs. Yes, of course interchanging, omitting, or deleting one single character completely changes the meaning, because each symbol carries a large amount of semantic content. This is equally true of any other language that uses regular expressions, whether it be from libc or in any other programming language. Consider how differently a circumflex can be interpreted in a call to regcomp(3) depending on whether it is the first thing in the string or not, as well as whether it's the first thing after the opening square bracket of a character class. It's subtle. You do have to be careful. Such is the nature of the beast. Then again, I haven't seen a Calculus book that eschewed symbolic notation, either, and I'm not certainly I'd care to.

Let's consider the "do what I mean" effect. If you'd like another quote of mine on this matter which is also somewhat mixed in its connotation, then consider: " `Do what I mean' is really just `do what Larry means', and if you and Larry don't mean the same thing, then you may be in trouble." :-)

I guess the bottom line here is Perl's context-dependent behaviours. I have mixed feelings about this whole issue, and could probably work up a fairly substantial jeremiad in either direction. I'm talking about the fact that things like these two:

@files = `ls`;
$files = `ls`;

The first, being in "list context" by merit of being on the RHS of an array assignment, actually ends up being

@files = split(/(?<=\n)/, `ls`);

It seems pretty obvious that it's more fun to write it without that ugly split. A reasonable alternate approach would be the creation of two separately named functions to do this job. But that's not what happened.

Of course, it's not as though C were free of issues of context dependence. Consider how the comma operator acts in "list context", such as when you construct an actual or formal parameter list to a function or when you create an aggregate data initialization, compared with the normal, "scalar context" comma operator. Or consider how sometimes c[] and *c are equivalent (parameter declarations), and how sometimes they are not (extern declarations). And for a real fun time, just try to explain to a neophyte why argv[0][0] is doing run-time pointer arithmetic (assuming the conventional declaration), but that data[i][j] would not be given a declaration like char data[MAX_X][MAX_Y] to create a proper two-dimensional array.

C has plenty of other "do what I mean" issues. For example:

• Letting multiplication bind more tightly than addition -- a secret, implicit rule
• Permitting but not requiring a trailing comma on aggregate data declarations
• Allowing int to be omitted in declarations involving extern, static, auto, unsigned, and volatile.
• Defaulting functions to have a return type of int.
• Assuming that for(;;) should mean while(1).
• Sign extension on some architectures.
• Freely coercing integral types

I imagine there are more of those, too, that I could come up with if I had. In fact, I'm quite sure that I could list a bunch of "do what I mean" issues for Python if necessary. Certainly the significance of whitespace and indentation is one glaring case. Another is the default nature of many libraries to raise an exception upon error, rather than returning an error status, even when that exception is, as K&P put it in Java's case, far from exceptional.

So I didn't address these issues because I felt that they were largely true, but not particularly relevant. All symbolic encoding systems are subject to semantic shifts due to small changes in symbols. And many of them attempt to "do what you mean". Does Perl share these properties? Of course it does.

Finally, Jordan, you've stated that you feel that Perl lacks attributes of a programming language that lends itself to high maintainability. I don't know whether this is fair or not, because I do not know what your metric is. If you're looking for me to play the devil's advocate, I could point out things like

• minimal static analysis
• extremely late binding
• libertine autoextension of memory
• free, dynamic conversion between intrinsic types
• default mode is for fast-and-loose programming, not careful architecture with elaborate pre-declarations

However, our advocate's adversary would be quick to illustrate how easily these can be construed to be not bugs but features given the appropriate target environment. In this respect, you've probably hit the nail on the head when you mentioned trade-offs.

But you haven't enumerated your criteria, so it's hard to judge what you're thinking.

Anyone can write bad code in any language

[Ted V]

Anyone can write bad code in any language. It takes good programmers to write good code. But it also takes a good language, and perl is one such language.

The problem with many languages such as LISP is that it's so _difficult_ to write good code! Perl is such a gem because it tries very hard to make your life easy. Of course, some people still do things the wrong way. It's not an issue of the language. It's a problem with the programmer.

Although I do admit that Python is an equally good language.

-Ted

Possible /. interview?

[NullGrey]

Hey, Hemos & Taco, can we get Mr. Wall for a /. interview? He would be most entertaining.

Legos kiddies and professional architects

[Tom Christiansen]

Perl sucks. I will admit that if you know Perl well, then yes, you can write powerful programs quickly within particular domains (notibly cgi scripting), some might even enjoy this. However, if you have ever tried to maintain a perl program, particularly someone else's, then believe me, the fun drains right out of the experience. Perl code is a mess of obscure control characters which can change the meaning of the code significantly.

Anything that says "X sucks" stands a good change of being downscored, and probably deserves it, too. Please endeavour to express whatever sentiments lie behind that outburst using substantiating reasoning rather than emotive expletives.

Perl is not a rebellion against `good design'. In many senses, it is an expression of the same, where good design means something organic and adaptive, something tuned more to the wait people think than to the way computers operate. It is a kind of design which has proven itself time and again over the last several thousand -- if not in fact, billion -- years.

As for the common refrain, "I can't maintain other people's code!", this is just another bit of popular Perl FUD. Eschew such nonsense. The underlying inability may reflect on you. It may reflect on them. But it does not reflect on Perl.

What you hate is when the code to be maintained was written by an unskilled laborer, someone who doesn't understand the tenets of software design. It would be hell maintaining that code no matter what language it was written in. Another scenario for hating life is when the original coder was competent, but the person doing the maintenance is completely clueless. Here my plea:

STOP HIRING VISUAL BASIC WEENIES TO MAINTAIN PERL CODE!.

You don't hire them for maintenance of C++ libraries, so stop hiring script kiddies (I mean nonprogrammers who can only cut and paste others' scripts) to maintain Perl. This is your fault for hiring the wrong people for the job.

I've had the pleasurable experience of maintaining a great deal of Perl code that was designed and implemented by competent, professional programmers. You cannot compare the work of the Legos kiddie with that of the professional architect. It's insulting to all three parties.

One last bit: don't denigrate the accidental programmers who've had Perl thrust upon them, or who have turned to it from a starting point of zero knowledge. They're doing the best that they can, given the circumstances, and should be encouraged, not squelched. Most programming is performed folks not trained in formal software engineering. You should compliment them for how much they were able to accomplish, not diss them for not knowing the precepts and subtleties of good design. Perl succeeds because it is available not just for professionals, but for casual programmers as well.