×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Why Corporates Hate Perl

kdawson posted more than 5 years ago | from the not-such-a-shiny-new-thing dept.

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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

963 comments

Nigger Jew did 9/11 (-1, Troll)

Anonymous Coward | more than 5 years ago | (#24669893)

9/11 tragedy was perpetrated by American Nigger Jew and not Arab conspirator!

Ockham's Razor tells me.... (5, Interesting)

arth1 (260657) | more than 5 years ago | (#24669897)

... 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.... (5, Insightful)

silentbozo (542534) | more than 5 years ago | (#24669957)

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.... (5, Insightful)

dintech (998802) | more than 5 years ago | (#24670233)

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.

Sometimes the correct answer is the simplest (3, Informative)

tanveer1979 (530624) | more than 5 years ago | (#24669963)

If we forget the conspiracy theories for a while, there are other reasons too.
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 completely different, hence the fear.

For example look at this
        s!(?:^|\w*/|\.\./|\./)[^\s,@;:]*(?<=/)([^\s,@;:]+?)(?=[\s,@;:]|$)!$1!g;

Interesting?
Thats a one line regexp which does something which appears to be very very simple to do, but actually isnt.

Re:Sometimes the correct answer is the simplest (5, Insightful)

smitty_one_each (243267) | more than 5 years ago | (#24669983)

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.

Re:Sometimes the correct answer is the simplest (4, Insightful)

Alioth (221270) | more than 5 years ago | (#24670083)

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:Sometimes the correct answer is the simplest (0, Troll)

arth1 (260657) | more than 5 years ago | (#24670117)

A 100K/year good programmer can also have difficulties understanding perl code.

You don't have to understand how to read it, beyond grepping for comments and function names. You have to understand how to write it.

Perl is a very very powerful language. A small change can make the code do something completely different, hence the fear.

Which is why you never do a "small change". You replace non-functioning code with functioning code.

This is why specs and comments that document the API, and not just the code, is crucial. It allows you to replace code far easier.

Re:Sometimes the correct answer is the simplest (3, Insightful)

tomtomtom777 (1148633) | more than 5 years ago | (#24670173)

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, download 50 perl programs at random, download 50 python programs at random, compare the quality. Fact that there is to much f*cked up perl code, shows that it is an inferior language.

Re:Sometimes the correct answer is the simplest (5, Insightful)

baest (763283) | more than 5 years ago | (#24670207)

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.

Re:Sometimes the correct answer is the simplest (0)

Anonymous Coward | more than 5 years ago | (#24670335)

So, you're the $100k/yr programmer who's confusing between Perl and regex? Man, I want your job.

Re:Ockham's Razor tells me.... (-1, Troll)

Anonymous Coward | more than 5 years ago | (#24670025)

Someone is jealous because they didn't get a perl necklace from the boss this week. Sometimes it's not the money you receive but the service you give.

Re:Ockham's Razor tells me.... (4, Interesting)

Lonewolf666 (259450) | more than 5 years ago | (#24670049)

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.... (3, Insightful)

smitty_one_each (243267) | more than 5 years ago | (#24670115)

You post invites the question:
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.... (1)

Lonewolf666 (259450) | more than 5 years ago | (#24670163)

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?

I don't doubt that a system might reach the point where it can only be replaced.

What I suspect is that the management in question has come to the false conclusion that the old system is bad because it is written in Perl. Not because project planning or the developers sucked.

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.

Re:Ockham's Razor tells me.... (4, Insightful)

fishbowl (7759) | more than 5 years ago | (#24670211)

"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.... (1)

Lonewolf666 (259450) | more than 5 years ago | (#24670361)

In this case (I'm neither an employee nor a stockholder of the company in question) I certainly don't have a dog in the fight. So it is more of a general observation on what might work and what might not.

If you dislike this sort of discussion, maybe Slashdot is not the right place for you.

Re:Ockham's Razor tells me.... (1, Insightful)

Anonymous Coward | more than 5 years ago | (#24670283)

Oh please, it's not just corporate opinion it's programmers that hate Perl. If you want beauty and speed then Python is better. If you want language features then Ruby is better. Both languages encourage more maintainable code and there's very little now that Perl is better at, other than promoting a language with comparatively ugly syntax (and please no relativism here... no one would choose that Perl syntax if they were starting from scratch and so let's just call Perl what it is: ugly, just not as ugly as PHP)

.

Further, the external impression for over 5 years now is that Perl/Parrot is a dead project. There are no iterative improvements, it's a build-from-scratch restart with completely new foundations. Now the apologists will say that the 5.x series receives new software on CPAN and so they don't need feature X. I mean really, listen to yourselves. If you didn't love Perl you be elsewhere -- the apologists explain exactly why Perl is dead. It might do a Firefox/Phoenix and rise from the ashes in 5 years but -- unlike Firefox -- Perl isn't filling a hole. Other languages have shown they are more than capable at pulling up the slack. Perl/Parrot suffers from exceptionally poor project management.

.

And to be honest I'm happy with syntax problems, a dead project and a public impression of decay. Unlike 10 years ago the language doesn't deserve your praise anymore -- it's not earning your respect and you should acknowledge that. Nostalgia is a good reason to like Perl or to think fondly of Pluto as planet, but the world has moved on and you should too.

.

Perl is deprecated. Python and Ruby are where it's at.

Re:Ockham's Razor tells me.... (5, Informative)

chthon (580889) | more than 5 years ago | (#24670353)

Yes! Book recommendations for Perl programmers, outside of the standard ones you need :

  • Perl Best Practices, by Damian Conway. This one is really mandatory.
  • Higher-Order Perl, by Mark Jason Dominus, to understand why Perl is so powerful.
  • How To Design Programs [htdp.org], which taught me better ways of using Perl, even though the book is based upon Scheme.
  • Structure and Interpretation of Computer Programs [mit.edu], which is somewhat the bridge between HTDP and Higher-Order Perl.

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.

Age (4, Insightful)

damburger (981828) | more than 5 years ago | (#24669913)

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 (4, Interesting)

famebait (450028) | more than 5 years ago | (#24669989)

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.

Clarity and whatnot is for retards. (0, Flamebait)

tjstork (137384) | more than 5 years ago | (#24670157)

they're called for or not, and too little in clarity, modularity and maintainability

I've been around the block long enough to know that what this often is an excuse for corporate environments to hold better developers back to try and force a levelling of a pay scale. If you paid developers based on their ability to produce working systems, you would find that some developers produce far more than others. But.... now we have to riddle our code with wrapped access methods, ultra long symbol names, case sensitivity and standards made by morons for morons, and all of it adds -ZERO- features to the finished product. Sure, you can argue that it makes "better" code, but that "better" code has NO MORE EXTRA FEATURES. It only allows retards to work on it. And really, is that a feature?

Re:Clarity and whatnot is for retards. (4, Insightful)

Lonewolf666 (259450) | more than 5 years ago | (#24670235)

Sure, you can argue that it makes "better" code, but that "better" code has NO MORE EXTRA FEATURES. It only allows retards to work on it. And really, is that a feature?

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.

It's the slashdot effect! (5, Funny)

pjf (184549) | more than 5 years ago | (#24669925)

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.

Give the yahoos what they want (3, Insightful)

Anonymous Coward | more than 5 years ago | (#24669935)

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 (4, Interesting)

Colin Smith (2679) | more than 5 years ago | (#24669941)

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 (0)

Anonymous Coward | more than 5 years ago | (#24669979)

I don't know. Git is pretty successful.

Re:Perl IS /your/ the problem (0)

Anonymous Coward | more than 5 years ago | (#24669995)

If you can't write proper code with Perl, I'm really sorry, but it's your problem.

Re:Perl IS /your/ the problem (0)

Anonymous Coward | more than 5 years ago | (#24670141)

Re:Perl IS /your/ the problem

Perfect example of perl syntax!

Re:Perl IS /your/ the problem (1)

iron-kurton (891451) | more than 5 years ago | (#24670147)

I think his point is that Perl doesn't encourage nor enforce good coding practices.

[asbestos hat on]
If you take Java for instance, _everything_ from the main method to the kitchen sink is inside objects (with very few, controlled and necessary exceptions), which conform to the OO paradigm.

Tell me, what kind of structure does perl enforce or even encourage?

Don't get me wrong, Perl is EXCELLENT in what it can do -- quickly manipulate large amounts of data. But it wasn't designed to do much else. Perl (like PHP) is a far, far cry from a enterprise programming language, and frankly, I'd like it to stay that way.

[asbestos hat off]

Re:Perl IS /your/ the problem (0)

Anonymous Coward | more than 5 years ago | (#24670159)

It appears that you are yet another Perl fanboy who refuses to acknowledge that there really is an issue with the spaghetti code that Perl coders tend to produce. These types of situations don't occur nearly as often when using PHP or Java. It may be that Perl tends to attract the types of programmers who just like to get the application working and go home, while Java tends to attract the types of programmers that care more about architecture and maintainability. From my experience, 4 out of 5 Perl coders haven't read Design Patterns while 4 out of 5 Java coders have. It should be no surprise that Perl coders (most of which don't have a CS degree) tend to write unmaintainable code with no type of architecture in mind.

Please read YOUR post (0)

Anonymous Coward | more than 5 years ago | (#24670221)

"the spaghetti code that Perl coders tend to produce."

that's not Perl, that's the coder. Make them write in C# and it will be spaghetti code. Does that mean C# is a terrible language?

No.

Re:Perl IS the problem (0)

Anonymous Coward | more than 5 years ago | (#24670111)

Perl is, after all, referred to as "executable line noise".

Re:Perl IS the problem (4, Insightful)

niceone (992278) | more than 5 years ago | (#24670143)

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.

Re:Perl IS the problem (0, Flamebait)

Alioth (221270) | more than 5 years ago | (#24670167)

There's an old proverb: 'A bad worker blames his tools'.

I don't have this problem with Perl.

Re:Perl IS the problem (1)

LizardKing (5245) | more than 5 years ago | (#24670307)

Yeah this excuse comes up every time someone dares to go against the Slashdot orthodoxy and criticise Perl, along with "it's possible to write unmaintainable code in any language". The truth is that Perl code is generally a hack, because it's so easy to do something that just about works with it. Look at the CPAN modules for example - so much unmaintained, unfinished code (for example, has Perl/Tk stopped crashing and leaking memory like a sieve yet?). For systems where "just about works" isn't good enough, I'll choose a language and libraries that allow me to use decent profiling and debugging tools. One where there is also extensive literature on designing systems (programming in the large, not just the language details or programming in the small). Where OO and threading are an intrinsic part of the language, not another weird joke from Larry Wall or eternally marked as experimental.

Re:Perl IS the problem (0)

Anonymous Coward | more than 5 years ago | (#24670183)

Um, no.

Perl, quite simply put, is a tool. It's a versatile one, like a Swiss army knife or so - and it's one that requires its users to actually have some intelligence because it doesn't FORCE them to do things The One True Way.

Some people will be comfortable with that, some won't. Maybe you fall into the latter group - no, you *certainly* fall into the latter group -, and that's OK, but don't make the mistake of being so narrow-minded (quite literally) to think that everyone else is like that, too. It's precisely that same One True Way thinking again.

Re:Perl IS the problem (1, Insightful)

MrMickS (568778) | more than 5 years ago | (#24670245)

Perl doesn't help but its not the problem. The problem falls on the people writing the code and the demands made on them.

My current berth is typical of this. We've been given a 'system' that requires a degree of scripting to be done to glue the various discrete parts together. A combination of Perl and Ksh has been chosen to do this. Why? No idea, those choices were made before I joined the project. Looking at the people writing the code, none of them have any sort of development background. Add to this the demands from the business that the 'system' has to work yesterday, means that a lot of hacking together of scripts has gone on.

The result is that some of the code is practically unmaintainable by anyone but the person that wrote it. This isn't the fault of the language though, its the fault of the developers. With a framework of modules in place the newer code is readable and easy to maintain. Its the older stuff that we just poke with a stick. No Perl doesn't stop you writing bad code, it doesn't make you write it either though.

Getting back to the original topic. A lot of Perl code was written around the time of the dotcom bubble, when there was a shortage of IT staff. The result was that if you could spell Unix and Perl you could get a job. Everything was fast paced, had to be first to market. Corners were, frequently, cut. The result was people with inappropriate skills developed systems without spending the necessary time spent in the design phase. Corporates have had to deal with the fallout from this when people have said "I can't fix that, I'll have to rewrite it". Instead of looking at the bad practice that generated the code they are blaming the language. Other languages may protect, somewhat, against these bad practices, I doubt that they instantly make code maintainable though. I can write bad code in any language, its experience and professionalism that means that I chose not to.

To be fair to the corporates (4, Insightful)

Sycraft-fu (314770) | more than 5 years ago | (#24669945)

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 (5, Insightful)

famebait (450028) | more than 5 years ago | (#24670103)

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:To be fair to the corporates (2, Insightful)

iron-kurton (891451) | more than 5 years ago | (#24670199)

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 get frustrated and go back [oreillynet.com] to PHP!

I haven't heard many PHP developers going back to Perl.

heyho, python - the new perl. (3, Interesting)

apodyopsis (1048476) | more than 5 years ago | (#24669947)

python seems to be the new perl - ie. a general purpose, scripting glue language. its small number of keywords and simple layout make it easier for the less technical minded to learn quickly.

of course, many people will prefer to use perl because of its larger amount of add-ons and clever tricks.

at work I use PHP a lot for many of my simulations and quick fixes, its really good for processing 2M line data files (try doing that with excel). I know its not what it was originally designed for, but it works for me.

look on the bright side, perl will no longer be learnt by many people and in a few years legacy "perl coders" can command higher wages to work on "legacy system" - much like COBOL programmer do now (though there are less of them every year).

I think this is the way it will always be, there will always be a simpler language to replace the old standards, and a new shiny technology that those who have managerial power but less technical knowledge can mandate from on high.

so, what happened to java? I liked it, it never went away but seems to hover on the edge.

Re:heyho, python - the new perl. (3, Interesting)

mcvos (645701) | more than 5 years ago | (#24670029)

python seems to be the new perl

There's one big diifference, however: python is a well-designed, highly structured language. Perl sort of grew organically from a couple of scripting languages, and had OO pasted on later.

Perl is probably brilliant for simple scripts, but should not be used for large programs. Python is very useful for large programs, however.

so, what happened to java? I liked it, it never went away but seems to hover on the edge.

On the edge of what? Java is the biggest programming language in the world today. It dominates the web and mobile phones, and although it's not quite as popular for desktop programs, it's not uncommon there either.

It's not a scripting language like Perl, however, so if your world looks like Perl, you may not notice Java that much.

Re:heyho, python - the new perl. (4, Insightful)

Anonymous Coward | more than 5 years ago | (#24670181)

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. (1)

DJProtoss (589443) | more than 5 years ago | (#24670203)

Perl is probably brilliant for simple scripts, but should not be used for large programs. Python is very useful for large programs, however.

I agree. However, I'll go further and say for most simple scripts sh ( or at a push bash ) is better. The only thing you can't easily do is arrays ( which you *can* do, but its nasty ). Oh, and the performance can be poor if you have too many calls to sed. On the other hand, if its a sufficiently time critical / important script that a few extra seconds because of all the spawning matters, I'd probably be cracking out the c compiler anyway...

Re:heyho, python - the new perl. (3, Insightful)

baest (763283) | more than 5 years ago | (#24670253)

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 powerfull.

Re:heyho, python - the new perl. (1)

js_sebastian (946118) | more than 5 years ago | (#24670369)

I love python, but I see my own python projects (developed at astonishing speed) quickly become pretty ugly, as opposed to say, my C++ code which mostly has a reasonably thought out design. That's mostly ok, as most of them are prototypes anyway... but you never know when a prototype will turn into something else!

I think a robust python codebase requires strong committment to quality coding standards, and an automatic checker to enforce at least some of them. I'm not sure if pychecker cuts it. Otherwise it's just too easy to do potentially evil things (like adding members to a class from outside the class, which is convenient but very confusing too, or getting into the whole import mess with too many from import *). Oh and unit tests, unit tests...

Re:heyho, python - the new perl. (0)

Anonymous Coward | more than 5 years ago | (#24670035)

I don't do much coding now and if I do it's in java. I used to use perl exclusively for prototyping. It was easy to knock up an 80 line program that did EVERYTHING.

To do the same in java these days, it probably takes 80 lines, but you need to import a dozen classes.

Flon's Law (1, Interesting)

Anonymous Coward | more than 5 years ago | (#24669951)

There is not now, and never will be, a language in which it is the least bit difficult to write bad programs.

Perl is WRITE-ONLY language. (0, Flamebait)

Anonymous Coward | more than 5 years ago | (#24669953)

Perl is WRITE-ONLY language.
You have to be a well-disciplined person an write the comments for every line of Perl code otherwise
it's hard to decrypt the flow. Such things happens
rarely in other languages (C++/Java/Python).
IMHO, a syntax where you have to prefix a variable with a special character ($ in Perl's case) is a bad syntax.

Re:Perl is WRITE-ONLY language. (3, Funny)

Vectronic (1221470) | more than 5 years ago | (#24670085)

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. (5, Insightful)

fishbowl (7759) | more than 5 years ago | (#24670275)

>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".

Why not Python? (4, Interesting)

Raul654 (453029) | more than 5 years ago | (#24669959)

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? (2, Insightful)

cheater512 (783349) | more than 5 years ago | (#24670021)

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? (5, Insightful)

gullevek (174152) | more than 5 years ago | (#24670065)

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? (1)

k-zed (92087) | more than 5 years ago | (#24670325)

From a more technological point of view there is also a fundamental difference between the philosophies of the two languages.

Perl subscribes to "there is more than one way to do it"; Python is all about "there should be only one way". The latter is what made Java such an insipid and annoying language to develop in. Python is probably saved from this only by its much better standard library and generally smaller verbosity.

Personally, if I had to choose from the two, I would still choose Python because of the gentler learning curve, and because I hate forced indentation/whitespace slightly less than Perl's type sigils.

But if you can choose any language, try one of those newly popular "modern" languages - finally get down on your ass and learn Haskell (as I should), or Kaya, or LISP (which, as one of the oldest still in use today, is more "modern" than almost anything that has seen light ever since), or Ocaml, or even F# or something. (Any one of these can also show you that OO is not the only way of abstraction, or the best way, or, god help me, even a particularly good way.)

Re:Why not Python? (0)

Anonymous Coward | more than 5 years ago | (#24670165)

CPAN

Re:Why not Python? (1)

dltaylor (7510) | more than 5 years ago | (#24670219)

Embedded system with a very small footprint.

There was already some Perl in it because it used an easily modifiable bit of existing code. Rather than add the burden of yet another interpreter, I use Perl to manipulate text files that are a bit too clumsy in bash/sed/awk.

As for Java, there are some problems that lend themselves to class/... solutions (and, yes, I have read my copy of "Design Patterns"), but there are a LOT of small text utilities, among other things, needed in an autonomous Linux box that are a royal pain to code in OO, utterly unmaintainable when hammered into that model, and bulkier, when all of the libraries are added, than even Perl.

Pick a language that solves the problem. Sometimes, maybe even frequently, that language is Perl.

Re:Why not Python? (4, Funny)

El_Muerte_TDS (592157) | more than 5 years ago | (#24670247)

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.

Re:Why not Python? (1)

beefstu01 (520880) | more than 5 years ago | (#24670271)

What lack of readability? All my Perl stuff is very readable, and it's easy to follow what's going on. If I use a crazy regex, then I leave a nice comment saying what it does.

Just because you can obfuscate Perl to the point where you can move a mountain with one line of code doesn't make it unreadable- I can do that in any language. If you're complaining about readability, the problem probably exists between the keyboard and the chair. A good dev puts out good code, and a bad dev will make unreadable stuff.

Over here we use the right language for the job. Perl, Python, C, Java- they're all tools with strengths and weaknesses. Use appropriately and you win.

Re:Why not Python? (1)

neuromanc3r (1119631) | more than 5 years ago | (#24670281)

Regular Expressions. I love Python, it's definitely the language I use most, but its regexp support is a joke compared to perl's.

Which does not mean that it's bad, it is logical and consistent with the rest of the language, but it isn't nearly as fast and effortless as in perl

Face it, Perl IS hard (3, Insightful)

Pecisk (688001) | more than 5 years ago | (#24669971)

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.

Re:Face it, Perl IS hard (1)

Iftekhar25 (802052) | more than 5 years ago | (#24670371)

To say Perl is hard is a bit much. Actually... I'd say it's just plain wrong. I'd say it's really easy. In fact, most people say it's *too* easy. In fact, some of the things Perl does are just... so stupid it's a miracle nobody ever thought of them before.

Really tell me, why does the if statement need to be at the head of a code block, and this must be adhered to even if the world comes crumbling down? In Perl it can be put at the end of a statement, e.g., do_this() if (TRUE);

At first glance it's cumbersome, but the language is thinking like the brain thinks. I think we're just used to the *really* "hard" languages, and have trouble wrapping our heads around a language that is actually, when it comes down to it... very easy!

Every heard of the Perl Self-Answering Questions [ginini.com]? Too easy, man. Not too hard. Too easy.

Why Corp. hate Perl? (4, Insightful)

Manip (656104) | more than 5 years ago | (#24669997)

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 (4, Interesting)

QX-Mat (460729) | more than 5 years ago | (#24670003)

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 (4, Insightful)

Bryan Ischo (893) | more than 5 years ago | (#24670137)

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++.

Re:Perl too readable (1)

fishbowl (7759) | more than 5 years ago | (#24670229)

>C++ and perl are such different languages, that it's not really useful to compare them.

Off-topic, but I say this about C and C++ also.

And I've said it for years, maybe for decades, I can't remember. And over the years, having written much in these languages,
even implemented parsers and compilers for each, I say it even more vociferously. I *hate* seeing the expression "C/C++", it makes me cringe, and throw up a little to see that.

Re:Perl too readable (1, Funny)

Anonymous Coward | more than 5 years ago | (#24670273)

I totally agree in general, but your example is bullshit.

  @array = map { s/something/better/g } @data;

actually modifies the values in @data, and the result array contains the number of substitutions for each array item. Is that what you had in mind? ;-)

"Hate" isn't the right word. (5, Insightful)

jjgm (663044) | more than 5 years ago | (#24670011)

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.

Re:"Hate" isn't the right word. (1)

Meshugga (581651) | more than 5 years ago | (#24670309)

i wouldn't have written my post if i read yours first... it is more diplomatic too ;)

seconded.

Software or line noise? (1, Insightful)

Anonymous Coward | more than 5 years ago | (#24670015)

Corporations hate perl because it takes too much restraint to write maintainable programs in it. You can totally write beautiful systems in perl, but face it there are simply too many ways to skin the same cat syntax-wise and "clever" programmers seem to gravitate to the syntax and language constructs which are least readable. Yes I understand you can write hard to read programs in any language, my point is that perl seems to make it easy.

People who don't work with perl all the time don't want to open up a code base after some time and spend a pile of time researching WTF $_#&->!] means again.

No I'm not talking about regexps, and that wasn't meant to be real perl.

For goodness sake, move on. (5, Funny)

PinkyDead (862370) | more than 5 years ago | (#24670041)

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.

Re:For goodness sake, move on. (0)

Anonymous Coward | more than 5 years ago | (#24670217)

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.

The company he is talking about (the BBC) will do exactly that.

There is a lot of people making design decisions in the BBC who don't even know the basics of good software design.

With that kind of structure in place, getting any good software created is unlikely, no matter language is used.

Re:For goodness sake, move on. (0)

Anonymous Coward | more than 5 years ago | (#24670225)

only the usual non- static trained "programmer" makes such an idiotic statement as usual.

This isn't just about "new and shiny" (3, Insightful)

wyldeone (785673) | more than 5 years ago | (#24670063)

While it's possible to write readable code in any language (well, maybe not Brainfuck [wikipedia.org]), and just as possible to write horrible spaghetti code in the same, Perl does not encourage clean, readable code like python or ruby (my preference.) As a result, nearly all of the perl code I've seen has been virtually indecipherable to anybody not a perl veteran. More modern scripting languages like ruby and python not only have "syntactical sugar" that allows complexities to be expressed more simply (and therefore, more readably) but in general discourage things like the perl super variables that radically decrease readability. Additionally, their object-oriented structure allows for more clear code organization, making 100,000+ line programs possible to understand (look at rails, for example; hundreds of thousands of lines of code, but readable for someone without great knowledge of the codebase).

This is an insult (4, Funny)

Skapare (16644) | more than 5 years ago | (#24670071)

This is an insult to associate us Perl-Haters with corporate types.

Re:This is an insult (1)

Hal_Porter (817932) | more than 5 years ago | (#24670331)

Yeah, I hate Perl and corporate types too.

Come to think of it, I'm not also hate people that hate Perl or corporate types. And I hate people who hate people that hate

STACK OVERFLOW

Management (1)

Pvt_Ryan (1102363) | more than 5 years ago | (#24670079)

Management are blaming Perl for the problems when really they should be blaming the management and design procedures that were in place (or, more likely, werenâ(TM)t in place) when the code was originally written.

I think this is the key paragraph. Everyone knows that management can't blame management that would imply they were in the wrong

You have to deal with reality (1)

Chuck Chunder (21021) | more than 5 years ago | (#24670099)

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.

The latter may be true but you have to realise that it probably always will be.

You can dream of an improved development environment, you can even take steps towards one, however the simple fact is that in 99% of the situations there are real development pressures that make "piecemeal development", inadequate attention to design, poor attention to coding standards and countless other problems an inevitability.

Once you accept that sad reality the decision to avoid Perl for something less impenetrable makes sense.

Perl may not be the cause of the problem but it can certainly compound it.

Nothing wrong with PERL (0)

Anonymous Coward | more than 5 years ago | (#24670109)

There is absolutely _NOTHING_ wrong with perl, and compared to shell scripts it is natively cleaner.

You can write good, and bad programs in any language, which is why academic language development, eg Worth, has been such a waste of time. Perl, in contrast, was designed by a group of exceptionally capable programmers and mostly does the right thing by default.

Like any language, perl can be mis-used but so can C++, Java and Python. Indeed the more complicated the language, frame-work or toolkits become the more they are prone to mis-use and the more duct tape eg design patterns aka example/template solutions seem to be required to get anything done. The extream of this is where the language/framework requires so much boilerplate code that you need an IDE to generate it. Think Java J2EE.

dynamic Lang (0)

Anonymous Coward | more than 5 years ago | (#24670129)

Any dynamic language faces this problem . They're good for glueing apps or writing quick scripts, but for enterprise applications of any significant size it's kind of a joke to have something in php or perl, ruby. For small web 2.0 or text prcessing web sites I can the benefit on the small scale, but...the dangers of dynamic lanuages when you're sharing code in an enterprise, particularly doing calculations, is just too great.

Re:dynamic Lang (2, Informative)

fishbowl (7759) | more than 5 years ago | (#24670265)

I worked in a shop that replaced a really complicated process that had been written in COBOL, with
a really efficient, compact, regex-based, DBI-enabled perl program. I'll let you explain to them
why that's inappropriate for their enterprise scope... :-)

Writing bad code (4, Interesting)

Phroggy (441) | more than 5 years ago | (#24670133)

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 (4, Interesting)

jimicus (737525) | more than 5 years ago | (#24670171)

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? (5, Insightful)

MaX_3nTrOpY (629785) | more than 5 years ago | (#24670187)

"I realized at that point that there was a huge ecological niche between the C language and Unix shells. C was good for manipulating complex things - you can call it 'manipulexity.' And the shells were good at whipping up things - what I call 'whipupitude.' But there was this big blank area where neither C nor shell were good, and that's where I aimed Perl."
-- Larry Wall, author of Perl

I rest my case.

I don't get it (3, Insightful)

RichiH (749257) | more than 5 years ago | (#24670189)

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.

I hate perl too (1)

Evildonald (983517) | more than 5 years ago | (#24670209)

I hate most programming languages with weak types, vaguely defined variables and ambiguous functions like "chomp"

Re:I hate perl too (1)

Paolone (939023) | more than 5 years ago | (#24670251)

chomp is not ambiguous. RTFM and stop crying.

Re:I hate perl too (1)

Evildonald (983517) | more than 5 years ago | (#24670301)

ambiguous: open to or having several possible meanings or interpretations

Either you don't know what ambiguous means or you only know the word chomp to mean "Remove trailing CR/LF"... in which case I recommend RTFDictionary.

Re:I hate perl too (1)

Iftekhar25 (802052) | more than 5 years ago | (#24670321)

Variables can be vaguely defined, or they can be done nice and neatly. And chomp is very well-defined, and a damn useful function, thank you very much!

Perl gives you the flexibility to be a slob, or to be prim and proper. It gives you a choice rather than putting you in a straight-jacket which helps prevent you from pulling your own eyes out, but you now you can't eat!

The fact that most people out there are slobs doesn't reflect poorly on a language that is otherwise a pleasure to work with, and very intuitive.

...and the wisdom to know the difference. (1)

SuperKendall (25149) | more than 5 years ago | (#24670223)

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..

That's fantastic. Given your assertion is 100% correct, and you cannot change the practice of companies ALWAYS developing code piecemeal over a number of years with no single consistent design authority - what variable is left to alter?

Perl is dead (1)

Meshugga (581651) | more than 5 years ago | (#24670269)

(or rather: should be)

Let me explain:

First, and foremost, perl encourages via its programming culture (does the acronym TIMTOWDI strike terror in your head?) and through its design obscure programming. Thus, the risk of resulting unmaintainable code is very high.

Second, perl is technically a hybrid of different programming paradigms. This does not only add to the complexity and the before mentioned risky "TIMTOWDI" behaviour, but it more often than not gives perl coders who need/want to work in an existing perl environment a huge headache. The colleagues do it differently, they have been, for years.

Third, perl is highly deficient in what i would call "semantic integrity". It is like speaking a language with an unusual high percentage of phrases, lexical and grammatic exceptions.

Fourth, perl has a huge history. A history so large and moved that it carries a lot of weight of past programming paradigms, do's and dont's, hacks and "boobytraps". No business decision can be based upon that.

Fifth, perl is slower, bigger and consumes more memory, and does not offer bytecode by default. This, again, is not the fault of the perl maintainers, but the of the dead freight perl is still carrying for compatibility purposes and the lack of "one" way to do things.

Sixth, perl has a weird typing concept, which encourages misuse. (Hey, no other scripting language i know uses a library-include to render typing useable...)

Seventh, and this is nourished by my own experience, there is the phenomenon that you get much better (in terms of maintainability) perl code if you hire programmers who do not primarily program perl. This is weird, but my observation suggested, that this is because they don't tend to give in to certain sugar perl offers and use paradigms like OO more straight forward. The perl-enthusiasts I met as job applicants, who were altogether very capable programmers, were kind of proud of their obfuscated perl code. So proud that a lot of them even put it in their application (which was of course rejected prematurely).

Perl has done great, and I mean really GREAT things for the internet, for script language evolution and for businesses.

But it is time to let go, really.

"nearly all of the perl code I've seen has been vi (1)

thoglette (74419) | more than 5 years ago | (#24670291)

nearly all of the perl code I've seen has been virtually indecipherable to anybody not a perl veteran

Of course this is the reason that Lisp has died as a web-app tool. It requires a clue. :-)

Add:

  • Shiny New Languages
  • Shiny New Buzzwords
  • Clueless universities teaching Java or VBasic (instead of Lisp)
  • A decade of poorly designed, poorly written, poorly tested and generally evolved code. And did I mention we outsourced it for a while a few years back?

Yup, it's the language's fault that our boring, me-too web application sucks:-)

Seriously, the whole Perl 6 thing has been a bigger problem: the brighest and best have been playing "Perl the Game" rather than making the language more useful. Consider XML/Xpath processing: the existing CPAN modules are "somewhat behind the cutting edge". To put it kindly! And comparisons between the web frameworks for Perl vs The Others is even less flattering.

Keep in mind, Perl is *not* easy (1)

X.25 (255792) | more than 5 years ago | (#24670299)

PHP is shiny. Perl is not.

People like shiny things.

(and I love Perl :)

Oh Brother I Hear You! (1)

Iftekhar25 (802052) | more than 5 years ago | (#24670303)

I work at a company (right now!) that developed it's own in-house framework on Perl. It's written in Chinese for all I know, there are portions of the system the IT head tells me not to look into. It's a black box. It works, so we don't touch it, we don't look at it. We don't think about it, in case something snaps and sends the system crashing.

I was code surfing once and came across 2-d arrays. I asked my boss, and he's like, oh, yeah, it gets even better: there are 3-d arrays in there.

The system is currently a black box. The business poured significant amount of money back in 2001 when the system was designed, and the company's been milking the productivity it gets out of the system. As new projects come up with new features and functionalities, the system is more strained, and we do more workaround and hacks, until we forget where the system ends and the hacks begin.

From a business standpoint, the management won't invest in a new system, Perl or otherwise, because that's additional costs for a system that *was* designed, they thought, back in 2001. They're not interested in listening to strange terms like "architecture" and "design." They hold the keys to the safe, so here we are, working on a project on a crumbling old system not designed to do anything like what we need it to do.

Boy, oh boy, I'm sending this article to my boss. And bro... I hear you. I love Perl, what a damn beautiful language to code in. Sure, you need to set the ground rules or people will run amok or write one-way code, but it's such an absolute pleasure to work with. But the language, nor the programmers who love working with it, get much respect.

It's not about perl (0)

Anonymous Coward | more than 5 years ago | (#24670313)

You see this process all the time in companies that have a lot of old code. Companies start associating problems related to these systems and their age with technologies underneath.

It does not matter if it was written in perl, COBOL, common-lisp or C++ ... it has happened countles ammount of times - you slowly start relating problems of a particular application with programming language or a framework and then thinking that you can't fix the problems without changing that part without throwing out the baby with the bath water.

If you want to keep the language alive - the most devious solution would be associating problems with some innocent but old perl libraries, or making your company switch web frameworks, so they would have something to blame for the old problems. Because making them realise that problems are induced by age of the application, might be just too difficult, and even then you would either have to prove that fixing old stuff is better than rewriting or that they should stick to perl for the rewrite. And all of these are social problems - not thecnical ones.

Perl was never intended for that (1)

aaaaaaargh! (1150173) | more than 5 years ago | (#24670337)

Perl advocates nowadays might deny this, but at least in the beginning Perl was never intended to be used for anything more than providing quick scripting solutions for text processing tasks to the lazy programmer. And there is nothing wrong with that, it's better than awk. When a language becomes popular, people start using it for purposes it was never intended for, and it's only fair that the mindless corporate drones don't want to encourage that. Moreover, the average manager type can barely understand a line of Perl, but is probably convinced that he could do Python programming better than professional programmers. Then, of course, Perl will be discouraged.

Personally, I stopped using Perl 10 years ago, so I don't mind.

Obligatory language flame part: By the way, Python sucks, too. I mean, "duck" typing", that's just crap. Use mzscheme instead.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...