Slash Boxes
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

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Monday July 27, 2009
05:12 AM

Solutions Are Not Problems. Problems Are Problems.

[ #39357 ]

Important caveat before you read: please don't read this blog post as Ovid saying "don't evangelize Catalyst, don't write tutorials, etc." I'm not saying that. These things are important and we should continue them. I'm saying that we need a core team to get together to really understand the nature of the problem we face rather than relying on anecdotal evidence. Now on with the show.

Gábor wrote the following in his blog:

Yesterday I wrote Perception is Reality - we need a director of marketing. After a few hours I was caught on IRC by some people who said the main problem why companies are not picking Perl or why they are leaving Perl is that they cannot find good Perl programmers. As reaching programmers to learn perl is not the job for a marketing director hence we don't need a marketing person.

Gábor doesn't buy this argument and he's right not to because this reflects a very fundamental and common error of identifying the solution as the problem. The reasoning works like this: "companies aren't finding enough Perl programmers so we need to teach more programmers Perl." The error can be illustrated by a slight change to that: "companies aren't finding enough COBOL programmers so we need to teach more programmers COBOL."

The problem is identified as "not enough Perl programmers", but that's actually a component of the solution because it completely fails to address the problem of why we don't have enough Perl programmers. Since this error has been made, I really have to attribute a large part of that to myself because I've failed to communicate as effectively as I can, so I'll try to take another swing at it. Let's look at a few proposed solutions to what I'm calling P3 ("Perl Perception Problem") and see what new (or old) perceptions might result. To be fair, many of these "solutions" might very well reflect a perception of a different problem.

Solution: We need to keep Perl stable to maintain trust.
Response: You've already lost trust and besides, Perl is antiquated, so stability doesn't appeal to me.
Solution: We need to add features X, Y and Z.
Response: My preferred language already has those features so there's no reason to switch.
Solution: We need more tutorials.
Response: So does COBOL. Why should I care?
Solution: Catalyst! Moose!
Response: Too bad they're written in Perl.
Solution: We need something as easy to use for Web development as PHP!
Response: You shouldn't reinvent the wheel. PHP is good enough for me.

(Note: read the next paragraph carefully. I've been accused of trashing Perl and I expect that's because people are skimming what I write.)

Notice that I am not saying I agree with any of those hypothetical responses. Nor am I saying that those are the responses we'd receive. Further, all of those proposed solutions have merit, but the one (or ones) which will gain us the most bang for our buck are unknown. Heck, parts of the solution might be things we've not even considered yet.

One danger of proposing solutions without understanding the underlying problem is that we may come off as self-serving and we don't want to do that. To avoid it, one thing we must realize is that not all of our critics are wrong. Consider PHP. They mopped the floor with us on what many considered our home turf. They've obviously done something right. We might make vague claims of "technical superiority", but tell that to SmallTalk and Scheme developers. They also think they have "technical superiority", but superiority for what? If we don't understand the problem, we can't say what we're superior for! If our solutions are truly self-serving, they deserve to be ignored as there's a good chance we're solving the wrong problem. Just look at the RIAA. Many people involved with that really believe they're doing the right thing just as we're convinced they're not. It's easy to hear what one wants to hear.

In regards to understanding the problem, chromatic wrote:

I think we can both agree that marketing activities should reflect reality. That's why I base my conclusions [regarding the Perl 5 development process] on (and refer to) publicly accessible raw data, such as timelines, release dates, bug reports, patch submissions, commit logs, documentation, and mailing lists are all public information.

Relying on raw data is important and I'm happy chromatic is doing that, but few, if any of those sources really tell us why we have a problem (the mailing lists sound tempting, but we're really in an echo chamber). For example, let's say that you're consulting your access logs and you find many searches for the term "email". You might conclude that you have a support problem and people are looking for contact information. It might be spambot email harvesters. We're the BBC. We might have people thinking they can find celebrities email addresses online. The thing is, you can't know by just looking at raw data. You can only guess. If we can gather better information about P3, we still won't know the answer, but we can make better guesses.

To understand P3, we need to do research. Some people have mentioned the financial aspect and that's a worthwhile concern, but we don't necessarily have to spend money -- though we will need to spend time. I doubt many of us are experts in market research but maybe someone is and is willing to volunteer services? Maybe we can team up with another open-source group to facilitate this? Maybe we can find a university teaching marketing and propose an interesting research project and domain expertise? Do we have contacts for any of this? If we want to understand this problem, we can. We just need to be sufficiently creative and motivated to get to the bottom of it.

Dave Cross and I (and Rozallin Thompson, I believe) will be meeting in Lisbon at YAPC::EU 2009 to discuss this issue. I encourage others to join us. Let's tackle this beast once and for all. Our careers depend on it.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Dave Cross and I (and Rozallin Thompson, I believe) will be meeting in Lisbon at YAPC::EU 2009 to discuss this issue.

    Do you mind if I join you as well?

    Cheers, JJ

    • Not at all! The more the merrier. Heck, even people disagreeing with me on P3 are quite welcome. I want plenty of opinions.

  • Dave Cross and I (and Rozallin Thompson, I believe)

    Yep, I shall be there.

  • One facet of market research (really, product marketing) is identifying the target customers and how well the product serves their needs.

    I suspect one part of the echo chamber problem you describe is that few people seem to be explicit about who the customer might be and what they need. One facet of market research (really, product marketing) is identifying the target customer and how well the product serves their needs.

    Perl has several "customers" to consider. A non-exhaustive list might include:

    • Co
    • This is an excellent point and one I've been considering. In order to define the customer, we need to understand what we're trying to do. In other words, once we have a goal defined, we can better understand who are customers actually are and thus know who we need to potentially gather data from. My goal is this (and when we get a group together, perhaps this will change):

      Allow Perl to reclaim its status as a respectable programming language for new projects.

      If that goal is acceptable, then we can better

    • PHP won because you could edit your website in a website editor.

      You could use all the tools you had already to learn the skills you didn't have and achieve the goal you want.

      Dreamweaver clinched it for them, because now you had an editor that wouldn't break the code.

      And most people, in my opinion, don't change technologies if the ones they already have can do the things they need.

      • Check out []. It's in russian, but from download picture you'll get the idea. It has perl extension, however how much time will you spend looking for good perl hosting.
  • I've been talking to a lot of people about this recently, and I usually ask the question "Why do you care if Perl survives?". Most people say the same thing that you say at the end of your post: "Our careers depend on it."

    I think that's a pretty poor reason to do anything, and certainly the worst of all the reasons to promote a programming language. If we're in a situation where we are merely trying to save jobs and keep Perlers employed, we're not doing the right thing.

    • Ouch! You're perfectly correct. I was trying to come up with a vaguely punchy ending and dropped the ball. Thanks for calling me on that.

      • Interesting.
        Why do you think it is not a good enough reason?

        I thought that the sentence Your career depends on it perfectly fits my situation and probably that of many others so I was wondering why do you think it is not an acceptable reason to invest in the future of Perl?

        I am quite sure if I could not make a living any more using Perl I could switch to something else. It will certainly take many years to gain some reputation and I might even need to take a salary cut because of that but I would find m

        • Hi Folks

          Because companies which hire me don't hire me to promote my career! Surely that's obvious.

          They hire me because they have a code to be written, I'm available, and either they want Perl or (rarely) they let me choose Perl.

          Again, for /them/, my career does not come in to it.

          So, we need to promote Perl so more people automatically see Perl as the best language to provide a solution.


        • The reason why "your career isn't a good enough reason" can possibly be explained by again casting things in a slightly different light. Imagine if we saw this posting:

          We need to better evangelize COBOL and convince more programmers to learn it because our careers depend on it!

          The obvious reply is that this is a very self-serving statement which ignores the reality that COBOL is an antiquated language that needs to die. Companies are turning to older COBOL programmers because young people don't want to le []

    • Other people - and companies - might not care about my career, but I do. So I'd I thought career depended on perl then hell yes, "my career depends on it" is a damned good reason for *me* to care and to do something about it!
      • You should take anything your career depends on and make your career not depend on it. If Perl disappearing meant that your career was over, then you either aren't a valuable employee or need to diversify your skills. You should never have only a single thing that makes you employable.

        Knowledge of a particular programming language should be among the least of your skills. You should be valuable for your general knowledge of how things work, your experience in the problem domain, and your ability to solve pr