Slashdot Mirror
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."
... 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.
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 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.
Deleted
python seems to be the new perl - ie. a general purpose, scripting glue language. its small number of keywords and simple layout make it easier for the less technical minded to learn quickly.
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.
There is not now, and never will be, a language in which it is the least bit difficult to write bad programs.
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 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?
To make laws that man cannot, and will not obey, serves to bring all law into contempt.
--E.C. Stanton
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.
sudo ergo sum
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
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 will point you in the right direction.
I highly recommend The Daily WTF?. Perl does NOT get a disproportionally large representation there.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
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.
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.
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
C - the footgun of programming languages
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.
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.
E pluribus unum
Look at this site: http://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.
Knowledge is power. Knowledge shared is power lost.
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.
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.
A major Perl moto is "There is more than one way to do it".
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.
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!
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
The parent post is genius.
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."
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
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.
I've fallen off your lawn, and I can't get up.
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.
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".
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
Basically Perl sucks because you need this to figure it out:
http://www.ozonehouse.com/mark/blog/code/PeriodicTable.pdf
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!
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, ...
I am anarch of all I survey.