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.
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.
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.
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:5, Funny)
to me the biggest issue is maintainability, some languages help you in that department, some hinder.
I quote the lecturer from my software maintenance course:
"As I understand it, the standard maintenance method with Perl is to start again."
Re:Ockham's Razor tells me.... (Score:4, Funny)
with things like OO being rather clunkily bolted on
I beg to differ. I think that how perl handles OO is one of the most elegant ways I've seen any language to it.
Re:Ockham's Razor tells me.... (Score:4, Insightful)
Re:Ockham's Razor tells me.... (Score:5, Funny)
oh, don't worry, they'll be brief, this is perl, right ?
Whether you'll be able to read them though, that's a different matter altogether ;)
Re:Ockham's Razor tells me.... (Score:5, Funny)
All Perl needs is a shiny new catch phrase...
Perl on Rails?
CloudPerl?
Extreme Perl?
Perl#?
Re:Ockham's Razor tells me.... (Score:5, Funny)
Perl6?
Re:Ockham's Razor tells me.... (Score:5, Funny)
All Perl needs is a shiny new catch phrase... Perl on Rails? CloudPerl? Extreme Perl? Perl#?
How about "Perl Necklace?"
Re:Ockham's Razor tells me.... (Score:5, Funny)
Well you're a C++ programmer so your vote on elegant OO is NULL and void* :-P
I jest, I jest.
Re:Ockham's Razor tells me.... (Score:5, Insightful)
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.
Re:Ockham's Razor tells me.... (Score:4, Insightful)
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.
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:Ockham's Razor tells me.... (Score:5, Funny)
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.
That's because PERL, even good PERL, looks like an explosion at the punctuation factory compared to a vast majority of other languages.
Re:Ockham's Razor tells me.... (Score:5, Insightful)
what's not obvious in that line ?
Re:Ockham's Razor tells me.... (Score:4, Insightful)
my %hash = ( [ 1, 2, 3 ], [ 4, 5, 6 ] );
My, that's awfully ugly, isn't it?
Re:Ockham's Razor tells me.... (Score:5, Insightful)
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.
Re:Ockham's Razor tells me.... (Score:5, Insightful)
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."
Re:Ockham's Razor tells me.... (Score:5, Insightful)
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.
Re:Ockham's Razor tells me.... (Score:4, Funny)
What is worng with you Perl programmers? Does the thought of a newline or indentation, possibly even whitespace fill you with fear and horror?
Re:Ockham's Razor tells me.... (Score:4, Insightful)
I can only speak for investment banking but "lines per day" is not a metric which I've ever seen people actually use.
Some people use it, but on its own it's a really bad metric. A top quality developer will do the same task in far fewer lines of code, with better reliability, than a poor quality developer. That means metrics based on lines per day alone may identify the worst programmers rather than the best.
Sometimes the correct answer is the simplest (Score:3, Informative)
A 100K/year good programmer can also have difficulties understanding perl code.
If you look at the most efficient perl code, it will be very small, and do a lot. But it will also mean that nobody else can understand the code
Heck I have difficulty in understanding a couple own scripts if I look at them after a year, and that too when I add comments.
Perl is a very very powerful language. A small change can make the code do something
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.
Re:Sometimes the correct answer is the simplest (Score:5, Insightful)
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.
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.
Re: (Score:3, Insightful)
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.
For a company to choose a language, one should not only consider the power, but also the maintainability. One should not only consider how a strong programmer would perform in it, but also how a beginner can screw it up, and how a beginner can understand a powerful program.
These considerations make Perl generally a bad choice. As a simple test, dow
Re:Sometimes the correct answer is the simplest (Score:5, Insightful)
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 [wikipedia.org] 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.
Re:Sometimes the correct answer is the simplest (Score:5, Insightful)
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.
Re:Sometimes the correct answer is the simplest (Score:4, Insightful)
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.
And we all know that proper indentation will never break anything.
TAB Code
TAB Code
SPACETAB Code
TAB Code
TAB Code
How long would it take you to debug that problem? It took me two hours the first time I tried to learn Python (reading someone else's code) and that's why there hasn't been a second time.
Re:Sometimes the correct answer is the simplest (Score:5, Informative)
How long would it take you to debug that problem?
About 12 seconds. Run Python with the -tt option and it will tell you about lines with inconsistent use of tabs and spaces.
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: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.
Comment removed (Score:5, Funny)
Re:Sometimes the correct answer is the simplest (Score:4, Insightful)
s!(?:^|\w*/|\.\./|\./)[^\s,@;:]*(?<=/)([^\s,@;:]+?)(?=[\s,@;:]|$)!$1!g;
"You have a problem, and you discover you can solve it by using regular expressions.
Well, now you have another problem"
I read this in the opening of a regular expression chapter of a Python book by Tim Peters (though the quote is certainly not exact); so I am unsure whether he was quoting somebody, or not. Anyway, the point stands.
Re:Sometimes the correct answer is the simplest (Score:4, Informative)
The actual quote is this:
The source of the quote is Jamie Zawinski [jwz.org], who said it on Usenet in 1997 [regex.info].
Re:Sometimes the correct answer is the simplest (Score:5, Insightful)
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.
Re:Sometimes the correct answer is the simplest (Score:4, Insightful)
So your argument boils down to "perl is unmaintainable, but that's ok, because you can just replace code instead of maintaining it".
You must write bug-free code if you never have to make small changes to existing code. My hat is off to you sir.
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.
Re:Ockham's Razor tells me.... (Score:4, Insightful)
How many internal/script-driven systems have you seen
over "a few" years old
maintained by at least "a couple" different people,
that don't end up a train wreck?
The need to revamp a system is often more a question of when.
So, you get to that point, and the question becomes:
do we keep this funky old perl,
or start from scratch with something relatively tidy and
popular from a staffing perspective?
Re:Ockham's Razor tells me.... (Score:4, Insightful)
"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.
Re:Ockham's Razor tells me.... (Score:5, Informative)
Yes! Book recommendations for Perl programmers, outside of the standard ones you need :
All the rest I learned from the camel book. I use Perl on three platforms (Win32, Cygwin and Solaris), using the same libraries, and now also adding Perl/TK to the mix.
If you need to define several goals, I would recommend Perl Best Practices for writing maintainable and easy to read code and installing a peer review process.
HTDP is more for individual programmers, to become smarter and better programmers.
Re:Ockham's Razor tells me.... (Score:5, Insightful)
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.
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:Ockham's Razor tells me.... (Score:4, Insightful)
For some subjective metric of "better"...
Age (Score:4, Insightful)
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...
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.
Programming tricks (Score:4, Insightful)
Whenever you think of a clever programming trick: forget it !
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.
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:Clarity and whatnot is for retards. (Score:4, Insightful)
None of the things you mention improve clarity, modularity and maintainability.
Well possibly wrapped accessors, but only when called for.
What i meant was avoid clever-but-stupid shit like displaying
how much crap you can get done with a bodyless for-loop,
deep if-trees that might save you a superflous comparison or
two, but take all day to read correctly and correctly implement
a really simple change in the underlying rule.
If you do database access, data representation, transformations
and file output, please don't do them all all over the place.
You don't need to amake a plugin architecture, but it really
doesn't cost much to design a simple output module API so it might
be switched with a completely different output engine later.
And guess what: it will make your code clearer and better even if
you never make that second output module.
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.
Re: (Score:3, Funny)
Give the yahoos what they want (Score:3, Insightful)
Shiny.
New.
Perfect.
Can use it without knowing anything.
They'll start complaining about the new stuff as soon as they realize it only gives them a new untested set of problems and work-arounds. If you want to keep working there, you'll change yet again when enough of the 'decision makers' can't take it anymore.
I have a client with a very workable multi-platform enterprise calendaring/scheduling system. Two people out of 15 in the organization want to use Outlook. It's a fair bet the company will migrate to Microsoft Exchange within the next 6 months and if I want to keep making money from them, I will be training these two users and their colleagues on how to share calendars in Exchange/Outlook. Will life be any better for them? I think the learning curve for sophisticated use of Outlook/Exchange is a bit higher than for MeetingMaker... but we shall see.
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.
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.
Re:Perl IS the problem (Score:5, Insightful)
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.
Re:Perl IS the problem (Score:5, Insightful)
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.
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:Perl IS the problem (Score:4, Insightful)
People on this board blame VB all the time for bad programs. Perl doesn't get a pass.
(That said, I agree with you, I don't think you can blame the language for bad code; I *do* believe a language can contain features that encourage bad code.)
Re:Perl IS the problem (Score:5, Insightful)
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.
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.
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.
Re: (Score:3, Insightful)
It's true that programmers fall victim to fad-ism, but the fact is that the learning curve of Perl is quite steep compared to that of PHP. PHP (and, arguably ASP) brought something to the table that Perl lacks -- readability, comprehensibility, expandability.
As far as RoR is concerned, it's nothing new -- it's simply a framework (a very young, immature one, at that, in terms of software maturity) that could have been written in ANY language (PHP on Rails, anyone?). This is why we're seeing RoR developers ge
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.
Re: (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, i
Re:heyho, python - the new perl. (Score:4, Insightful)
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.
Re:heyho, python - the new perl. (Score:4, Insightful)
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,
No, it's your suggestion that applets are even relevant to this discussion that's laughable.
Have you ever heard of servlets? Have you head of the dozens of web frameworks that run in them?
You're living 10 years in the past. Right now, Java does dominate the web backend. PHP and Perl are hasbeens, and simply not suitable for the large scale web applications of today. Ruby is deifintely up and coming, but is still a long way from eating Java's lunch (though I'm sure that will happen someday -- I hope it will, because Java kinda sucks).
Re:heyho, python - the new perl. (Score:5, Informative)
Applets? This isn't 1998.
If you missed it, this thred is about corporates. All the big players - governments, big iron (ibm, etc), large enterprise developers (logica, capita, etc), military and most cutting-edge science development projects, use Java for Enterprise-grade applications.
Sure, the front-end desktop/browser embedded side is dominated by flash and ajax, with flex on the rise. But only small to medium development houses use much PHP and Python. Ruby is too new/too niche for now, and Perl *is* legacy, due to too few developers around, and no major new projects being written in it (Thank God).
Thanks for playing, try again sometime.
Re: (Score:3, Insightful)
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.
You can argue that Perl's OO is pasted on, which is somewhat true, but that doesn't mean that it isn't powerfull. Try Moose [cpan.org]. Certainly OO is a thing being fixed in Perl6. Until that is available use Moose or try to realize that OOP isn't the only form of programming.
Saying indirectly that Perl5 isn't well designed, just pisses me off. It grew organically, but changed during these years and got refined. If you keep to best practises, Perl code can be as readable as any language and even better as it is more
Re:heyho, python - the new perl. (Score:4, Informative)
There's one big diifference, however: python is a well-designed, highly structured language.
But still, dynamically typed so we get type errors at customer sites, slow, and memory hogging. (Also 'features' of Perl too). OO-paradigm, so clumsy to use. And the stupid whitespace thing means that patches get misapplied and it's very easy to accidentally misindent some existing code in the editor, not notice, then have the program do some totally different thing.
Perl is probably brilliant for simple scripts, but should not be used for large programs
That's complete nonsense. I personally have maintained 100,000-line Perl programs without problems. Divide the program up, factor out modules as libraries, do lots of testing and code reviews. It's really not that hard.
Rich.
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: (Score:3, Insightful)
Python's syntax pisses me off.
I primarially program in Perl, PHP and C/C++ which all share virtually identical syntax.
Makes it a lot easier mentally and you can still use the right tool for the job.
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 ...
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.
Face it, Perl IS hard (Score:4, Insightful)
Setting aside obvious reasons why corporate hats would hate anything they don't dig (tip: it is matter of control. Yes, they want to have possibility to fire you any moment without hesitation), Perl is powerful, but really hard language. Specially when it is written in hurry to complete some task. Without any shred of doc or help it is almost impossible to maintain for thirty party.
Also, in broader picture, it is common problem with IT everywhere - nondocumented stuff which does system critical stuff is big no no. I know, lot of people see it as job security, but it is the same variation as terrorist has job security when it has hostages.
If you want real job security, do your job properly, and you will get rewarded. And if there will be firings, they will happen in any case.
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?
Re:Why Corp. hate Perl? (Score:5, Funny)
Perl 1.0 was released in 1987, four years before Python. How old is your dad - and more to the point, how old are you?
Re:Why Corp. hate Perl? (Score:4, Funny)
In Internet Time, 1987 was 84 years ago.
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++.
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.
"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 isn't just about "new and shiny" (Score:4, Insightful)
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.
Re: (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
How about the right tool for the job? (Score:5, Insightful)
-- Larry Wall, author of Perl
I rest my case.
I don't get it (Score:3, Insightful)
So, you are saying that someone, who is not specified, wants to move away from some program, which is not specified and written in Perl, to a solution based on a different language, which is not specified. You then speculate that this or might not be due to the grown & evolved nature of the unspecified program.
How is this news? What do you actually want to tell us?
Don't get me wrong, I love Perl. I simply do not understand why you would submit this to /. or why it would get approved. I am seriously confused.
Quality vs Complexity (Score:5, Insightful)
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.
Re:Perl is WRITE-ONLY language. (Score:4, Funny)
Dim Perl As String.WriteOnly
If You = Well.Disciplined.Person And Write.Comments(UBound(Perl.Lines) = True Then
If Decrypt(Flow) Then
Such Things Happen
Elseif Other.Languages = (C++ Or Java Or Python)
Decrypt.Method += Hard
End If
End If
If Syntax.Contains("$") Then
Return Format(My.Opinion, Humble) & "Bad Syntax"
Else
Return Format("", Opinions.Null)
End If
Ok, so the code sucks (in VB no less)... but, I just found the way you wrote your comment kinda weird...
Re:Perl is WRITE-ONLY language. (Score:5, Insightful)
>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".
Re:Perl is WRITE-ONLY language. (Score:4, Insightful)
If you give your variables/functions meaningful names (ie: $StoredPrice instead of $st, savePrice() instead of sv()) then half of your reading problems is fixed already.
I'm truly tired of that laziness. Well written codes should need the minimum of comment. Oh...And by the way, tabulation and don't play the genius coder while trying to put as much as instructions per line. Split them wisely. Then everybody is happy, whatever the language is...It will be readable.
My main concern with Perl is the object oriented feature, for the rest, it works like a charm. The synthax isn't that hard, the problem is the lambda Perl coder bad habits IMHO (trying to be the most cryptic possible), it is purely cultural and it has nothing to do with the language as far as I know.
Re:I hate perl too (Score:4, Funny)
chomp is not ambiguous. RTFM and stop crying.
http://perldoc.perl.org/functions/chomp.html [perl.org]
This safer version of "chop" removes any trailing string that corresponds to the current value of $/ (also known as $INPUT_RECORD_SEPARATOR in the English module). It returns the total number of characters removed from all its arguments. It's often used to remove the newline from the end of an input record when you're worried that the final record may be missing its newline. When in paragraph mode ($/ = "" ), it removes all trailing newlines from the string. When in slurp mode ($/ = undef ) or fixed-length record mode ($/ is a reference to an integer or the like, see perlvar) chomp() won't remove anything. If VARIABLE is omitted, it chomps $_ . Example:
If anything I'm crying harder after reading that.
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.