Forgot your password?
typodupeerror
Perl Businesses Programming IT Technology

Why Corporates Hate Perl 963

Posted by kdawson
from the not-such-a-shiny-new-thing dept.
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."
This discussion has been archived. No new comments can be posted.

Why Corporates Hate Perl

Comments Filter:
  • by tanveer1979 (530624) on Wednesday August 20, 2008 @03:22AM (#24669963) Homepage Journal
    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 (Score:2, Informative)

    by fishbowl (7759) on Wednesday August 20, 2008 @04:15AM (#24670265)

    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... :-)

  • by chthon (580889) on Wednesday August 20, 2008 @04:28AM (#24670353) Homepage Journal

    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.

  • by pjf (184549) on Wednesday August 20, 2008 @04:57AM (#24670527) Homepage

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

  • by Fross (83754) on Wednesday August 20, 2008 @04:58AM (#24670533) Homepage

    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? (Score:3, Informative)

    by PhilHibbs (4537) <snarks@gmail.com> on Wednesday August 20, 2008 @05:44AM (#24670805) Homepage Journal

    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.

  • 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 (Score:3, Informative)

    by budgenator (254554) on Wednesday August 20, 2008 @06:42AM (#24671169) Journal

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

  • by bytesex (112972) on Wednesday August 20, 2008 @07:14AM (#24671369) Homepage

    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.

  • by Richard W.M. Jones (591125) <rich@anne[ ].org ['xia' in gap]> on Wednesday August 20, 2008 @07:24AM (#24671459) Homepage

    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.

  • by sgtrock (191182) on Wednesday August 20, 2008 @08:39AM (#24672551)

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

  • by parnold (119081) on Wednesday August 20, 2008 @08:57AM (#24672787)

    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.

  • by Medievalist (16032) on Wednesday August 20, 2008 @09:10AM (#24673037)

    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.

  • by Talderas (1212466) on Wednesday August 20, 2008 @09:16AM (#24673125)

    use strict;

  • by Alpha830RulZ (939527) on Wednesday August 20, 2008 @09:28AM (#24673325)

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

  • by slashgrim (1247284) on Wednesday August 20, 2008 @09:40AM (#24673569) Journal
    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]
  • by Just Some Guy (3352) <kirk+slashdot@strauser.com> on Wednesday August 20, 2008 @11:11AM (#24675493) Homepage Journal

    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.

  • by nabsltd (1313397) on Wednesday August 20, 2008 @11:47AM (#24676269)

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

  • by mr_mischief (456295) on Wednesday August 20, 2008 @12:19PM (#24676959) Journal

    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.

  • by bar-agent (698856) on Wednesday August 20, 2008 @07:21PM (#24683627)

    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 (Score:3, Informative)

    by Phroggy (441) <slashdot3NO@SPAMphroggy.com> on Wednesday August 20, 2008 @11:02PM (#24685375) Homepage

    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.

The biggest mistake you can make is to believe that you are working for someone else.

Working...