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.
  • We throw around words like "Modern" and "Enlightened" and "Directory of Marketing" because they are the best we can do, because we don't know how to name things well.

    IMHO, "we" throw around these terms because they have positive connotations with no denotations -- i.e. they are standard marketing claptrap. If you have a specific idea for how you want Perl to change, you christen it "Good Perl" or something, then repeat that term endlessly. One of these days, after I decide what I want Perl to become, I'll

    • [They] are standard marketing claptrap.

      I don't speak for any "we" but the editorial we, but I like the term "Modern Perl" because I like pointing to well-written code which takes advantage of the CPAN and community idioms and features added to Perl in the past decade to solve problems elegantly and maintainably and having a concise, memorable term to use to distinguish it from bad code poorly thrown together with no sense of design, little understanding of Perl's strengths and weaknesses, and no intent fo

      • I don't particularly care what other people use as a name, whether Enlightened or Modern or Maintainable or Good or whatever.

        Try "chromatic's," or "strict and warnings and Moose," or (I guess) "rakudo." My point, which seems to have sadly been lost, is that "meaningless-positive-adjective Perl" is standard marketing bullshit, and implicitly assumes that your audience is a pack of semi-morons. It's no better than "Enterprise Perl Bean Solutions." Please don't do that.

        • I don't see it as "meaningless-positive-adjective" perl, so much as "memorable-succinct-suggestive-adjective" perl.

          A "name" has to serve a lot of purposes.  If it is too long and unmemorable (strict and warnings and Moose Perl) it is not a name but a description.  The name does *not* have to be the description, it just has to be suggestive enough that, once someone learns the description the name will an easy to remember tag that quickly reminds them of the description.  It also is a bug advantage if the name is catchy/interesting enough that someone seeing it for the first time is inspired to investigate and find out what it means (which might mean learning some history to know why the name is suggestive - such as why "modern" perl is different from "traditional" perl).

          For example, "Extreme Programming" meant absolutely nothing to me when it was just a name.  After reading about it and the various components, it made an excellent label to identify what I had learned (even though very little in it seems extreme to me - but then I was never too fond of the more traditional methodologies against which it might seem extreme).

          Just because you can have marketing speak infested things that have no content does not mean that all marketing speak is bad.  Used with care and in moderation, it can be very powerful and enhance the technical content immensely.
          • The name does *not* have to be the description, it just has to be suggestive enough that, once someone learns the description the name will an easy to remember tag that quickly reminds them of the description.

            Agreed. But to retain some credibility, the name should be both descriptive and value-neutral. "Extreme Programming" and "Waterfall Programming" both succeed because they describe the relevant processes without claiming that they are either good or bad. "Perl" and "Linux" do as well, to some extent