Why Corporates Hate Perl 963
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."
Ockham's Razor tells me.... (Score:5, Interesting)
... that it's because it's too complex for them. There's no pointy-clicky visual perl, and absolutely no correlation between code size and complexity. So they can neither hire a $35k/year H1Ber to do it, nor count lines of codes to measure complexity.
Oh, and without taking special measures, others get to see the code. Including sysadmins, who may laugh at the stupidity of the $35k programmers. Which doesn't make management look good.
Perl is the enfant terrible of the programming world. A very smart one, but requiring the same smartness of its users.
Perl IS the problem (Score:4, Interesting)
Particularly perl, even with coding standards, reasonable indentation, comments etc.
I stopped writing the stuff years ago because I realised that I was only making things worse. Perl encourages big ball of mud [laputan.org] development. It's specifically designed as a "glue" language which lets you stick things together, in fact it's a sticking plaster language which allows you to paper over cracks which would be far better filled in another way.
Now if I see myself or others considering Perl to accomplish something, I'm pretty sure there's a problem with the entire approach.
heyho, python - the new perl. (Score:4, Interesting)
of course, many people will prefer to use perl because of its larger amount of add-ons and clever tricks.
at work I use PHP a lot for many of my simulations and quick fixes, its really good for processing 2M line data files (try doing that with excel). I know its not what it was originally designed for, but it works for me.
look on the bright side, perl will no longer be learnt by many people and in a few years legacy "perl coders" can command higher wages to work on "legacy system" - much like COBOL programmer do now (though there are less of them every year).
I think this is the way it will always be, there will always be a simpler language to replace the old standards, and a new shiny technology that those who have managerial power but less technical knowledge can mandate from on high.
so, what happened to java? I liked it, it never went away but seems to hover on the edge.
Flon's Law (Score:1, Interesting)
There is not now, and never will be, a language in which it is the least bit difficult to write bad programs.
Why not Python? (Score:5, Interesting)
At the risk of starting a programming language holy war, can someone explain to me why someone would choose to start a new project in Perl instead of Python? From what I've seen, they both do essentially the same things in the same ways, and they're both (roughly) the same as far as language overhead (from language interpretation) is concerned. But from a readability perspective, there's no question that Python is miles ahead. (Perl's readability, or lack thereof, is literally [bbspot.com] the source of jokes) In the long run, this translates into lower total development budgets, which is something businesses like to hear. So, why would anyone choose Perl over Python?
Re:Age (Score:5, Interesting)
I would also dispute the idea that the simplicity of newer code is necessarily a good thing. Maybe they are yet to find all the bugs that require inelegant solutions...
That could of course be the case.
But it is a fact that some programmers have slightly too much interest in "clever" tricks, compactness, and optimisations whether they're called for or not, and too little in clarity, modularity and maintainability.
I won't claim this as fact, but I also strongly suspect that this kind of programmer also tends to love perl (you find them everywhere though). Many lose these traits as they mature, get to experience the pain and cost of working other people's unreadable code, and as you get more proficient you simply aren't that impressed by low-level coding skills any more. But some seem incurable.
Perl too readable (Score:5, Interesting)
People keep telling me that Perl is less readable than other languages, but i disagree. It's only less readable when you dont know the language specific semantics used - surely everyone remembers when they saw floor((float)i + 0.5) in C for the first time? It's no different to a perl programmer who uses @array = map { s/something/better/g } @data;
While I must admit that if you code in perl like a one-liner guru, you're not going to make particularly managable code but not coding in perl has significient RAD drawbacks. In Perl I worry about one thing: variable tainting. In C and C++ I have to worry about tainted variables, constant index-off-by-one errors, the possibility of null pointers and null reference handling, libraries and linking.
Some Perl programmers could do with more non perl experience to make their style managable. Perl 5 oop is a joke, and perl 6 is trollbait - but these aren't reasons why programmers shouldn't apply wider programming skills as a C/Jaava programmer uses their ADT knowledge and skill between langages.
Matt
Re:heyho, python - the new perl. (Score:3, Interesting)
python seems to be the new perl
There's one big diifference, however: python is a well-designed, highly structured language. Perl sort of grew organically from a couple of scripting languages, and had OO pasted on later.
Perl is probably brilliant for simple scripts, but should not be used for large programs. Python is very useful for large programs, however.
so, what happened to java? I liked it, it never went away but seems to hover on the edge.
On the edge of what? Java is the biggest programming language in the world today. It dominates the web and mobile phones, and although it's not quite as popular for desktop programs, it's not uncommon there either.
It's not a scripting language like Perl, however, so if your world looks like Perl, you may not notice Java that much.
Re:Ockham's Razor tells me.... (Score:5, Interesting)
I suspect they merely have associated "Perl" with "bad" because the existing cruft happens to be in Perl. Because there are very few managers who understand the difference between programming languages.
Besides, you can create an unholy mess in any programming language.
Writing bad code (Score:5, Interesting)
As many others have pointed out, you can write bad code in any language. Perl makes it very easy to write terrible code, just as Perl makes it very easy to write just about anything else. There are other languages that place obstacles between you and the bad code you're trying to write - for example, Python won't let you not indent correctly, and Java won't let you not use OOP.
When coding large applications, it is critical that certain coding standards are followed. Everybody has to play by the rules, and do things in a standardized way. Perl doesn't impose any of these rules for you automatically. If you choose not to self-impose any rules, your code will wind up being an unmaintainable mess. But no language can save you from that - if you write terrible code in Python, it's guaranteed to be nicely indented, but that doesn't mean it'll be maintainable. And, if you want to self-impose some rules to help keep your code clean, Perl Best Practices [google.com] will point you in the right direction.
I highly recommend The Daily WTF? [thedailywtf.com]. Perl does NOT get a disproportionally large representation there.
It's possible to write rubbish in any language (Score:5, Interesting)
Or, to put it another way, correlation is not causation.
Perl has been around long enough (and, more to the point, was pretty much the only choice if you wanted a half-decent scripting language 10 years ago) that there's a strong chance in any business that badly-designed hard to maintain systems that have been around for 10 years or more include a fair chunk of Perl.
That's not because of Perl, that's because they were badly done in the first place. I'm willing to bet that there's just as much code which is written in Perl and does a perfectly good job but nobody really knows about it because it's been sitting in the background doing a perfectly good job for so long.
Re:It's possible to write rubbish in any language (Score:3, Interesting)
Until someone finds out it's written in perl, and launches a project to get it ported.
In a company I worked for, that happened. A small perl script scanned all the web server logs, removed internal accesses, and presented a list of the most common search terms, ordered by soundex (to catch and list common misspellings).
This worked surprisingly well, providing a service that the search engine didn't. For years.
Until someone found out it was a (hiss! spit!) perl script, and decided that it needed to be rewritten as a managed java application, supported by the search vendor.
Of course, the result cost about as much as a small house, needed its own server, log transfers took several hours a day, and hours of manual intervention whenever (daily) a transfer failed (like if a file was larger than 2 GB or the passwords had expired), and it could not correlate results by soundex.
This was called a success.
The lack of functionality in the new replacement app was blamed on, I kid you not, perl, for being inherently difficult to port to java.
C++0x (Score:4, Interesting)
One thing that really disappoints me about C++ is the direction that it's been heading for the past 5 or 6 years - "template programming". In fact it's about as bad as perl in terms of readability and maintainability, but much worse for debuggability. I can't think of any programming "language" worse than C++ template programming. I stay away from Boost and really hate what it's doing to C++.
I respectfully disagree. The direction C++ is heading, with C++0x, is awesome. With the next standard, error messages from compilation of templated code will become comprehensible, thanks to concepts. This will mean using complex stl classes will be as easy as using java generics. Of course, designing the STL will still be hard, but I for one do not have to do that.
Also C++ will become viable for functional programming (which is possible but horrible nowadays) thanks to lambdas and closures.
Re:Ockham's Razor tells me.... (Score:5, Interesting)
Re:Ockham's Razor tells me.... (Score:5, Interesting)
to me the biggest issue is maintainability, some languages help you in that department, some hinder.
Perl makes it easier than even C to write obfuscated bits of code that even the author has a hard time understanding a few months later.
I've seen perl used to create job security for it's coders, in that respect it is the new assembly language.
Re:Ockham's Razor tells me.... (Score:3, Interesting)
Of course it's a bad one. So why does it get used?
Because it's easy to implement and it produces a number. Numbers are great because managers can do barcharts and statistics and stuff like that to stick on the wall and go "blah blah KPI blah blah" in meetings.
And re the GP about doing negative lines - yup, been there (we didn't use LoC formally, but I was questioned on why the programs were getting so much shorter). Is taking out the shit that some imbecile had copy/pasted a few hundred times and putting it in subroutines counted as refactoring?
Re:overpriced and overhyped (Score:4, Interesting)
Sometimes it is a matter of not being able to deliver due to lack of architecture. Read, the side effects in the non-architectured spaghetti code finally reached the point of overwhelming the programmers.
If you managed to avoid this situation with sufficient foresight, it is not always obvious. After all, maybe a simpler system would have done the job too?
Besides, the point of not being able to deliver due to lack of architecture usually comes later in the lifecycle, and the first versions may be quite successful. So in some cases, the badly designed terrible little programs win by being first and becoming the "industry standard".
Now the obligatory dig at Microsoft... ;-)
As far as I can tell from the user perspective, Windows seems to fall in this category. For the second time:
-First time, Windows 9x was quite successful for a while but ended in disgrace with Windows Millennium. Fortunately for Microsoft, they had developed the much more solid Windows NT line in parallel, on which they then built Windows 2000 and XP.
-Now, it seems Microsoft has managed to overextend its architecture again with Vista. This time I don't see a better product line in the background that could take over. Let's see what happens over the next five years
Re:Perl IS the problem (Score:5, Interesting)
There are two problems with this analysis. The first is that you (as many coders do) assume that tools that require intelligence on the part of the coder is an unalloyed good. Businesses, however, don't see it that way, especially large ones with many coders.
As Dave Clark once said in a different context, and architecture is partly there to tell you what you *can't* do. Programming languages are like that as well. Java is very good at encouraging certain idioms and discouraging others. Perl is not so good at either thing. Organizations that want structure will also want languages that support structure.
The answer "But its their fault for hiring dumb coders!" won't wash, because when you are the gas company working on maintaining a legacy billing system, you have to hire coders of average quality, and a language that allows coders of average quality to do stupid things is inferior to a language that shapes their work, *even if it slows them down*.
The second problem with this argument is fetishization of the individual coder, when most large codebases, esp in businesses, are social affairs. Even stipulating the impossibility that every business should hire only coders of above-average intelligence, different coders are intelligent in different ways. When 'Code as thou wilt' is the whole of the law, confusion abounds.
Did you ever see Rael Dornfest's bloxom blog project? Elegant, tight perl that did stuff like string replace on slashes in a fiel path to get an array of dir names, the file name itself, *and* kept the number of substitutions as a variable for traversal depth, in a single line. It was smart, but it also took other coders a long time to understand the JAPHishness of that single line of code, because it was doing three things at once.
Interestingly, he re-wrote it in Python, and its better, mainly because you can't do stuff like use the Boolean return of an assignment as a side-effect for an if test, and there's no concept of $_. Perl doesn't require JAPHishness and Python doesn't completely banish it, but other things being equal, Python produces more sociable code.
Once you start seeing the business imperative as enabling a group of acceptably competent programmers to work together, rather than being a platform for individual brilliance, the original article starts to look a lot more sensible.
Re:Perl too readable (Score:3, Interesting)
I can't think of any programming "language" worse than C++ template programming. I stay away from Boost and really hate what it's doing to C++.
Actually, templates provide a sense of "duck typing" familiar from Python and the likes, but with static linkage and native code performance.
Templates enable quite a lot of things that would look quite awkward without them, and perform terribly. Basically, you rarely need to create your own templated classes - they mostly reside on the "library" side of the application, so most of the time you are not really writing new templates, you are just instantiating them.
I have spent a lot of my programming career programming in C++ without templates (because the platform discouraged their use) - but now, when I'm working on a project that encourages the use of templates, it's a hoot.
Regarding the original topic - I thought everybody, not just the corporates, hate perl. Wake up and smell the python...
Perl in bioinformatics (Score:3, Interesting)
As someone who has both written and read _alot_ of perl, in particular in Bioperl and Ensembl, in bioinformatics I have a rather love/hate relationship with Perl.
I love: the low learning curve for people coming from biology, with alot of forgiving behaviour (in particular I think the auto-creation of datastructures as you use notation to fill in complex anonymous - think pointer based - structures). This is probably the critical one which means we can hire a much broader group of people with a much better understanding of biology and for them to be productive far earlier
I love: the large and robust libraries accessing nearly every sort of database, web-app and other things you need
I love: the consistency of behaviour between systems (don't get me started on Java or porting C++ code between compilers/library systems. Ugh! unbelievable pain as one starts using those languages and move between high end systems. Its C for the fast stuff and Perl for anything else for portability in my book).
I love/hate: The (huge) amount of robust existing Perl code that we have in Ensembl and that works day in, day out on multiple outings
I hate: The lack of clean objects. Why, oh why, oh why?
I hate: The inability to switch on strong typing and bigger checking optionally in libraries - I know you can do more these days, but it is still clunky.
I hate: switching the word "continue" (in C) to "next" (it gets me every time)
I hate: having to always brace if statements
I hate: operators designed for one-liners that gets in the way of good readable code - grep and map in complex lines are pet hate of mine.
I hate: the tortorous cross-language capabilities - compare python's jython and other C-level compilers. Soooo much better.
Interestingly I coded in python for about 6 months in the late 90s - very early on python - and lots python appeals to me. But then Perl came along, and lots of bioinformaticians were using it, and systems people were installing it by default on systems...
Roll on Parrot. I want Parrot to be able to run
Perl5 syntax code, Perl6 and Python/Java syntax
all together, with easy ways to load in C level or compiled down libraries. That's what Perl needs to save it.
Re:Sometimes the correct answer is the simplest (Score:3, Interesting)
I don't think so. It's much, much harder to write crappy code in Java than it is in Perl. Java enforces a lot of practices in its syntax that annoy the code hacker type but make the software much more maintainable down the road.
Re:Sometimes the correct answer is the simplest (Score:5, Interesting)
Look at this site: http://99-bottles-of-beer.net/ [99-bottles-of-beer.net]
This site make the song "99 bottles of beer" into a program that displays the lyrics of 99 bottles of beer. Now look at the Java implementation, it's a bloody mess! Waaaay to complex in order to maintain flexibility. Now look at the a comment where another person has done the same thing but then in a simple manner.
Yes, you can make any language look butt ugly if you try.
Re:Perl IS the problem (Score:5, Interesting)
I see this claim all the time - "it's not Perl, it's that people write bad Perl."
Well then, why is bad Python a million times easier to read?
I also hear that Perl is great because you can write things quickly. This completely disregards the fact that you can write quickly in many other languages, that do not have the same "ball of mud" tendencies.
I also think that those Perl mantras: "laziness impatience and hubris" are not virtues and nor is having a thousand different ways to do things - this just leads to code that can only be read by one person.
Being methodical, aiming for clarity and simplicity, avoiding obscure functionality - this is what leads to code that can be maintained. Perl does not encourage any of these virtues.
Re:Age (Score:2, Interesting)
But it is a fact that some programmers have slightly too much interest in "clever" tricks, compactness, and optimisations whether they're called for or not, and too little in clarity, modularity and maintainability. I won't claim this as fact, but I also strongly suspect that this kind of programmer also tends to love perl
As you say, there's no way of proving this as a fact. But even if it is true that a lot of Perl programmers like "clever" tricks, it's irrelevant.
The way to avoid these things ending up in your code base is not to choose a language you think is less likely to have "clever" coders, but to put in place a good set of development practices, and ensure you have a decent ratio of "tech leads" (or whoever it is responsible for ensuring the standards are kept up) to other coders.
There are two main problems with a lot of the legacy systems in Perl. Firstly, when they were written (late 90s), it was the Internet boom, and everyone was a start-up, at least in the Internet field (even if they were an established company already). Secondly, a lot of the development practices that are mandatory today (eg. TDD, Continuous Integration, even Source Control) were far from ubiquitous back then. And it's quite hard (and expensive) to retro-fit those standards to a code base.
Business people usually aren't interested in paying for that, because there's zero direct business value from it. Although this is something that's slowly starting to change as business realise how important technology is, and how hard it can be to get right.
I don't think it's really a language specific thing, it's just that a lot of this stuff was done in Perl in the late 90s, and altho you can write bad code in any language, without good practices, it can get bad really quickly in Perl.
Re:Perl IS the problem (Score:2, Interesting)
Perl is the center of so many big balls of mud because elegant Perl code tends to be both powerful and obtuse. Prototyping merely encourages the creation of more powerful code.
Most corporations are more concerned with getting a project out and working by deadline than whether good design was carried out or that non-critical bugs persistent. In short, if you know ahead of time that you're likely never going to go back and do a clean design, you should choose a language that at least encourages good design from the start if you want to minimize the mudball that will form; that means choosing a language other than Perl (or finding the few Perl programmers who follow good design).
Re:Ockham's Razor tells me.... (Score:5, Interesting)
One python coder here was scared because I was writing some tools in PERL that he was going to have to use and maintain. He complained PERL looked so terrible and was so horrible to follow that he wasn't sure he'd be able to do it.
Then he saw my code, and understood every line of it...
I'm like the anti-PERL PERL programmer (although I don't even use it myself anymore). He was absolutely right... when there was a more obscure way to do something, but it saved two characters of code, the PERL programmer would do it. My code was pretty verbose and easy to read.
If I was passing those scripts off to other PERL programmers, they'd have mocked my style.
Re:To be fair to the corporates (Score:3, Interesting)
C++ is still around for a reason. There are whole classes of problems that simply cannot be solved using the higher level languages you're used to.
Anyone that's ever used C++ for more than the required chapter in school would probably agree that it's not a language for dabblers.
That is, if you want to get GOOD at C++, you need to use it regularly. You need to get GOOD at it. When you do, you learn how to avoid the most painful/tedious parts. You have easily accessible things in your toolbox, like a solid string class that you understand well.
And you learn to avoid things like MFC where they're not needed.
And more than anything, a good C++ developer knows that his language can do anything, and faster, than a higher level language. Device drivers. OS Kernels. Things like that.
I'm no longer a FT C++ dev, but I did it for a long time. The ability to create and boot your very own OS is so, so worth the investment you make in the language.
I'd never create a CRUD app in C++ because I can't see any reason I'd need to. But I could if I wanted to. And that's something that, say, a Ruby or PHP developer couldn't say (That they could build ANYTHING they wantetd to).
And, really, if you think PHP is a "nasty hack" then you seem to me to be trading only in cliches here.
I'm not a huge fan of PHP, but it's a modern language. It's library is ugly. It lacks naming conventions. But its actual code-base is really quite good. If you want to see some well done C++ code, check out the PHP internals. It's made a lot of progress in the last 5-7 years.
Re:Ockham's Razor tells me.... (Score:3, Interesting)
"And when I grow up, I hope to program in java."
i was agreeing with you till that comment.. now i want to shoot you... (not becuase i dislike you - but rather to save you from your self)
Re:Sometimes the correct answer is the simplest (Score:3, Interesting)
Flexibility in a language is good. Too much flexibility is a problem. You only need to know one way to do a set of tasks in Perl to write an effective program. I only need to know one way to do a set of tasks in Perl to write an effective program. He only needs to know one way to do a set of tasks in Perl to write an effective program.
But you, he, and I need to know multiple ways to do sets of tasks in Perl to read, fix, and extend each others' code.
Now, I agree that Perl's biggest problem is really just the marketing war. But this too-much-flexibility problem also exists. I understand Perl6 addresses that somewhat, but I haven't heard whether any of the compilers has a final release yet.
Re:Ockham's Razor tells me.... (Score:4, Interesting)
This has been said ad nauseum: There's nothing inherent about perl that makes its programs unmaintainable or broken. It's all about getting programmers who know how to write maintainable, well-designed code. A bad programmer can make an abortion of any programming language or fancy pointy clicky system.
That was my response to this article as well.
They're chasing trends instead of paying attention to the quality of programmers they're using, because smart programmers are not interchangeable parts. They prefer cogs.
Management isn't all as screwed up as this. Some managers prefer highly intelligent staff that can work semi-autonomously.
Re:You are correct sir (Score:3, Interesting)
Perl has no mainstream, normal, people yelling and screaming for it. There's just the older, gruffer programmers and, more likely, sysadmins.
Yeah, the same sorts of idiots who still use UNIX, Emacs, C and Usenet (with that whole snipping and bottom-posting weirdness). Some of them probably even grok Lisp and wasted their time learning prehistoric nonsense like assembly language. Don't even get them started on documentation, or designing code before writing it; if you even mention unit tests, they'll just mumble something about understanding how code works before changing it. What have people like that ever done for the world, anyway?
You know, one day it would be really funny if these dinosaurs decided to take a sabbatical for a couple of months, all at the same time, and let the younger generation and their high-tech advances run the show for a while. Then management would see how much more effective you can be with a 3D GUI in your OS, a visual IDE, web application frameworks and wikis!
MOD UP (Score:3, Interesting)
He only forgot the part about how when the bridge is halfway built, they come back and say:
"We need the bridge to be at a different location on the river (enen though we didn't specify one in the first place)."
OR
"We see you're building a suspension bridge - we need it to be an arch bridge."
"Oh, and by the way, your materials budget and deadline haven't changed."
Re:Ockham's Razor tells me.... (Score:2, Interesting)
At my last job, I wrote a perfectly good perl loader...
during my entire working life managers have been trying to replace "coders" with tools that don't need a skilled operator (just point and click!)
they (mgmt) probably were more interested in getting rid of their dependency on you (or someone like you) rather than just Perl
and i don't know if they're right or not. do companies with super-skilled cadres of developers always win out over competitors with retrained VB code monkeys?
often i hear about companies being taken over (i.e. they "lost") and the IT staff cannot believe how messed up the parent's IT infrastructure is
Re:Perl IS the problem (Score:2, Interesting)
Well then, why is bad Python a million times easier to read?
You won't get hit by a car if you're chained to your kitchen.
And while impossibility of being hit by a car is a good thing, having chains around your leg gets troublesome.
I have seen spaghetti code written in Python (10.000+ lines, jumping back and forth between files). I wonder if you would say it is maintainable?
I also hear that Perl is great because you can write things quickly
Just to illustrate the example:
I rewrote small script written previously in Python to Perl. Around 130 lines of code (mostly CLI) turned into 20 lines of code while preserving readability, 100% of functionality and even adding some of its own, just because of "perl magic". And that's the prototyping speed I want!
Visual cues (Score:4, Interesting)
I think if I show someone perl code, and then show them python code, they're going to feel a lot more comfortable with python. Perl's $, %, and @ variable prefixes, file i/o weirdness (print $_) and other way-too-shorthands are seriously intimidating and foreign looking as compared to python. Python's regular, sensible indentation makes an impression of regularity and comprehensibility as well. Python's just a cleaner technology by nature. You can make Perl look pretty good, but you have to work at it.
I know I'm a lot more comfortable with Python, and I wrote in Perl for many years. Basically until I discovered Python, then that was the end of Perl for me. :)
Just a thought.
Re:Perl IS the problem (Score:3, Interesting)
I disagree. Languages don't encourage bad code (well, maybe Intercal, Malbolge, etc). They just don't enforce good coding practices.
There are problems with enforcing good coding practices, too, though. One that there are so many from which to choose that are good in different ways. You could just pick one, as Guido did, but then that makes other ones harder to use or less clear.
Vertical whitespace often makes things easier to read than horizontal whitespace does, but the majority of the time horizontal whitespace wins. Objects can really help clarity and modularity, but they get in the way when a small procedural program makes more sense. Some programs make more sense in a functional style with recursion while many recursive solutions can be made clearer and faster with iteration and a few side effects.
The difficulty people have with Perl is not that it encourages bad coding. It's that puts the responsibility for choosing a decent style and model on the programming team. If you're not ready to make those decisions, you can use Perl::Critic and PerlTidy or you can use a language that makes those decisions for you.
Just be aware that whether you make coding standard decisions consciously or by defaulting to some language designer with a particular taste, you're going to have pros and cons to your coding standards. It is an advantage in some ways, I suppose, that you end up with the same standards as your competitor down the street. It's also an advantage if you come up with one that allows your coders to be more productive than his.
Perl Stagnated (aka Duke Nukem Perl 6 Forever) (Score:3, Interesting)
I think Perl blew it by the inordinate amount of time Perl 6 is taking. I am surprised nobody mentions this. Pythona and Ruby on the other hand have good roadmaps (especially Python). They make releases like clockwork, they're always in the news about new frameworks and some cool stuff. Perl usually is in the news for the wrong reasons, mainly about why Perl 6 is so delayed. Perl has simply lost mindshare. Oh, I know Perl has not really stagnated. Perl 5.x series has been making steady progress but that only appeals to people who're already using Perl. For newer people taking up a scripting language, Perl seems like it's past it's prime. Besides, let's admit it - the language is arcane; especially the OO stuff in Perl 5. I even find OO interfaces in perl modules unintuitive. If someone likes Perl and wants something more "clean", modern and shiny, I'd recommend Ruby though I personally prefer Python.
Don't mistake me. I was (and still am) a big fan of Perl - mainly Perl 4 though. It's one of the most powerful languages that I've used. Even today, I usually start writing something in shell (because I am throwing together a bunch of programs to get my job done). Then I hit the limitations in shell and usually port the program to perl. That said, I have mostly switched to Python, especially when I am starting to write something from scratch.
Re:Why the python tag? (Score:3, Interesting)
Most of the comments here smell like fanboyism, both from the perl camp and the other camps. I like the way articles like this always get 500+ comments in no time eventually ending in language du jour-camp claiming to have a better language with awesome syntax, language of old-camp claiming they can rapidly do things (it's called experience, btw), language-of-non-related-camp chiming in on having better OO-support, and language-of-years-of-training-in-acronyms-camp loudly proclaiming to be dominating the market in acronym.
Language wars aren't productive. I spent a year in an office with two guys that loved flaming eachother over their favourite language. 3 years later both of them have chosen other languages to go all zaelot about, and I'm so incredibly happy not to have to listen to it all day long.
But for completeness, I used to use perl a lot in my previous job, mostly for CGIs and quickly hacking together something I'd rather not do in bash. These days I spend a lot of time in java and C++, with every now and then a dash of python. I like to think that each programming language comes with its own mindset, idioms (and idiots) and each has their own advantages and disadvantages. I still use perl for small personal projects or quickly parsing a 200MB textfile and formatting it to another kind of textfile, simply because I can use it to things quickly or because it only needs to be done once.
Perl may have the elegant look of an infuriated elephant ramming a jeep (depending on the sloppiness of the programmer), but it's helped me do things on so many occasions in a matter of minutes that would take a lot longer in another language that I occasionally grab back to it. I still prefer it over bash for something more complicated than piping a couple of programs, and that will probably not change until it's no longer included in the operating system I will be using then.
As for all the regex hate on slashdot... I don't really get that. They're incredibly handy for parsing text quickly, but like with all things: if you take it too far you're just asking for trouble. I actually saw someone hack together an XML parser in 3 very complicated regexes, while thinking "That's impressive, but probably a very bad idea". A few days later I saw him throw a hissyfit over XML namespaces and thought "That was a bad idea".
Re:Ockham's Razor tells me.... (Score:2, Interesting)
my PERL code looks like Pascal: descriptive variable names; breaking evaluations and operations into intermediate steps; king-pinning functions. For example, I name the iterating variables in "for" loops 'counter', not 'i'
Some Delphi programmers think I'm too descriptive.
Perl is hated because it begets a putrid mess! (Score:2, Interesting)
Have you actually seen the Perl syntax? It's a horrifying mess designed for people who like twisted grammar puzzles and cryptic codes (and cyptics like RMS who think that recursive acronyms are cool). To express anything clearly in Perl requires a frontal lobotomy and a C-section at the same time (yeah, even if you're male).
It's such a freakish language that it's got syntax for syntax rather than a very clear simple syntactic idea like LISP or Smalltalk or Self or, fuck, even C is easier to comprehend than Perl.
There's an article over here that covers some points why Perl sucks the big one and doesn't even suck well at it! When a language sucks at least I want a good blow job!
http://smalltalk.org/articles/article_20040914_a1.html [smalltalk.org]
Basically Perl sucks because you need this to figure it out:
http://www.ozonehouse.com/mark/blog/code/PeriodicTable.pdf [ozonehouse.com]
Professional systems people want their systems to be clear and as easy to grasp as possible, Perl provides the opposite. We ONLY use it when the existing system is using it, and then we only do maintenance bug fixes (lots of those) and do not under any circumstances add new features to programs written in it!
The above are a few reasons that Perl is ostracized from the corporate space and should be excised from your brain.
If you want to hack your way through life, fine, be cryptic and use Perl. If you want excellent systems that perform and get results use a language that helps in that regard: Smalltalk, Lisp, C. Avoid Java, C++. Heck use Assembly Language before Perl!
Re:Why Corp. hate Perl? (Score:3, Interesting)
Perl is dying because Perl 6 is taking as long as "Duke Nukem Forever" to be released.
There are more choices in scripting languages now than there were back when Perl 5 came out: PHP, python, Ruby, ...