Please create an account to participate in the Slashdot moderation system


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 internet speed test! ×
Perl Programming IT

Perl's Glory Days Are Behind It, But It Isn't Going Anywhere 379

snydeq writes "Deep End's Paul Venezia waxes philosophical about Perl stagnancy in IT. 'A massive number of tools and projects still make the most out of the language. But it's hard to see Perl regaining its former glory without a dramatic turnaround in the near term. As more time goes by, Perl will likely continue to decline in popularity and cement its growing status as a somewhat arcane and archaic language, especially as compared to newer, more lithe options. Perhaps that's OK. Perl has been an instrumental part of the innovation and technological advancements of the last two decades, and it's served as a catalyst for a significant number of other languages that have contributed heavily to the programming world in general.'"
This discussion has been archived. No new comments can be posted.

Perl's Glory Days Are Behind It, But It Isn't Going Anywhere

Comments Filter:
  • Re:Wait, what? (Score:5, Interesting)

    by girlintraining ( 1395911 ) on Tuesday January 29, 2013 @06:29AM (#42723987)

    Perhaps a few mandatory rules could fix this problem? Doubt it though because it seems PERL programmers seem to value code over hardware..

    You're blaming poor programming on the language. Perl isn't meant to be a replacement for, say, C, but considering its an interpreted language, running at 1/56th speed of compiled code is not bad []. The author here mentions PHP, Ruby, and Python. A separate analysis [] reveals that PHP is worse. The others are only marginally better because they have a specific function by that particular benchmark test optimized. A separate and equally simple benchmark has Perl on top []. I'm sure many will be able to come up with more comprehensive benchmarks, and then a flamewar will erupt... But my point (soon to be lost forever in the ensuing tsunami of replies) is that the usage scenario determines language performance, and in many usage scenarios, Perl is the winner amongst the author's picks. Don't blame the language because the programmer either (a) uses it incorrectly or (b) uses it for something other than it was designed for. Perl is fundamentally about string manipulation and I/O between various datasets and is a high-level language. If you aren't using it for that, you're doing it wrong. Not to say it won't work... but it's not the Right Thing.

  • Re:Wait, what? (Score:5, Interesting)

    by girlintraining ( 1395911 ) on Tuesday January 29, 2013 @06:38AM (#42724031)

    It's not failing because it's not changing, it's failing because less people are using it.

    Compared to the alternatives the author suggests? Ruby and Python combined are doing less than Perl. PHP is the runaway favorite [], but if you dig into the numbers, you'll find that most of the change is due to Content Management Systems which by and far have been developed on PHP. So these massive zomfg numbers PHP is pulling in isn't due to people programming with it as much as they are copy-pasting it en masse.

    Perl is often custom back-end stuff with little visibility. It runs in cron jobs. It happily links various back-end pieces to one another... doing its unglamorous jobs with ease. Yes, Ruby is pretty and shiny. Yes, Python is a hot thing right now. But I've developed for all of them, and you know what? Perl is still what I'd turn to for back-end work over either of them because it's easy to work with and in many use scenarios I encounter professionally... faster as well. Python starts to choke (badly) in a take-down-the-server kind of way when it gets taxed. Ruby is the same way. But Perl seems bulletproof... even in a resource-constrained environment, it just. doesn't. die.

    And for me, writing code for corporate use... Reliability trumps shiny any day of the week.

  • Re:Wait, what? (Score:4, Interesting)

    by girlintraining ( 1395911 ) on Tuesday January 29, 2013 @06:44AM (#42724049)

    However with faster systems and lower cost or free databases available, Perl need has declined.

    I don't think that's what's driving the numbers down; It's the Web 2.0 culture. There are a lot of self-contained solutions (such as content management systems) built on PHP, etc., that pretty much you unpack into a directory, set the permissions and tweak a config file, and you have a usable app. Perl was never about that. Perl is like duct tape -- you use it to glue things together.

  • by guacamole ( 24270 ) on Tuesday January 29, 2013 @07:21AM (#42724215)

    Perl is certainly right for sysadmins. First, Perl borrows heavily the ideas/syntax/cues from the standard unix shell scripting. I am talking about writing scripts with bash, awk, sed, grep, find, tr, etc. If you know them, you will fee right at home. Perl glues the ideas of all of these tools together into a more consistent syntax, and runs much faster than the speed most shell scripts could ever achieve.

    Another important issue is the community. Perl community is filled with people who do system administration (not that there aren't other users of perl), so there are tons of libraries, which are available to use as easily as starting Perl's CPAN shell and having it install them automatically. The best book to learn Perl is Larry Walls "Programming Perl". A new edition just came out.

    Having said this, I want to mention a that it's a good idea to develop a good sense of judgement. For example, I always got annoyed by some fanboyish coworkers who wrote Perl scripts when a simple shell script would suffice. I have seen perl scripts that are filled with calls to external shell commands, cp and rm and so on which I thought was stupid. (Need a shell script? just write a shell script). And I still loving using awk and similar tools for writing most of "one-liners". I always found awk to be a bit better suited for that than perl. On the other hand, know when to start writing Perl script instead of shell script. Shell scripts can get clumsy very fast.

    Another advise, you may also want to check out Python. I was a Perl person, and recently looked into Python, and lo an behold, I am very impressed. In my opinion Python sets a new standard in cleanness and readability. Take a look at the free book "Dive into Python" as well as the official Python 3 tutorial online. Both are short and can be covered in just a few study sessions. Still, in sysadmin world Perl may be more useful, but Python is a great all-around general purpose language.

    To see what I mean, take a look at this discussion []

    compare the tidy Python code at the top with the proposed Perl solutions below.

    Finally, the most striking tool I have used when working as a sysadmin was CFengine. It's the bomb try it. It's a very high level declarative programming language for managing large sites/infrastructures.

  • Re:Wait, what? (Score:4, Interesting)

    by rgbatduke ( 1231380 ) <rgb&phy,duke,edu> on Tuesday January 29, 2013 @07:44AM (#42724317) Homepage

    And C is the best to write operating systems (and a lot of other stuff) in and APL is actually pretty nifty for writing certain kinds of vector code and...

    Personally, I still love Perl and use it by preference when I need a short one-off program that doesn't have to be fast, especially one that does a lot of parsing. It is a great on-the-fly translator, and is often used to facilitate data conversion of one sort or another because it is so easy to use for that purpose. I have written far more complicated stuff -- actual interactive GUI applications -- in Perl, but that's where one is probably pushing it outside of its area of primary utility and I probably won't do that again. And yeah, one of the best features of Perl is its ability to split lines and do regex processing in a syntactically compact way. Tools like awk/sed/bash are also very useful for doing simple stuff -- pattern matches and substitutions -- but sed rapidly becomes arcane to the point where one has to keep a library of sed 1 liners or examples handy to remember how to pull the third octet out of an IP address, add 24 to it, and write it back or the like. In Perl doing this takes several lines of code (if you want the result to be readable) but it is easy and robust to code and understand. I used to use awk a lot (15-20 years ago), but Perl completely superceded that. I do still use sed simply because s/aaa/bbb/g is so damn useful on the fly, more so if you chain several sed conversions and other stuff together in a pipe. But once the complexity passes a fairly low threshold, Perl is very much a tool of choice.

    Of course it is not unique. Nowadays, lots of people like other similar languages e.g. python that serve more or less the same space. But arguing about which of the available languages is "best" is a fruitless exercise. Philosophically they are very different. Some people like what I would call "fascist" languages (where python is in that category IMO) with strict rules on e.g. indentation and structure. Some people like loose, free languages that don't care how you indent and use brackets instead. Some people like procedural languages. Some people like object oriented languages. Some people are agnostic and like languages that do both, each in its place. And whatever the programmer likes, there is also the task -- some tasks manipulate data or perform computations in procedural ways, some work with data objects.

    Personally, I think any rumor of the demise of Perl is likely exaggerated and premature (and I'd want data to support it!) I use it all the time, and obviously I wasn't surveyed. A lot of the rise and fall of scripting languages is dictated by what schools are teaching and what people need in jobs, and these days it is dominantly java (or javascript), python (because it is easy to teach structured programming in python), php (because it enables web programming), and even "html" (which isn't really a programming language but so what). For web programming -- a major if not the major marketplace for programmers -- and even for database programming (web interface to database) this set makes sense. Perl was popular early on for writing web scripts because it worked, but it wasn't really designed for that purpose and languages that were (but were otherwise remarkably perl-like) eventually won out. So what? That wasn't what Perl was written for, and it's not what it does best.


  • Re:Wait, what? (Score:4, Interesting)

    by Viol8 ( 599362 ) on Tuesday January 29, 2013 @07:54AM (#42724363) Homepage

    "I think Perl's biggest problem is it's liberal use of $ % @ etc operators in variable names. I like them. They're there for good, cool reasons;"

    No they're not. There is no good reason for having to tell the interpreter the type of the variable once its been created. It should already know. Its just pointless noise that doesn't need to be there and reduces readability. The reason shell script does it is because it needs to know if its a variable or program name, perl doesn't have that restriction.

  • Re:Wait, what? (Score:3, Interesting)

    by cmdr_tofu ( 826352 ) on Tuesday January 29, 2013 @08:37AM (#42724573) Homepage

    First off, I love Perl, but I hate it too. All of my backend code used to be Perl, but I long since abandoned it for Ruby. Now when I have to use Perl, it's usually called from a Ruby script and I real the Perl output into Ruby through JSON.

    As far as performance is concerned, i think Python is really a top contender with native thread support, but generally for sysadmin stuff, you don't always need a high-performance solution. For something that is easy-to-write, and easy-to-manage, and almost more importantly easy-to-read-the-code-2-months-later, Ruby is great. I have nothing bad to say about Perl, but there are clearly some advantages (when using objects especially) to Ruby and Python. The Perl community ( is the best programming community I've ever come across. The only reason I even switched to Ruby was because I believed that Parrot would bring a convergence and interoperabilty between Perl 6, Ruby and Python.

    If Perl becomes less relevant in the future it would make me sad.

  • Re:Wait, what? (Score:4, Interesting)

    by laffer1 ( 701823 ) < minus punct> on Tuesday January 29, 2013 @09:02AM (#42724743) Homepage Journal

    I don't think less people are using Perl. I think young people aren't using perl. The hot thing is Python and JavaScript solutions for everything. Python can be used for GUIs, crazy admin scripts, etc. It can be used in place of Perl, but it will never replace Perl. Python doesn't have CPAN. Python code is just as bad as Perl code sometimes, because people who use both languages are sometimes too clever for their own good. Personally, Perl makes more sense to me than Python. I get why people like Python, but it's not for me. After trying to port it to MidnightBSD, I had to look inside and I was not impressed. Then there's the whole Python 3 thing... too many people still use Python 2.x. Python 3 is what will happen if Perl ever actually goes to 6.0 (mainstream). You'll have a fork and then death of the language long term. It's only a matter of time. I think the Python community either has to go back to 2.x or kill security updates on it so it forces people to adopt 3.x.

    No one has ever shown me a feature in Python I can't live without. I would never write a GUI in Perl, but I also think it's ridiculous in python aside from prototyping. If you want evidence of why I feel that way, look at many Gnome projects. I have done it once as a script to create PDFs of web pages with their actual rendering from WebKit bindings for my previous employer and I got a bad taste in my mouth.

  • Language Design (Score:5, Interesting)

    by YojimboJango ( 978350 ) on Tuesday January 29, 2013 @10:12AM (#42725321)

    I wrote this a while ago, but I find it's useful to post it here:

    The precondition that you can write terrible code in any language is a mental diversion. You must design languages for people that believe in intelligent design.
    If there is low hanging fruit in your garden of eden, people are going to assume that someone vastly smarter then they are placed it there for plucking.
    Not even God himself coming down from on high and face to face telling every member of the human race not to touch it is going to keep it from being abused.
    That is the true nature of humanity and by inclusion programmers.

    perl: An unorganized, but sprawling garden full of almost every imaginable fruit. Regex is a shiny sinful apple at eye level on every single tree. The only way to navigate the garden is to ask the snakes.
    python: An organized garden that has one of each kind of fruit. But it's half way through being dug up and replanted into an even more organized garden.
    ruby: A newer garden. Heaps of fertilizer make everything grow incredibly fast, but the trees are getting tangled and there's a problem with weeds.
    c#: Someone spent a lot of money crafting this garden correctly. They also planted trees that emit a hypnotic pollen that will murder you if you try to leave the garden.
    java: A beautiful garden but only when viewed from space. Every tree has exactly 1 fruit, and getting anywhere takes forever. Recently taken over by someone interested in c#'s hypnotic pollen trees.
    c++: An industrial farm complete with tractors and combine harvesters, but no safety equipment. As a bonus 98% of the farm does not contain buried land mines.
    c: A plot of land and a barn full of seeds. Get to work.
    javascript: There's only 1 tree and it grows upside down, but you can find it resurfacing in all the other gardens. It's also sentient, growing rapidly, and trying to murder you.

Philosophy: A route of many roads leading from nowhere to nothing. -- Ambrose Bierce