Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • An OSCon or two ago, I was talking to a manager at a prominent open source company. He was very aware of the power of Perl and the capabilities of Perl hackers. I asked him under what circumstances he'd hire Perl developers, and if there were any stumbling blocks, what they were.

    For one-off kinds of projects, he said he'd be hesitant to hire Perl programmers to build something. Part of it is the hiring risk that your brother speaks about, but his perspective was from a risk mitigation perspective. After all, with (near) infinite funds, it doesn't matter much that 4 Perl developers can be more productive than 2, 4, 8, or 16 Java developers. And if the Java developers can deliver a stable product to market within an acceptable time frame, it doesn't matter that the Perl developers can do it in a fraction of that time.

    It all boiled down to risk. Because Perl is so powerful, a perlhacker can do a lot of damage on a bad day (or when a little too sleepy). Java, on the other hand, has layers and layers of safeguards that make managers happy. Sure, they'll code like they're running with leg irons, but there's a limit to how much damage they can do when they're sleepy or just not thinking clearly. When money is (nearly) free, better to take the conservative approach, because there's no telling if the money you saved is sufficient to clean up the (highly unlikely, but possible) damage.

    So, there probably isn't a soluble perception problem. Some managers won't touch Perl (or Python, or Lisp, or Ruby) with a 10' pole because it doesn't come from Microsoft, hasn't been blessed by IBM, or isn't sold by the darling vendor-of-the-week. No amount of "education," "advocacy," or "marketing" from the open source community will change their minds. However, many managers who understand the fundementals still choose Java/C# for perfectly valid reasons, just not technical ones.
    • It's not just managers. Far from that. There are many knowledgable people who won't touch Perl with a 10 foot pole. Very good programmers. And they are right, Perl isn't their thing.

      It's not just perception. The problems people see with Perl are real. Perl is a handy tool. Multipurpose. But it's also difficult to handle, it's dangerous, and it has a lot of quircks. It's not for everyone. In fact, it's not the right language of many people currently using Perl. If I look at Perlmonks or Usenet, I'd say th

      • I'm certainly happy to hear well-known Perl programmers say this. This Pollyanna "Perl for everything" attitude is just as silly as the "Java-only" folks.

        • Oh, don't get me wrong. I'm certainly in the "Perl for everything" camp. However, I'm not in the "Perl for everyone" camp. I use Perl for everything I can get away with.

          However, I don't think that because I think Perl is the language of choice to solve a problem, anyone else should pick Perl to solve the same problem.

      • Why do you think, so many programmers shouldn't program Perl? Many of them started with an other programming language (may be Java) and now start to learn Perl. May be they have to solve a problem that can be solved with Perl in a better way than the solution written in Java would be.

        I noticed that more and more discussions about the future of Perl start. I think, that Perl can get in trouble, because outstanding people have a false perception of Perl.

        Why do all people compare Perl and Java? They have
        • Why do you think, so many programmers shouldn't program Perl? Many of them started with an other programming language (may be Java) and now start to learn Perl. May be they have to solve a problem that can be solved with Perl in a better way than the solution written in Java would be.

          The problem is that you cannot infer any general rules here. Sure, some people come to Perl from another language, and have learned the fundementals first. Others come to Perl as their first language, with or without an

          • But I think, that "advertising" or "marketing" can help to avoid misunderstandings. "Advertising" is not the solution on its own, but it is a part of it.

            My sense of Advertising is not to run to everybody and say "Perl is the Best, you shouldn't use anything else", but to show what Perl is good for. And that Perl programs can be as "clean" and "maintainable" as programs in other programming languages.
        • Why do you think, so many programmers shouldn't program Perl? Many of them started with an other programming language (may be Java) and now start to learn Perl. May be they have to solve a problem that can be solved with Perl in a better way than the solution written in Java would be.

          The mistake you are making here is that you assume that it's that problem that makes a language suitable. And while the problem plays some role in picking the right language, the programmer is far more important.

          Why do

      • The big problem I have with this is the "why" of it. I don't dispute that it's true.

        In fact I don't even mind that there should be another language for this kind of thing, I just wish it could be something other than Java or C#. Something more like Ruby.

        Can the "why" be fixed with something other than Java/C#?