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.
  • Great conversation here. Glad that people are willing to engage in it thoughtfully. (Many thanks to Alias for the conversation starter.)

    @educated_foo [perl.org]: The reality is that people are using Ruby, and Rails, for more than just scripting up "shiny-looking web page with minimal effort." (I'll concede the point about DHH's hair.) They're using it for all kinds of crazy stuff, like writing desktop applications and large-scale messaging services like Twitter. (All things that Perl can do equally well.)

    Regardless, I think a major point is being missed in these arguments: the people making these "shiny-looking web pages" are doing the grassroots marketing for Ruby, and Rails, and so on, e.g.: "Hey, did you know that Yadda-yadda was built with programming-language-of-the-day?" "No kidding? I gotta try that..."

    So that's point #1: "solve your own problems" isn't quite right. Grassroots marketing is helping other people solve their problems with your solution. Admittedly, I think that's what you're saying with "package up your code in a way that others can use it."

    Point #2 is that most of the people using frameworks like RoR and Django have made the choice to learn them recently. FIve years ago, nobody I know was programming primarily in Python or Ruby. And it's not like there was a glut of Ruby and Python University graduates looking for frameworks; they all had to make a choice to learn something new.

    So why did they choose these other languages and frameworks? Perhaps it was marketing "claptrap," perhaps it was hype and shiny Web sites. Those surely played a part. However, the other aspect is -- as we've all been talking about -- perception. Perceptions, and first impressions, of the language, its community, its resources and so on, all impact people's likelihood to take that first step into learning something new (or coming back).

    I've heard it argued that the Perl community doesn't really want an avalanche of new people -- signal-to-noise and all that garbage. However, if we want to see those showcase sites, and applications, running Perl -- if we want the grassroots marketing that brings -- Perl must do a better job of communicating clearly about itself.

    Communicating clearly is everything discussed above. It's the marketing "claptrap," it's the shiny-looking Web sites, and its a community that appears to openly want people to adopt this language, because it's the best damn language we've got.

    --
    Keeping technology simple since 2003
    • > I've heard it argued that the Perl community doesn't really want an avalanche of new people -- signal-to-noise and all that garbage.

      Really? Who? Where? I'll go and smack them in the face.

      > However, if we want to see those showcase sites, and applications, running Perl

      And the scary thing is, we do run those sites.

      IMDB, Amazon, Yahoo, DoubleClick, LiveJournal, The BBC, the... er... world's biggest... um... porn site (YouPorn).

      > It's the marketing "claptrap," it's the shiny-looking Web sites...

      Half

      • I think we could use some good blogs on marketing and visual vs. functional design, etc. A website dedicated to grinding this particular ax would welcome. Articles in a well read online publication would be excellent. Ignorance can be cured.

        Some of what needs to be done, may appear as simple window dressing. But a consistent style guide and resources for building Perl websites that would like to use it would be great.

        There are a lot of unorganized efforts out there. Things like making it easier to install

      • "And the scary thing is, we do run those sites."

        Very underplayed by the Perl community, unfortunately. From Perl.org, which then links to the O'Reilly site, the "success stories" are five years old. There are other lists I've seen, but none are very comprehensive or compelling.

        "The question is, given a consistent lack of competence, and a desire to improve, what are the kinds of processes we need to go through to address it?"

        I think the process has begun [delicious.com]. Let's see where it goes.

        --
        Keeping technology simple since 2003
    • Desktop applications? I haven't seen any yet (I don't count web apps), so can you point me in the right direction?

      AFAIK, Twitter is just a shiny web app that throws a lot of servers at a problem. Other than the web interface, it seems like the whole thing could be done with text files and a UDP server. Rails actually seems like a terrible fit for what Twitter is doing; it seems better suited for the simple, low-traffic web interfaces that most small businesses want than for a high-traffic buffered mess

      • I expect Perl 6 will fail because it's not directed at an actual problem....

        361 problems Perl 6 addresses (non-exhaustive list) [perl.org]

        • Just to take one example, "the AUTOLOAD subroutine should be able to decline a request" may be a shortcoming of the Perl language, and may annoy some Perl programmers, but it's not a "problem" in the sense I intended. "I need to offer my company's widgets for sale on the web" is a problem. "I need to convert this UniProt file to FASTA" is a problem. If you design a programming language while thinking about programming languages, you get Scheme.

          • If you design a programming language while thinking about programming languages, you get Scheme.

            That's a lovely slogan, but in the real world I suspect it's meaningless.

            If you don't think about programming languages while you design a programming language, I wonder how you add features that are specific enough to address real design problems while general enough to allow people to use them to address problems that didn't exist while you were designing the language. I wonder how you balance elegance and t

            • I missed a "solely" there: "If you design a programming language while thinking *solely* about programming languages, you get Scheme." If you look at the languages that endure, most were designed by smart people with specific problems to solve: John Backus wanted to TRANslate FORmulas to machine code, and created FORTRAN; Dennis Ritchie wanted to program his PDP-11 in something higher-level than assembly, and created C; etc.

              Perl fit(s) into this tradition. Perl 6 hasn't quite figured it out yet.

          • > If you design a programming language while thinking about programming languages, you get Scheme.

            I believe the evidence would suggest you get something like Ada as well :)

      • "Desktop applications? I haven't seen any yet (I don't count web apps), so can you point me in the right direction?"

        http://www.macruby.org/ [macruby.org]

        "AFAIK, Twitter is just a shiny web app that throws a lot of servers at a problem. Other than the web interface, it seems like the whole thing could be done with text files and a UDP server. Rails actually seems like a terrible fit for what Twitter is doing; it seems better suited for the simple, low-traffic web interfaces that most small businesses want than for a hi

        --
        Keeping technology simple since 2003