Slashdot Log In
Why Corporates Hate Perl
Posted by
kdawson
on Wed Aug 20, 2008 04:02 AM
from the not-such-a-shiny-new-thing dept.
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."
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
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.
Re:Ockham's Razor tells me.... (Score:5, Insightful)
What makes me laugh (and cry at times) is these same businesses, who insist that programmers and administrators are hard to come by, turn to ridiculous metrics like "how many lines of code do you write per day", and require x number of years of experience with technologies which just came out this year (and have yet to be proven.)
Let them have their H1-Bs, and the deadwood with the inflated resumes. Good riddance.
Parent
Re:Ockham's Razor tells me.... (Score:5, Insightful)
There may be some architecture and best practices you have to meet in carrying out your implementation which is what this article is about I suppose. Perhaps integrating with other systems forces you to use a particular tool or language. However, in general you can do whatever you want as long as you fulfill the user and business requirements.
That could mean perl but usually we think of that as being a fancy bash script with perhaps a bit of database interaction rather than a platform for writing server-side (or even client-side?) apps.
Parent
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.
Parent
Re:Sometimes the correct answer is the simplest (Score:5, Insightful)
Possibly not the best example of why perl is shunned.
Perl is simply not winning the marketing war.
Parent
Re:Sometimes the correct answer is the simplest (Score:5, Insightful)
Your regexp example isn't awfully good - any language that has regexp support will have lines like that. These days, PHP has regexp support (possibly always has), C has regexp support, C++ has it, Java has it, and I expect that even C# has regexp libraries.
The alternative to a regular expression is usually a very convoluted parser that's a lot of effort to support.
Parent
Re:Sometimes the correct answer is the simplest (Score:5, Insightful)
For example look at this s!(?:^|\w*/|\.\./|\./)[^\s,@;:]*(?<=/)([^\s,@;:]+?)(?=[\s,@;:]|$)!$1!g;
But this "Perl" code is really a regular expression which is also used in PCRE and PHP and so on. Copied because it was the best there was.
To improve readability of a regex use best practise and use /x (with whitespace and comments) and stop confusing Perl and regex.
Parent
It's the slashdot effect! (Score:5, Funny)
It's simple why businesses don't like Perl. Slashdot is written in Perl. Whenever a business is mentioned on slashdot, their website goes down. Ergo, Perl is bad for business.
To be fair to the corporates (Score:5, Insightful)
I see the same thing with developers in general. Nobody wants to use Perl anymore, PHP was the new thing, and now Ruby is eclipsing that. Now I'm not talking about cases where the new language legitimately makes something much easier, I'm talking about a good deal of fanboy-ish "Oh I do all my code in Ruby now because it's way better!"
It isn't just PHBs, programmers themselves seem to fall victim to fads in development. They want to use the new shiny stuff, simply because it is new and shiny. Hell I've seen developers say C/C++ are "dead" and that shiny_language_x is going to take over.
Re:To be fair to the corporates (Score:5, Insightful)
Hell I've seen developers say C/C++ are "dead" and that shiny_language_x is going to take over.
That may be not so much fadism as well-informed wishful thinking.
OK, plain C is not _that_ bad, but you do need to fight its innate spirit in order to implement sane coding practices.
But I recently had to return to C++ on a recent project, and although I was expecting some tedium, it was way worse that I remembered. MY GOD how painful it makes a lot of really trivial things. Even the nasty hack known as PHP starts looking well planned in this light.
It may be better than alernatives if you really need the performance and low-level capabilities, but if you don't (or only a small part of your project does), you're paying a huge price for wizard points you don't need.
Glitzy clicky interfaces do not a good product make, but a platform where _some_ thought has been given to workflow really is something we should start to expect in this day and age.
Parent
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:Why not Python? (Score:5, Insightful)
Very simple:
* the user has deep knowledge of perl but not of pythong
* the program needs certain libs that are easy available for perl but not for python
* the user is not very keen on the syntax of python
* there already exists a lot of perl code & libs that can be re-used and would need to be re-written to python
whenever you start something from scratch in a different language you have to see if it pays off. If you already have tons of libs & classes and knowledge in one language there is no need to write it in another again.
That's why I code my scripts still in perl, because I know what I am doing, I am fast, I get it done and I have classes that help me do the things I want to do. I see no reason why I should start again in python. I really don't have the time to re-do everything from scratch ...
Parent
Re:Why not Python? (Score:5, Funny)
Reason is simple.
Pearls are shiny and worth a lot.
Pythons are scary, they can bite, and have venom and stuff.
Rubies on the other hand are a viable replacement for pearl.
Parent
Why Corp. hate Perl? (Score:5, Insightful)
Hmm let me think:
- Few Perl Developers
- Difficult (or impossible) to maintain
- There are better alternatives
- Easy to write badly difficult to write well (e.g. Language doesn't lend its self to good practices)
Perl is a dying language and frankly it is easy to see why. The real question is what does Perl do better than the competition other than being older than my Dad and having a bunch of essentially pointless libraries?
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:Perl too readable (Score:5, Insightful)
I respectfully disagree. Which languages are easier to read and which ones are harder is of course obviously subjective. So maybe for YOU perl is easy to read. However, I myself have never, ever read or written (or written and then later read) perl code that was easy to read. There are lots and lots of very very small symbols which have very large effects on Perl code. Single characters can completely change the meaning of statements in perl. Sure that's true in many languages, but perl takes this problem to a whole new level.
Perl will die if people in general find it to be too troublesome to write and maintain. I personally have been in that camp for years and years. This article suggests that this is a global trend, and I say, good riddance.
C++ and perl are such different languages, that it's not really useful to compare them. They live in completely different parts of the programming language space. So it's not very useful for me to say that I find it much easier to write maintainable C++ code than perl code, even though it's true.
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++.
Parent
"Hate" isn't the right word. (Score:5, Insightful)
The problem is, Perl is just a programming language, not a conceptual system. Arguably it is the antithesis of a conceptual system. Many teams then create their own application frameworks atop it (e.g. Mason, POE), and it's rare for these frameworks to be compatible since Perl offers so many variations in the construction of even standard programming artifacts like classes & objects.
In addition, the level of expression (i.e. TMTOWTDI) means in practice that highly varying programming styles occur throughout large, long-lived bodies of code.
As a result, significant Perl-based business applications tend to become hard-to-maintain hairballs of divergent style and subtly variegated concept.
The root cause: as I started with; the absence of a standard conceptual framework for Perl means that during the early phases of a project, it's much harder to reason meaningfully about the eventual form of the system than it is with, say, Java or .NET where many of the design patterns are explicitly standardised.
I wouldn't say that "Corporates Hate Perl". It's just the Perl as an application language doesn't suit the formal design & architecture process we're seeing increasingly as IT departments start to grow up and realise that they're not the most important people in the company.
That doesn't disqualify Perl from being a useful tool, and it'll always have a place in data transformation, but it does mean that Perl isn't going to be one of the general-purpose application programming languages of the future.
For goodness sake, move on. (Score:5, Funny)
You have to migrate your badly written and hard-to-maintain Perl code into badly written and hard-to-maintain Java code as soon as possible.
This is an insult (Score:5, Funny)
This is an insult to associate us Perl-Haters with corporate types.
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.
How about the right tool for the job? (Score:5, Insightful)
-- Larry Wall, author of Perl
I rest my case.
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.
Parent
Re:Clarity and whatnot is for retards. (Score:5, Insightful)
From a manager's point of view, yes. Because it makes it easier for the company to find someone who is capable of maintaining it once the 133t haX0r has moved on to another job.
Besides, don't underestimate the importance of clarity and modularity in architecture. Which is not the same as "coding standards" that enforce things like naming schemes for variables. The latter is rather low-level and understandable to a PHB, the former is still more of an art and not easily measurable.
Parent
Re:Perl IS the problem (Score:5, Insightful)
Is it really fair to blame the language? I think the reason perl is the centre of so many big balls of mud is that it is easy to do prototypes in it. If people choose to take those prototypes and turn them into big balls of mud, then that is their own fault. If you start with a clean sheet of paper, do a good design and then decide to implement it in perl you won't end up with a big ball of mud.
Parent