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

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
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)

Friday July 24, 2009
09:48 AM

What Does the Outside of Perl Look Like?

[ #39344 ]

I'm sure most of you are familiar with the debates which have consumed the Perl community lately. I really don't want to get into that other than to say that supporters on all sides have valid reasons for their views and everyone has something to contribute. Rather than speculate on what some problems are -- oh, and believe me, I can! -- I think what's more important is to figure out how to obtain information relevant to these considerations. In fact, I have several "perceptions" I think need to be better understood.

  1. Perl is dead.
  2. We need to eliminate Perl from our company.
  3. Perl's OK, but I wouldn't choose it for a startup.
  4. I want to learn a new language, but not Perl.
  5. Perl is unmaintainable.
  6. Perl doesn't scale (I'd love to see their jaws drop if they saw some projects I've worked on).

How did these perceptions arise? What is the source of them? Are people merely parroting what they've heard or do they have first-hand experience? What would it take to change people's minds?

These perceptions are a few things I hear constantly from those outside of Perl. Inside of Perl, we have different perceptions, but outside of Perl, I hear wildly different stories. Many of those stories don't match my experiences (see item #6 above), but in order to understand where the perception problem is coming from, it would be useful to better understand why people have these ideas (rather than play "pin the tail on the scape goat").

What I am thinking would be useful is for someone with some expertise in creating surveys to figure out a way to start collecting this information. So when I created the testing survey, there was a lot of fascinating information, but given my lack of expertise in creating surveys, it was rather limited (brian d foy helped quite a bit in expanding that survey beyond my initial questions).

I'm very keen on understanding the perceptions that programmers and organizations have about Perl. If we identify strong, persistent currents in thought, that might give us a clue as to what a good way forward would be. A lot of people are making blanket assertions about what Perl needs for the future. Some are quite reasonable (how do we tighten up the P5P development process), but many are based on hunches (Perl definitely needs to do X!!!).

Anyone interested in picking up this gauntlet and trying to better understand what we need to do? (This would involve potentially surveying companies in addition to individuals).


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

What Does the Outside of Perl Look Like? 25 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • I think unless someone (TPF?) hires a professional research firm, any "survey" about this is going to have limited value. To get at not just *what* the perceptions are but *why*, I think you'll need a properly designed survey and true random sampling of IT professionals.

    -- dagolden

  • Isn't this part of what he is supposed to be doing or facilitating with the tpf grant?

  • I have some experience of designing and administering questionnaires and analysing questionnaire data, both from my academic studies and in my current and previous jobs, and this is why I agree with dagolden that we need to enlist the services of a PR firm specialising in reputation analysis. I seem to recall seeing a talk at a London.pm workshop/tech meeting about how a company[1] was using Perl/NLP techniques to do just that for major corporate brands, but purely on a statistical level like brandwatch.net

  • If you come up with the questions, I'm happy to run it on the same codebase for the YAPC Conference Surveys, which runs on the Birmingham.pm survey. Just needs a YAML file to drive the questionnaire :)

  • While I agree with the need to change the perception of people from the outside I doubt you can actually find out why do they have that perception. As the saying goes perception is reality so how do you ask people why do they think reality is what it is?

    I don't think companies invest in finding out why is their perception bad. They invest in changing it.

    I think Perl needs someone with a marketing hat. Someone who has this as a paid job. One of the first things she should do is to find out what is really

    --

    • Steve Yegge covered these points at OSCon a few years back.

      The root problem is that geeks don't do marketing well, don't respect marketing, even when marketing is the most important thing we can do for ourselves and our projects. (It's been a while since I listened to his talk, so my memory is fuzzy here.)

      One of the interesting points he made is that GTE (the phone company) had a very bad reputation among its customers and in its service area. They conducted a poll to see what it would take to improve

      • Interesting point.

        I wrote a bit more on my blog about Perception is Reality [szabgab.com] but basically you responded to that one too.

        --

      • I find this really interesting. If Perl's PR is so bad that we can't pull out of it, then I guess always referring to Perl 6 as Rakudo (assuming that's the implementation you use) could be a great thing.

        That being said, I'm not a defeatist and I don't believe Perl's PR problems are insurmountable. The Perl community's resistance to PR, however, might be, thus making this a moot point.

        • The Perl community's resistance to PR....

          Isn't that odd? Someone recently called me a marketer during a disagreement, and the context suggested the other person meant it as an insult.

          • Marketing should help and sustain technical development, not go against it.

            • You say "marketing". I call it describing a very real, very large pachyderm which has taken adverse possession of the room [perl.org]. We will never agree on a term.

              However, I think we can both agree that marketing activities should reflect reality. That's why I base my conclusions 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. Anyone who wants to review that data in its orig

              • You systematically misrepresent the problems that the Perl 5 development has, and invent new ones. You propose technical solutions that show a total lack of understanding of what is a large user base for Perl 5. You refuse to listen to people who actually work on Perl 5. You arrogantly think that if most people on P5P think you're wrong, that's because most of P5P is wrong. Perl needs PR, but _your_ kind of PR is certainly hurting Perl a lot.

                • I highly recommend the Notes from the Perl 5 BOF at OSCON [perlfoundation.org] -- in particular those sentences which mention the words "blead" and "maint".

                  I was not present at the meeting, yet the discussion seems very familiar. Would you make the same criticism of the participants?

                  • As Dave Mitchell said on P5P [mpe.mpg.de], a list of hasty notes taken during a discussion among a non-representative group of mostly irregular porters was bound to ignore the most important problems. Yet I effectively recognize many concerns which I already mentioned (see for example the end of http://consttype.blogspot.com/2009/07/job-of-pumpking.html [blogspot.com] ) and I largely agree with the general line of thought. Which has little in common with yours, as explained on modernperlbooks. The BOF discussed about release managemen

                    • The BOF discussed about release management and volunteer herding; they didn't propose to break backwards compatibility,

                      That's only technically true:

                      Chip: Once we've defined a deprecation cycle, we define breakage of compatibility.

                      Don't misquote me: I didn't called you a marketer.

                      You're right. I apologize. You have called me a marketdroid [blogspot.com]; I suppose the suffix is of vital importance. The same post implies I'm a propagandist, that I'm anti-p5p, and called me hysterical and deaf to criticism. You've a [blogspot.com]

                    • I didn't delete anything except from my own initiative (and you know that), and for the rest I plaid guilty: what you're doing on modernperlbooks is disinformation and FUD. I note that it's Chip's turn to be quoted out of context. And now you're speaking about healthy debate, while I resigned in disgust from P5P after months of trying to avoid responding to your attacks. It would have been wiser to ignore you completely. Which I shall do from now on, since you still refuse to understand technical arguments.

  • I'm finding it interesting doing Ruby fulltime right now. The PR says Ruby is fantastically effective and time saving, etc.

    On actually using it and becoming proficient, I'm finding it's less efficient to write. I think I'm concluding that a competent Perl programmer ought to have better, less buggy code with more features than a Ruby programmer. I don't do Rails though.

    Right now, it seems to be coming down to things like Perl's better error detection, a built-up toolchain, and CPAN's metadata.

    I mention this

  • "Perl doesn't scale" these days probably refers to the lack of native thread support and/or lack of SMP support.

    • I've also heard it from people who believe that the only way to write web server programs in Perl is with CGI.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.