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.

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.