http://www.perlmonks.org?node_id=526866

We often hear the comment, "No IT Manager ever got fired for picking Java." Why is this? Java is considered a safe choice because it can solve many problems and it has sufficient market penetration that it currently is not viewed as a risky choice.

I compiled the following in an attempt to show that no IT Manager should ever get fired for chosing Perl either. I am not trying to write a justification for why Perl is the best choice for any given IT task. Rather, I believe the evidence listed below shows that it is a perfectly acceptable choice and should be considered on even ground with other possibilities.

Given this information, a responsible IT Manager should proceed to select a language or programming platform based on things that actually matter like the task at hand, the budget, the current skills of the target coders, the current environment, etc.

I present it to you, esteemed monks, for input and review.

Aptitude for the task:

Market penetration:

The main point of these stats is that Perl has a large and broad user community. With any technology you choose, you don't want to be the only one using it. These numbers show that Perl is still widely used for web development, among other things, and the user community is very active.

Notable Perl users:

Perl is used by Amazon, Google, Yahoo, and Ticketmaster.

Cost:

Perl, Apache, and related technologies are open source and free. On-going overhead cost to vendors for code that continues to run is $0.

Open Source:

Book sales:

Recent Bookscan stats show Perl at roughly three times the number of sales as Python, ten times as Ruby, and half as many as PHP.

O'Reilly Media is very much driven by numbers and they felt the Perl book market was strong enough that they published 4 new Perl titles last summer alone. That is a large number of books for a relatively small tech publisher to devote to a single language.

Job Openings:

There are many sites on the internet that post Perl jobs and they all more or less reflect the numbers listed at http://jobs.perl.org/about/stats

Some other jobs listings:

Basically, the number of companies listing Perl as a job pre-requisite is large relative to other technologies and has been consistent.

Active development:

Perl continues to be actively developed. Many developers are working on Perl 6, the next major version of the language. At the same time, dedicated teams continue to fix and augment the Perl 5.6, Perl 5.8, and Perl 5.10 releases. Many companies would have de-supported these version rather than maintain them. The fact that you can safely continue to use a production release of an older Perl without being forced to upgrade is a strong feature.

Release dates are available here: http://perldoc.perl.org/perlhist.html

Perl is also very mature and stable, and has been running on large production systems for years.

Other sources for Perl information:

Nice summary here too: http://perltraining.com.au/whyperl.html

Update: Clarified that mod_fastcgi is not Perl-only and started a list of other jobs sites.

Update: Changed 'fix' to 'modify' in the Open Source section.

Update: Now posted here http://www.perl.org/advocacy/whyperl.html also.

Replies are listed 'Best First'.
Re: Why Perl is a Valid Choice
by brian_d_foy (Abbot) on Jan 31, 2006 at 21:50 UTC

    Lately I've been busy correcting the work of lots of unsupervised programmers, and I've come to think something different about this whole debate. It's not the tool that matters, but the people choosing the tools. Their decisions are not rational or based on technical merit, and we can't solve this problem with reason or merit. There are good reasons to choose Java for some things, just like there are good reasons to choose Perl for other things, or even Python or Ruby or something else.

    The problem doesn't have much to do with the language. It's a failure in management. Now, I know the you (Jim) use Perl in your department, but that you also have regular training for everyone, comprehensive code reviews, and that you follow the technology. Not too many places I run into seem to do that, even at the technical worker level.

    Thinking about that, and after listening to an interview with AT&T's Ed Amoroso, and probably after reading a bit too much Joel Spolsky, led me to think that the lack of management is the problem in these cases. Aside from the usual, puerile generalizations about pointy-haired bosses, in my fire-fighting work I've noted several things that set up the problem. (Update: I'm not generalizing about managers, just some patterns of behavior I've seen from some people in those positions. Being a manager doesn't mean you do any of these things :).

    • Managers who don't know enough to do it themselves, and they put too much trust in what the code cowboys tell them
    • Managers who don't have a strong technical background, but they like to think they do (Ed's comments here are interesting)
    • Managers who don't enforce proper coding standards, or don't even have any
    • Managers who don't make their technical people learn more
    • Managers who don't give their subordinates the opportunity for formal training (in any subject)
    • Managers who don't know how to measure productivity
    • Managers who can't or won't solve personality disputes between developers
    • Managers who don't make their team work as a team
    • Managers who don't build a team with diverse skills and use workers are commodities
    • Managers who are afraid to piss off the tech guys
    • Managers who want to be liked
    • Managers who don't want to work
    • Managers who ultimately want to protect their ego

    There are all sorts of reasons why any of those things might be true, and not all of them are bad or even the manager's fault:

    • Ill-conceived company policy
    • Limited dollars and resources
    • Lots of work, not enough people
    • Fear of losing good employees because they might get better jobs if they knew more
    • Time wasted in useless meetings
    • Incompetence
    • ...and so on...

    No language is going to solve any of those problems, but I've heard many Java proponents say that they can take mediocre programmers and turn them loose without worrying about them. The problem there isn't Java, it's the lack or worry (which you should really read as "supervision"). Managers don't want to manage.

    A language like Perl, however, just makes the management problems more apparent, mostly because Perl doesn't let you blame some things a Java programmers gets to blame (and sometimes with good reason).

    • the JVM
    • the browser
    • the operating system
    --
    brian d foy <brian@stonehenge.com>
    Subscribe to The Perl Review
      • Managers don't know enough to do it themselves, and they put too much trust in what the code cowboys tell them
      • Managers don't have a strong technical background, but they like to think they do (Ed's comments here are interesting)
      • Managers don't enforce proper coding standards, or don't even have any
      • Managers don't make their technical people learn more
      • Managers don't give their subordinates the opportunity for formal training (in any subject)
      • Managers don't know how to measure productivity
      • Managers can't or won't solve personality disputes between developers
      • Managers don't make their team work as a team
      • Managers don't build a team with diverse skills and use workers are commodities
      • Managers are afraid to piss off the tech guys
      • Managers want to be liked
      • Managers don't want to work
      • Managers ultimately want to protect their ego
      There are some generalisations there that I'm not entirely in agreement with - remember, managers are people too. But your comments reflect something that I've been fulminating about for quite a while.

      Take a look at any job advert for an IT manager. What characteristics are they asking for? Line management experience obviously, but primarily business management skills, budget management skills etc. Technical comprehension is *way* down the list, on the rare occasions it even appears. It's my contention that to provide a good standard of service an IT manager must have a good technical understanding, as well as an understanding of business priorities. Not that an IT manager must be a world class coder, or a top notch oracle DBA; but he or she should at least understand the issues, comprehend software life cycles, testing principles, and be able to see without assistance where code can do one thing easily, and another with difficulty.

      That list is specific to managing coders, but the same principles apply to managing an internal IT department. Most IT managers make choices based on sales pitch, not on technical suitability. You don't have to be Donald Knuth to understand the relative merits of different products, you just have to have some understanding of them.

      Underlying this IMO is the fact that technical expertise is largely devalued by business people, so the business managers (possibly the board) who appoint the IT manager want someone with the same skills as them. The fact that they have half a dozen accountants who can manage a budget in their sleep, but no one who can tell them why a server costs more than a desktop doesn't seem to matter.

      In my perfect world, the IT manager would be a business oriented person who can code, but probably not very well. Someone who can meaningfully translate between business priorities and technical feasibility (am I bitter about not making the shortlist? You bet I am).

      But that isn't happening any time soon, so (to return to the topic of the thread) if we want to promote Perl to the people who make the language decision, we need to put cbrandtbuffalos very well thought out, and crucially non technical article in front of them - very few of them visit PM, in case you hadn't noticed. How can we do that? Suggestions are welcome, but perhaps identifying the right magazines, getting the right journalists on side, and getting well written, business oriented (not technical) case studies and articles out there.

      --------------------------------------------------------------

      "If there is such a phenomenon as absolute evil, it consists in treating another human being as a thing."

      John Brunner, "The Shockwave Rider".

        The way I've addressed this issue of technical and non-technical managers is to try to champion Brooks' The Mythical Man-Month. Despite the age of the book, his conclusions are as amazingly relevant to coding today as they were when he wrote them.

        The bit that I've pulled out and harped on is that there should be two advancement paths within a technical department: project manager and technical manager. Both need to be equal paths, and people with equal experience and skill in each need to be treated equally in the company (authority, pay, etc.). Each significant project should have both a project manager and a technical manager assigned and they work together, each focusing on their expertise.

        This has been very successful in our shop. We have several people who are certified project managers and do their job very well. They handle allocations, schedules, and dealing with stakeholders. I work as a technical manager where I keep my hands out of the project management software and make sure the technical challenges of the project are taken care of. I know about other projects going on, I help with code reviews, and I make sure coders know about all of our shared code and best practices.

        You can't get this to work everywhere, but I feel rewarded for plugging away until we tried it. And the success has kept it going. The project managers really like having someone on the project whose job it is to know the technical bits. And I feel my time is better spent away from Gantt charts.

        As for you other point, I thought about working this into something that we could share somewhere else. I just wanted to vet it through perlmonks first. I'm in The Perl Foundation, so maybe I can ask about throwing up a page on the TPF site somewhere.

      Lately I've been busy correcting the work of lots of unsupervised programmers

      Hmmm. Maybe Perl::Critic needs some greater publicity as an automated management tool. :-)

      -xdg

      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

        I don't think this is a technical problem, or one that we'll solve with technology. It's a people problem. If you already have a bad situation, an automated tool isn't going to make it any better. I know you said this with the smiley face attached, but the problem isn't the language. By the time people get to quibbling about the actual code, they've already passed through most of other problems that allowed that to happen.

        The best thing that people can do, I think, is work together. Programmers (or any other sort of worker) aren't veal calves to shove in cubicles. Although I won't go as far as recommending company retreats, people in the same organization should know each other, and know what other people are doing.

        For managers, this means actually inspecting the work of their subordinates and tracking its progress. You don't do that with an automated tool. You actually have to look at the code, and you have to think about it in terms of everything else. It's not just the syntax that's important, but how it relates to everything else. What does the code let you do? More importantly, what does it keep you from doing? What decisions does the code make for you if you allow a certain design?

        A good manager could use Perl::Critic, but tools don't and won't make good managers.

        --
        brian d foy <brian@stonehenge.com>
        Subscribe to The Perl Review
      • Managers are afraid to piss off the tech guys
      • Managers want to be liked

      I've worked at a job where the problem was the exact opposite of these two statements -- the director of the department had been a consultant -- he believed that the solution to any problem was to throw bigger hardware at the problem, and that the tech folks were just an annoyance that he had to deal with.

      Because he came from a semi-technical background, he thought that he was instantly knowledgable in all things technical. I don't know about you, but I don't want an ear-nose-and-throat specialist performing open heart surgery on me. Likewise, someone who designed a Citrix solution for the company might not have the necessary skills to deal with a 35k user mail system. (hell, he didn't even have the skilsl to design a replacement Citrix solution years later, when the Citrix consultants were trying to explain that the system ran best on faster dual processor machines, and he had already blown the budget on quad processor machines that he got a good deal on (and were discontinued shortly after he bought them)).

      In this case, the management only cared if they were liked by other management folks -- they couldn't care less about the people who worked around the clock for 2 weeks straight to try to repair a mail system that had tanked. (but of course, it was the system w/ student's accounts that went down, not the one with faculty and staff, so it wasn't that big of a deal)

      When I was appointed 'technical oversight' for a project, whenever I raised an issue with a solution that our director had proposed, I got bitched at, and told I was wrong. (the director had actually threatened multiple staff members, and I heard that there was a meeting that he tried taking a swing at one of my former managers). I was informed after I was fired that he had told one of my project managers to try to force me out.

      I'll agree on some of the reasons for such occurances, but we had 12 'UNIX administrators', the most of whom sat idle, and there were two of us who did the majority of the work, because we actually delivered. (but although we were the only two focused on development, they left us doing production support, and then got pissed off whenever a schedule slipped) They spent lots of money on training -- they even sent managers to training, but didn't bother sending the people who were actually maintaining the particular systems because they couldn't risk having those people out for a week.

      Money wasn't really an issue, either -- management would go to the board of trustees, explain how they needed another $1.5mil, and when the quote turned out to be lower than they thought, they'd just buy more systems than needed (to sit in a store room for more than a year) ... and of course, there'd be no budget left for disk upgrades because of it ... well, there was money spent on disks, but they went to a different project, so we didn't have the necessary disk space for our project.

      In this case, the director wanted to micro-manage -- he specifically kept overriding what my managers (yes, I reported to more than one ... I asked for clarification once, and he told me I took orders from any manager who had an emergency, and he refused to elaborate on what qualified as an emergency, and who made the judgement)

      ...

      So yes, I'll agree on the management incompetance, but there are a few, possibly outlying cases where managers try to rule by fear, and/or spend the time sucking up to their superiors (when they're not playing Jedi Academy at their desk), and couldn't care less about being liked by their underlings or even trying to do a semi-competant job -- just the appeareance of doing one to their superiors. And they're perfectly willing to piss off the tech guys, if it means they'll go away, so they aren't around to expose their lack of knowledge.

        I've worked at a job where the problem was the exact opposite of these two statements -- the directory of the department had been a consultant -- he believed that the solution to any problem was to throw bigger hardware at the problem, and that the tech folks were just an annoyance that he had to deal with.

        I've had similar experience.

        Some of the very best managers I've worked with have been completely non-technical. Some of the very worst managers I've worked with have been ex-techies.

        In my experience the divide between good and bad management has very little to do with technical experience, and a lot to do with being able to trust people to do their job well and remove the things that stop them doing it.

      Let me just update you all with my personal experience.
      Mostly we use Perl . Our top managent decided to start few projects in Java, very recently.
      I casually passed this information to one of my friends, who is a Manager in a good Software firm. He advised me Not to go with Java, and his reason was purely Non-technical. Java professionals are in high demand and hence they don't stick to one place for long time. This makes project very unstable and Manager has to spend sleepless nights in planning hand-over and recruiting the similar talent.
Re: Why Perl is a Valid Choice
by fluffyvoidwarrior (Monk) on Feb 01, 2006 at 05:44 UTC
    Back in the early days of the internet... long, long ago.
    The big rule was that no website a browser visits can ever run code on the client system (except browser limited scripting). In order to allow an "enriched user experience" to be supplied to basically unsecure windows systems owned and run by people who have little awareness of security we have gone away from this basic rule. I have encountered client systems trashed (I believe) by java code unwittingly accepted from the web. I've also encountered many systems trashed from the web because windows users routinely run with less tight security than they should because if they don't loads of "enriched experience" sites won't work. Don't websites realise that when many users are faced with "download plugin" or "update JVM" they just go somewhere else less threatening. I don't see how a similar scenario can ever be brought about by cgi/perl because of the way the whole thing works (ie. as it was originally envisaged by the wise ancestors).
    I've noticed that whenever I encounter a site that is a bit clunky or just downright doesn't work there is usually one of these "enriching" technologies behind it. This is why the websites of many very large companies with large bugets are just crap from a users perspective. Most people don't want their experience enriching they just want to buy their stuff and then go do something else. In fact too much enrichment isn't good for them, though they don't know it. Around the world millions of basically sound windows systems are dying under the weight imposed by unrestrained enrichment (application bloat). I think its the main thing that gives windows a bad rep but its also how windows development corporations make their money. Like paying a school dentist by the number of teeth pulled - result lots of bare gums. Unfortunately when open source wallahs are posed the question by website owners "his enriched gizmo can do this why can't your homemade thing?" the true answer of "cos its a crap idea for reasons you wouldn't understand" doesn't really cut it. I was recently talking to the head of security for such a company who asked my opinion of their site I told him to go visit amazon cos its miles better than his site and he agreed with me. In fact I had a bit of a constructive rant and he agreed with everything I said to such a degree that I was a bit worried that he was going to get me the job of sorting it out with perl/apache - way above my pay grade. I notice some months later they have just anounced a total rework of their presence on the web.
    In short, as a web user not as a perlist, I say don't enrich my web experience - just give me sites that work reliably without forcing me to make security compromises and don't be a cheapskate run YOUR code on YOUR computer where it belongs not on mine.
    Unfortunately the suits don't seem to look at it sufficiently from the users perspective and in real terms this is where perl really shines - basic reliable sites that always work for virually every user irrespective of their individual software circumstances or security policy. IT'S THE ENDUSER, STUPID!
      I've also encountered many systems trashed from the web because windows users routinely run with less tight security than they should because if they don't loads of "enriched experience" sites won't work.

      Yeah. "Enriched" sites suck. I was updating somebody else's computer the other day because their free demo of Norton was expiring. I installed a new AV app for them, and then went out to download Zone Alarm (because Norton was their firewall, too), and Zone Alarm offered to scan me for spyware. Sure, I thought. That's great. Except that "feature" wanted me to install Active X! Ack! In the name of making my computer more secure, they wanted me to install the world's biggest security hole??? No thanks!

Re: Why Perl is a Valid Choice
by rinceWind (Monsignor) on Feb 01, 2006 at 11:45 UTC
    We often hear the comment, "No IT Manager ever got fired for picking Java."

    I have a counterexample at my present client. The IT managing director was pushed out at the beginning of last year, because of a Java project going horrendously over budget and off the rails. It was not the programming language that was at fault, but the project management (or lack of it). Redundancies were made in May, and ironically a large proportion of these had attended the Java certification courses.

    Within the organisation, Java programming has acquired a bitter taste in the mouth. They are favouring C++ which is the language that the 5 year old "legacy" systems were written in.

    In terms of Perl use and acceptance, I'm working on it. I do have Perl code in use in the production environment, for application monitoring and suchlike. They've also got a big downer on Open Source.

    --

    Oh Lord, won’t you burn me a Knoppix CD ?
    My friends all rate Windows, I must disagree.
    Your powers of persuasion will set them all free,
    So oh Lord, won’t you burn me a Knoppix CD ?
    (Missquoting Janis Joplin)

Re: Why Perl is a Valid Choice
by aufflick (Deacon) on Feb 02, 2006 at 04:10 UTC
    A few small comments:

    * fastcgi is not purely used for perl. Eg. it is one of the serving methods of choice for Ruby on Rails
    * my experience is that jobs.perl.org is in fact a poor indicator of the availability of perl jobs. On any given day, cwjobs.co.uk lists way more perl jobs (with way higher salaries) than jobs.perl.org in banking, telco's etc.

    Many of your points are about the benefit of open source agile environments. I am happy for anyone choosing Ruby or Python or Perl. They are relatively equally valid choices. I think the one choice that is not valid is Java.

    Just my opinions!

      Thanks for the input. I'll add that site to the list. I'm still not clear how to present the general perl jobs picture. I wanted to keep it simple, without listing every internet job bank, but still accurately make the point.

      If I was going to list a subset of jobs sites, can the monks suggest maybe a top 5 that they might be familiar with?

      Also, it would be nice to post a link that includes the search. For example, it appears I could post your link above like so: http://cwjobs.co.uk/JobSearch/Results.aspx?Keywords=perl

      I think the one choice that is not valid is Java.

      Unless:

      • You have several million existing lines of Java code
      • You have a good team of developers who write Java well, meet their deadlines, etc.
      • You're targeting a platform that only supports Java
      • etc.
Re: Why Perl is a Valid Choice
by GhodMode (Pilgrim) on Feb 04, 2006 at 02:31 UTC

    These are all valid, accurate points... but can we humble employees get our directors to listen to them?

    I think that the opposing viewpoint is based on a very simple thing... marketing. Marketing, rather than programmer skill or the strengths of the language has been the foundation for the success of the languages pushed by the largest software company.

    Now, don't get me wrong... I agree that Perl is a valid choice and, for me, it's the best choice. But, in my limited experience, I've known too many IT managers and directors whose only skillset was "management". I know that none of them would bother to read anything as technical as PerlMonks :)

    They tend to play it safe in order to hide the fact that they don't know anything. They will choose the language pushed by the best known company if they have the budget to pay for the development tools. As a second choice they choose Java because it's the second best known platform. They may try to sell it in their meetings as a money saving initiative. They'll pretend to be innovative, but they're still just playing it safe.

    I know this has already been said: In truth, the language choice doesn't matter much in many work environments. It's the skill and creativity of the developers. For example, I could build a very capable CGI Web Application using Bash shell script. If I was pressed to do it, I might even be able to do it with a DOS batch file (I'd quit the job first).

    My opinion is based on experience, but only very limited experience. I have no formal education and, because of that, I have (happily) never been in management. I've only been working in this field for about 5 years. The only reason I can maintain a career in this field, and participate in conversations here, is because I take a certain masochistic pleasure in reading documentation from the first page to the last... and luck.

    So, my perspective is bound to be different, but not wholly unique.

    --
    -- GhodMode
    
Re: Why Perl is a Valid Choice
by BioGeek (Hermit) on Feb 03, 2006 at 10:43 UTC
    Basically, the number of companies listing Perl as a job pre-requisite is large relative to other technologies and has been consistent.


    It can be illuminating to see this trend graph, which shows the percentage of jobs that contain the search terms: ASP, C, C++, C#, Java, Perl, PHP, Python, Ruby and .NET on job-aggregator site indeed.com

    To deduct any any meaning out of it is left as an exercise for the reader.
Re^3: Why Perl is a Valid Choice
by graq (Curate) on Feb 03, 2006 at 15:50 UTC
    If you think of a company's IT as a solution (it provides solutions to required tasks) and in turn think of that as a part of the whole of the company, then, in my experience, IT is not a major factor in a company's success.

    Now I know a lot of people will disagree and miss my point, and I feel that I understand what your arguments will be (they are obvious), but I stand by it. For example, consider Microsoft; the quality of their IT has not been the major factor in their success.

    I'm not saying that you shouldn't strive to improve yourself and others. But Perl is a valid choice for anything that it can do and your arguments hold true for that set of people who put value in your measurements. But don't expect any business to pay it more than affordable lip service.

    UPDATE: This is a reply to OP, not g0n (unless you feel it applies, that is! ;p)

    Edit: g0n - reparented from Re^2: Why Perl is a Valid Choice at authors request

Re: Why Perl is a Valid Choice
by wolfger (Deacon) on Feb 03, 2006 at 13:39 UTC
    Open Source: * You can look in and fix perl modules. * You can look in and fix perl itself.

    That, I think, is actually a bad argument. What corporate manager wants to spend man-hours and money on fixing the programmin language he chooses? Yes, it's nice that we can if we need to, but using that as a selling point rather implies that we're going to need to...

      Every IT manager worth his salt will know that there comes a time when you need to find out more about your underlying libraries/systems than the API documentation tells you. With closed-source systems this often means scouring the web for anecdotal evidence or begging the vendor for more detailed information. Having the source available is the ultimate documentation and can save you lots of hours of guessing and testing. To then have the possibility to change the underlying system to better suit your needs, legally distribute your changes and even maybe merge your changes back into the mainline distribution, can be invaluable. So yes, I think it's a strong selling point. For clueful people, that is.


      All dogma is stupid.
      Good point. 'Fix' implies broken. I changed it to 'modify' since that implies choice of different behavior, and that's what I really meant. The funny thing is, in my head, I was contrasting Perl to some purchased apps we have that have problems right now. And, of course, we can't see what's wrong and we're waiting for support to figure it out. :) Thanks.
Re: Why Perl is a Valid Choice
by Anonymous Monk on Jul 04, 2006 at 00:07 UTC
    Perl is the humble workhorse that is doing work _somewhere_ on even the most snobby person's network. Perl5 has at least a few very good years left in it. The perl program itself is quite fast, super portable and extremely stable.

    There's a lot of great reasons to choose Perl for a project. There's not too many reasons to choose Ruby, Python or PHP over Perl. The most common one is a personal preference based on the feeling that Perl is "old and crufty" and these other languages are "cool". Most cite "I don't like objects in Perl" as the primary specific technical complaint. Most of these people never got very far into Perl, some did.

    Perl under Lighttpd/FastCGI or Apache/mod_perl is very capable of matching or besting a similarly configured J2EE/Ruby/Python/PHP system in bang-for-your-buck performance comparison.

    CPAN is simply unmatched in the history of code repositories. There are some minor issues with it. Huge time savings. No language comes close, yet.

    The Catalyst framework.

Re: Why Perl is a Valid Choice
by Dru (Hermit) on Apr 30, 2006 at 03:38 UTC