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."

Comments

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: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, who said it on Usenet in 1997.

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.

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, which taught me better ways of using Perl, even though the book is based upon Scheme.
• Structure and Interpretation of Computer Programs, 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. They use some home-grown system of objects, when they could be using Moose. They put up with outdated techniques when Perl::Critic 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. 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.

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.

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.