Why Corporates Hate Perl

Anti-Globalism recommends a posting up at O'Reilly's ONLamp on reasons that some companies are turning away from Perl. "[In one company] [m]anagement have started to refer to Perl-based systems as 'legacy' and to generally disparage it. This attitude has seeped through to non-technical business users who have started to worry if developers mention a system that is written in Perl. Business users, of course, don't want nasty old, broken Perl code. They want the shiny new technologies. I don't deny at all that this company (like many others) has a large amount of badly written and hard-to-maintain Perl code. But I maintain that this isn't directly due to the code being written in Perl. Its because the Perl code has developed piecemeal over the last ten or so years in an environment where there was no design authority.. Many of these systems date back to this company's first steps onto the Internet and were made by separate departments who had no interaction with each other. Its not really a surprise that the systems don't interact well and a lot of the code is hard to maintain."

Sometimes the correct answer is the simplest

[tanveer1979]

If we forget the conspiracy theories for a while, there are other reasons too.
A 100K/year good programmer can also have difficulties understanding perl code.

If you look at the most efficient perl code, it will be very small, and do a lot. But it will also mean that nobody else can understand the code

Heck I have difficulty in understanding a couple own scripts if I look at them after a year, and that too when I add comments.

Perl is a very very powerful language. A small change can make the code do something completely different, hence the fear.

For example look at this
        s!(?:^|\w*/|\.\./|\./)[^\s,@;:]*(?<=/)([^\s,@;:]+?)(?=[\s,@;:]|$)!$1!g;

Interesting?
Thats a one line regexp which does something which appears to be very very simple to do, but actually isnt.

Re:dynamic Lang

[fishbowl]

I worked in a shop that replaced a really complicated process that had been written in COBOL, with
a really efficient, compact, regex-based, DBI-enabled perl program. I'll let you explain to them
why that's inappropriate for their enterprise scope... :-)

Re:Ockham's Razor tells me....

[chthon]

Yes! Book recommendations for Perl programmers, outside of the standard ones you need :

• Perl Best Practices, by Damian Conway. This one is really mandatory.
• Higher-Order Perl, by Mark Jason Dominus, to understand why Perl is so powerful.
• How To Design Programs [htdp.org], which taught me better ways of using Perl, even though the book is based upon Scheme.
• Structure and Interpretation of Computer Programs [mit.edu], which is somewhat the bridge between HTDP and Higher-Order Perl.

All the rest I learned from the camel book. I use Perl on three platforms (Win32, Cygwin and Solaris), using the same libraries, and now also adding Perl/TK to the mix.

If you need to define several goals, I would recommend Perl Best Practices for writing maintainable and easy to read code and installing a peer review process.

HTDP is more for individual programmers, to become smarter and better programmers.

What's killing Perl...

[pjf]

...is backwards compatibility. In general, you can take some obscure piece of code that someone wrote almost a decade ago, and it will run on your modern Perl system. Unfortunately, people then take those obscure snippets of code, and try to learn from them. They may have been the best way to do things eight years ago, but they're certainly not now.

As such, one of the hardest problems with Perl is education of new techniques. Too many systems still use CGI.pm when they could use Catalyst [catalystframework.org]. They use some home-grown system of objects, when they could be using Moose [perl.org]. They put up with outdated techniques when Perl::Critic [perlcritic.com] would find them in a heartbeat.

So, if everyone learnt the new techniques, we'd be fine, right? Unfortunately, it's not that simple. I teach Perl for a job, it's still an incredibly popular language here in Australia [perltraining.com.au]. But because that old code still works, I still need to teach people how to understand it, even if I then proceed to teach them better ways so they can avoid it. That increases cognitive workload, and there's only so much one can fit into a fresh brain during its first contact with a language.

Perl still remains the language of choice for writing minesweeper bots [sweeperbot.org].

Re:heyho, python - the new perl.

[Fross]

Applets? This isn't 1998.

If you missed it, this thred is about corporates. All the big players - governments, big iron (ibm, etc), large enterprise developers (logica, capita, etc), military and most cutting-edge science development projects, use Java for Enterprise-grade applications.

Sure, the front-end desktop/browser embedded side is dominated by flash and ajax, with flex on the rise. But only small to medium development houses use much PHP and Python. Ruby is too new/too niche for now, and Perl *is* legacy, due to too few developers around, and no major new projects being written in it (Thank God).

Thanks for playing, try again sometime.

Why the python tag?

[PhilHibbs]

The article talks about PHP and Java as the alternatives that these companies are talking about, not python. Why is this tagged as "python" when it has nothing to do with the article? Why not tag it "c" or "ruby" "cobol"? Smells of fanboy to me, and that isn't a good smell.

Re:Sometimes the correct answer is the simplest

[jalefkowit]

The actual quote is this:

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

The source of the quote is Jamie Zawinski [jwz.org], who said it on Usenet in 1997 [regex.info].

Re:Age

[budgenator]

unreadable COBOL wow I could see incomprehensible but unreadable has to be some kind of a record for COBOL!

Re:Sometimes the correct answer is the simplest

[bytesex]

And even then, perl deals with regexes more elegantly than others, because they are an integral part of the language's syntax. In java, the GP's example would have to be enclosed inside a string, and be escaped.

Re:heyho, python - the new perl.

[Richard W.M. Jones]

There's one big diifference, however: python is a well-designed, highly structured language.

But still, dynamically typed so we get type errors at customer sites, slow, and memory hogging. (Also 'features' of Perl too). OO-paradigm, so clumsy to use. And the stupid whitespace thing means that patches get misapplied and it's very easy to accidentally misindent some existing code in the editor, not notice, then have the program do some totally different thing.

Perl is probably brilliant for simple scripts, but should not be used for large programs

That's complete nonsense. I personally have maintained 100,000-line Perl programs without problems. Divide the program up, factor out modules as libraries, do lots of testing and code reviews. It's really not that hard.

Rich.

No one's mentioned this old ESR article yet?

[sgtrock]

He describes quite succinctly why he moved away from Perl back around 2000:

...Writing these programs left me progressively less satisfied with Perl. Larger project size seemed to magnify some of Perl's annoyances into serious, continuing problems. The syntax that had seemed merely eccentric at a hundred lines began to seem like a nigh-impenetrable hedge of thorns at a thousand. "More than one way to do it" lent flavor and expressiveness at a small scale, but made it significantly harder to maintain consistent style across a wider code base. And many of the features that were later patched into Perl to address the complexity-control needs of bigger programs (objects, lexical scoping, "use strict", etc.) had a fragile, jerry-rigged feel about them.

These problems combined to make large volumes of Perl code seem unreasonably difficult to read and grasp as a whole after only a few days' absence. Also, I found I was spending more and more time wrestling with artifacts of the language rather than my application problems. And, most damning of all, the resulting code was ugly--this matters. Ugly programs are like ugly suspension bridges: they're much more liable to collapse than pretty ones, because the way humans (especially engineer-humans) perceive beauty is intimately related to our ability to process and understand complexity. A language that makes it hard to write elegant code makes it hard to write good code.

With a baseline of two dozen languages under my belt, I could detect all the telltale signs of a language design that had been pushed to the edge of its functional envelope. By mid-1997, I was thinking "there has to be a better way" and began casting about for a more elegant scripting language.

The rest of the essay can be found here [linuxjournal.com].

Re:Sometimes the correct answer is the simplest

[parnold]

How long would it take you to debug that problem?

About 12 seconds. Run Python with the -tt option and it will tell you about lines with inconsistent use of tabs and spaces.

I hope you're not doing that manually?

[Medievalist]

I use gawk (Gnu Awk [gnu.org]) for that job. It's the best tool I've found for rapidly re-writing hundreds of source code files on a running production system.

Arnold Robbins: "AWK is a language similar to PERL, only considerably more elegant."
Larry Wall, from audience: "Hey!"

find \corp\perl -type f -name \*.pl -exec fixbug.awk {} \;

Better be sure you know what you're doing before you press the button, though! I recommend building a cloned test environment.

Re:Sometimes the correct answer is the simplest

[Talderas]

use strict;

Re:Ockham's Razor tells me....

[Alpha830RulZ]

(and ENCOURAGES it with "implied" scalars)

Agreed. I resist using them, and won't let anyone on my team use them for code that gets installed at clients. Our client code looks like a well structured C program, as much as we can make it so.

That said, I like Perl for what we use it for, which is installation glue code, because it's generally easy for client staff to pick up. I like Python myself, but it's harder for marginal IT staff to pick up. Python and Ruby also tend to offend the client IT teams standards folks, who aren't quite sure about this new-fangled stuff. They'd prefer C# or Java, which are completely inappropriate for what we need to do.

Re:Sometimes the correct answer is the simplest

[slashgrim]

And that's why non-indented languages use http://en.wikipedia.org/wiki/Prettyprint [wikipedia.org] like http://www.gnu.org/software/indent/indent.html [gnu.org]

Re:Perl IS the problem

[Just Some Guy]

I have never once heard those listed as "Perl mantras"... where is this coming from?

"We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris." -- Larry Wall, Programming Perl (1st edition), O'Reilly And Associates

It neither encourages nor discourages.

He misspoke. Perl itself neither encourages nor discourages. Perl's community, however, is largely centered around those three exact things.

Re:Ockham's Razor tells me....

[nabsltd]

How do you measure whether you're on schedule to deliver the deliverable on time?

Simple. The "deliverable" is "Module Foo". The metrics to measure are:

• Module Foo: coding complete
• Module Foo: code review complete
• Module Foo: unit testing complete
• Module Foo: integration testing complete

When you defined any deliverable, you allocated resources (people and days) to each of the steps in creating the deliverable, based on the requirements. This is how you know what answer to give when the client asks "how long will it take and how much will it cost to add the 'Foo' capability to the project?"

• Foo coding: Joe & Bob, 10 days
• Foo code review: Fred (with Joe & Bob), 3 days
• Foo unit testing: Mary & Bill, 3 days (concurrent with code review)
• Foo integration testing; Mary, John & Max, 5 days

Although there are various ways of interpreting "on schedule", at least this lets you know that about 3 weeks from start, you should be damn near done with "Foo".

Re:Perl IS the problem

[mr_mischief]

You seem to be unfamiliar with the work of Damien Conway, Randal Schwartz, Tom Phoenix, and Lincoln Stein.

Stop by Perlmonks [perlmonks.org] to read some book reviews and maybe lurk the Seekers of Perl Wisdom or Meditations sections. You'll see that what you've been reading is not representative of how things actually get done.

There are Perl Poetry and Obfuscation sections on the Perlmonks site, but those are games. You'll notice that there's a clear division between neat tricks for the sake of neat tricks and maintainable code for the sake of maintainable code.

Re:Sometimes the correct answer is the simplest

[bar-agent]

So, the significant whitespace conveys the information formerly within { and }.

There's more to it than that. It's like Python has personal space. Whenever another tool, or even another conceptual model impinges on its personal space, it gets cranky. Three examples:

First, in complex software environments, you sometimes need to edit, elide, or change source code on the fly to support special software distributions. This is error-prone when you have to care about tabs and spaces.

Second, XML and HTML. They don't acknowledge differences between spaces and tabs, or even the existence of consecutive white space. You put Python code in one of those formats, and you are guaranteed to receive errors of some kind or another. If you've ever used the STAX testing framework, you'll know this pain.

Third, copy & paste. You can't use it reliably.

Re:Writing bad code

[Phroggy]

Pick one of the 5 methods, not all of them. Although I guess I'm ok with #5 since it is mimicking sh scripting behavior.

Funny, that's the first one I'd avoid.

You're right that there are at least five different ways to do this, but it should be fairly obvious which way makes the most sense in a given situation. For starters, since it looks like $debug is going to be a boolean value, you don't have to compare it to 1 or 0 at all, so that eliminates two of your options (the ones that compare to 0). Writing a conditional that doesn't look like a conditional is probably not a great idea, so we can scratch #5. That leaves is with only two options:

• if($debug) { print "foo\n"; }
• print "foo\n" if $debug;

So which of these is the best? Well, syntax #1 is designed for multi-line blocks, while syntax #2 only allows single statements. If you're only going to be using single statements this way, #2 might be best; if you're going to be putting multiple print lines in your conditional block, then it's probably best to use #1 every time, even when you use a single-line block (in which case you should probably NOT write the whole thing on one line like this example, but go ahead and put the print statement indented on the next line).

The other consideration is, syntax #1 puts the emphasis on the condition: if we're in debug mode then stop and take a break from the normal flow of our code so we can step off to the side and print "foo" before getting back to what we were doing. Syntax #2 puts the emphasis on the print statement (which may be mixed with several other print statements), with the conditional added as an afterthought.

Some coders will pick option #2 every time, simply because it requires typing slightly fewer characters. I've been guilty of this myself, but if the idea you're trying to express doesn't lend itself to that syntax, it's better not to use it.

Perl is about the expression of ideas in code. What's the best way to express your ideas? There are many different ways to express an idea when talking to someone, but with practice we learn how to choose the way that will help us communicate most clearly. Perl isn't much different.