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."
Could it be that, as well as being from an era of more ad-hoc approaches, the code is simply showing its age? System tend to get modified over time, and such modification is often done by multiple people under multiple managers.
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...
If we can put a man on the moon, why can't we shoot people for Apollo-related non-sequiturs?
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.
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.
Regular expressions are by no means a perl-only feature.
Possibly not the best example of why perl is shunned.
Perl is simply not winning the marketing war.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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?
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.
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 ...
"Freiheit ist immer auch die Freiheit des Andersdenkenden" - Rosa Luxemburg, 1871 - 1919
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.
Oolite: Elite-like game. For Mac, Linux and Windows
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++.
Perl encourages big ball of mud development
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.
ccalam - acoustic versions of new songs.
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.
Your assertion that Java 'dominates the web' is laughable, as applets have been a near-total failure, replaced wholesale by Flash- and AJAX-based systems, while on the backend PHP, Perl and more recently Python and Ruby have eaten Java's lunch. Where Java has succeeded is on big iron and with corporate accountingware (it is the new COBOL, much as C# is the new VB), and on mobile phones (as you stated), with some moderate success on the desktop.
-- Larry Wall, author of Perl
I rest my case.
My signature is in the cloud.
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.
"So they might try to have it reprogrammed in something popular (Visual Basic? *evil grin*) only to find out that a change of programming language will not magically cure their woes."
1. It's their money.
2. If it's not (#1), then it means you are in a position of decision making authority and can rectify the situation in a suitable manner.
Seriously, as long as your work environment involves calling decision makers "THEY" you really don't have a dog in the fight.
Why aren't you in an authoritative role by now, if you're so experienced, talented, knowledgeable and skilled?
It's no different from the other 10,000 slashdot posts where a decision maker was a "them", and somebody else's money was at risk.
-fb Everything not expressly forbidden is now mandatory.
I can only speak for investment banking but "lines per day" is not a metric which I've ever seen people actually use. Generally you are measured only one way. "Have you met your deliverables".
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.
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.
C - the footgun of programming languages
>IMHO, a syntax where you have to prefix a variable with a special character ($ in Perl's case) is a bad syntax.
The argument isn't really about syntax; it is rather the strong-typing versus weak-typing argument,
and that is worthy of far more investigation than simply declaring it "bad".
-fb Everything not expressly forbidden is now mandatory.
s!(?:^|\w*/|\.\./|\./)[^\s,@;:]*(? Interesting? Thats a one line regexp which does something which appears to be very very simple to do, but actually isnt.
That looks really simple? Sorry but it doesn't look to me. Perl may be a a very very powerful language, but that alone does not make it a language of choice.
Well that is a regular expression, not Perl. It's a different language, and is the standard way of handling strings in most programming languages. To be honest, I first learned about them in a formal language class in college, years before I picked up Perl.
If you don't like regular expressions, that's your choice, but it really has nothing to do with Perl, and you should try to understand them, as they are very useful, even outside programming.
As a software manager what i'm interested in is developing quality applications. The biggest cost in software is maintenance. If a language is difficult to read by the original author it will be impossible to maintain by anyone else.
I would consider Python because it encourages good design and readable code. Professionally I use Java because I can easily hire people who use it, and it also encourages good design and readable code, if a tad verbose.
Perl is very consise, but also difficult to read. It turns into a maintenance nightmare, and there are far fewer developer who know Perl.
Python is far better; it is more consise than Java, has similar OO features, is readable. It isn't quite up to replacing Java, but has impressed me and many other Java coders.
Oh, and I have no sympathy for coders who think they are so cool being able to code in ways nobody else understands. I would rather see a slightly slower algorithm thats clear than a fast one that is unmaintainable.
Complex code is the enemy of quality, as is premature optimization.
The language itself is not the problem, but the 'community' and their promotion of it may be. I have seen good Perl written by good corporate developers, but that's despite the available Perl tutorial and examples.
I can't recall seeing a Perl learning resource that presents code that is well structured, commented, and tolerant of bad inputs. That leads me to suspect that Perl attracts developers who take pride in hacking together "Works For Me" code in the shortest possible time using the fewest, tersest lines. Yes, you can do that in a C-like language, but Perl lets you get your "good enough" result faster.
When Perl is promoted by impatient, sloppy bodgers, it's no mystery why it would attractd similarly minded developers. It doesn't have to be that way, but that does seem to be the de facto situation.
If you were blocking sigs, you wouldn't have to read this.
Lines per day is frequently proposed and sometimes implemented. But it's also easy to kill, just do that little refactoring job you've been putting off and put in a report of minus two thousand lines.
They tend to get the message after that.
At my last job, I wrote a perfectly good perl loader for a large data file we'd bring in every night. They decided to kill it off and go with BusinessWorks instead. BW took 45 times longer (I shit you not -- 45 minutes instead of 1 minute) and broke every week. We finally got sick of the support issues and went back to perl.
Fact is that shiny pointy clicky just introduces complexity and additional points of failure into the infrastructure. If you want the latest buzzwords, then by all means, go with shiny pointy clicky. If you want your system to work, keep it with tried and true.
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.
Interesting that you got modded so high, despite failing to understand what the GP was saying.
I'm not positive what that regexp is doing, but the presence of / and ../ or ./ matches suggests it's manipulating a directory path in some way. After a few tests I think it may be intending to return the filename portion from a path, but if so it's a little buggy (and a good example of why reinventing the wheel isn't a great idea; just use basename).
You do make a point, but I feel your method of comparison is a bit questionable. While Python is a fairly old language, it's only seen general use for a very short period of time compared to Perl. That means that a) there's likely to be a lot more Perl code around than Python code, and b) a lot of the Python code that's around will be of high quality.
The main reason for this is that when a language first begins to be noticed, it's usually going to be embraced by people who want to show how good it is. They'll take extra care to make sure it's well written and easy to understand, because they're evangelizing the language. As a language ages, people will be using it who really don't give a crap about the quality of the code, and that will "pollute" your sample set.
Accessibility will also have a lot to do with it. Even when PHP was a pretty new language, a random sample of code would reveal it to be vastly inferior to just about every other language you could possibly think of. A lot of this is simply because PHP became so widespread that virtually every cheap (and many free) web hosts supported it, so every newbie who wanted to learn to program started with PHP.
A new programmer -- or a bad programmer -- can write terrible Python code just as easily as they can write terrible Perl code. But at least it will have proper indentation. I would be very hesitant to base too much of my assessment of a language on its "newbie safety factor". Else we'd all be using BASIC and Logo.
I'm a C++ coder. I've written OO code in Perl. Maybe I'm missing something about its elegance. Would you care to explain, with brief examples?
The problem here is that small != mean efficient.
Parsing the code is not what makes a program slow, and
we don't code for 1K or RAM anymore.
"impressive" oneliners completely fail to impress me.
Lines are cheap.
Time is not.
And bugs are expensive as hell.
I'm sure if you wrote code that walked through the
steps in what you are trying to achieve, all the
following would be quicker:
* for me to see the point of what you're doing
* for me to correctly change what it does.
* for you to get it working right in the first place.
If you feel it is childish to write code like
"find A"
"find B based on A"
"generate C based on B"
"silently fail for some values of C"
"replace B with C"
-rather than one giant, brittle regex-replace, I submit that you are the childish one.
sudo ergo sum
Good grief, how is "deliverables" a stupid metric. Either you deliver a working solution/program on time or you don't. Thats the deliverable. Bascially your saying that having and goal and having to deliver anything is stupid.
One should not theorize before one has data. -Sherlock Holmes-
Perl attracts developers who take pride in hacking together "Works For Me" code in the shortest possible time using the fewest, tersest lines. Yes, you can do that in a C-like language, but Perl lets you get your "good enough" result faster.
For me, that's the strength of Perl. I don't use it for anything other than works-for-me type small tidbits of code. Will it require maintenance, or extending, or support by other people? Then I don't use Perl, because it's complex enough to warrant a strict language. In essence, text parsing and one-off scripts are fantastic, other stuff I stay away from.
True confidence comes not from realising you are as good as your peers, but that your peers are as bad as you are.
Yes, it is.
It's like saying "Most Basic & VB Code is Verbose, is it really fair to blame the language?"
YES!!
Every language has a unique idiom. And the best languages use this idiom to painlessly guide the developer to best practices.
For exammple, lots of devs consider Java to be over-engineered and overly-complex. You've probably heard a dev talk about building something in, say, RoR in a week that would've taken 4 weeks in Java.
That's probably true, because Java is a tool best designed for large applications and when you're using Java, it's idiom guides you into building multi-tiered architecture.
Python's idiom guides devs into producing well formatted code and it's a great language for web apps because it puts powerful data structures right in the developers face.
C# is a FANTASTIC language for teaching OOD to procedural developers. It's HARD for a procedural developer to think in terms of object hierarchies. The mechanics are easy to pick up. The ability to deconstruct a problem into an object hierarchy is hard.
But you put them in front of a new project in C# and the language -- entirely OO itself -- just guides a developer to the right thing. It's very hard to shoe-horn a procedural architecture into an OO-only language.
JavaScript makes it insanely easy to create an event-driven application. Anonymous functions, LAMBDAs, etc, guide a developer into producing code in an event/event-handler model.
Any developer can do nearly anything with any language. But a language itself can make it easy and obvious when you're doing things right, and painful for you when you're doing them wrong. And a good IDE will reinforce both of these behaviors.
So true.
I switched to Python because I could not market Perl to anybody including myself.
I was using it from time to time and would try to convince coworkers to use it too.
But the readability issues and the lack of keywords made it more difficult to look for documentation etc.
As a result I could not market it to my coworkers and started having serious doubts myself. So I switched to Python.
Suddenly, I could convince my coworkers easily as it looked good, readable, easy to learn by example etc.
Also Perl and Python are very similar in what they offer (regexps, hashtables, string parsing, networking, modules). But Python usually offers a language construct to support important software engineering concepts (e.g. objects are native and not reimplemented every time as in Perl).
Just my 2 cents. I tried to love Perl and market it around me. But I couldn't. PHP, Python, Linux, Wikis are easy sells but Perl is not.
Sometimes. Sometimes, management gives you a deadline with the spec, and you don't have the ability to set your own schedule.
And sometimes, the spec is something like "Somewhere in the jungle is a river. Build a suspension bridge over it."
"Do you have a map of the jungle?"
"No, it's unexplored."
"Do you know how wide the river is?"
"No. I told you, the jungle is unexplored."
"Is there a road through the jungle to the river?"
"No. The jungle is unexplored. But look, you've built dozens on bridges, just tell me how long it will take to build this one! Give me a schedule with some deliverables."
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Lord, I thought the bless thing was a pain, and now you're telling me that there's at least FIVE different CPAN thingys that give me a way to do object-oriented Perl development? Perl's been on my "avoid" list for years now, and what you've revealed to me scares me to my very core, and only further cements my desire to continue avoiding it. It was great in the early-mid 90s as a way to make interactive web apps, and it fit really nicely into that "need more power than a shell script, but C is overkill" niche, but now? Perl sounds like the MCP from Tron, absorbing all functions into it. :-)
Since there are at least five of them, something tells me that the odds are decent that at a given Perl shop, some genius thought they all sucked and rolled his own all-singing, all-dancing object model. The net result is basically nobody can now claim to be truly knowledgeable about object-oriented development in Perl.
Right on. This is the real problem with Perl. Everyone rolls their own and we end up with multiple reimplementations of the same concept done in sometimes subtly different ways.
CPAN is one of my worst nightmares. There's no peer review so one ends up looking at several different libraries that do the same thing, only they all do it differently and have varying levels of feature complexity. I just want to get work done, not evaluate libraries.
what's not obvious in that line ?