use Perl

• The issues are... (Score:1)

  by jrockway (7171)

  So how are Modern Perl and Enlightened Perl different from the other similar initiatives?

  PBP was the first real step in the direction of "modernizing" Perl. It was a book that showed people that Perl isn't a toy, and isn't a "write-only" language. (Unfortunately some of the advice in the book was just wrong, like using Class::Std. What?)

  (I have never heard of Perl Enterprise Edition, and I am no marketing expert, but somehow I don't think "pee" is the way to make Perl popular again. Although it would pa
  • PBP is great, but it's sad it is needed (Score:1)

    by Ed Avis (3134)

    PBP is an excellent book but it is the most eloquent argument against Perl (and by implication, in favour of Python / Ruby / whatever) that I have read. Pretty much the whole book is a collection of gotchas and workarounds for crufty areas of the language that should have been cleared up years ago. The semantics of 'local $x;' are unclear and can trip up many programmers? OK, here is a sticking plaster. Shouldn't it simply be fixed in the language, with a sensible deprecation timetable and warnings as P

    --
    -- Ed Avis ed@membled.com
    • Re: (Score:1)

      by jrockway (7171)

      Pretty much the whole book is a collection of gotchas and workarounds for crufty areas of the language that should have been cleared up years ago.

      If you think there is any programming language that is not like this, you have not used that language long enough.

      The semantics of 'local $x;' are unclear and can trip up many programmers

      Anything can "trip up" programmers that don't know how to program. The semantics of local are quite clear. (Dynamic binding versus my's lexical binding. Not hard.)

      Shouldn't i
      • Re:PBP is great, but it's sad it is needed (Score:1)

        by chromatic (983) on 2009.01.28 15:43 (#67082) Homepage Journal

        Not everyone has to use Perl, but it is such a good choice for most things that it's a shame to dismiss it based on some arbitrary "the language shouldn't have anything I don't want" criteria.

        There's something deeply wrong with a software development process that enshrines deliberate obfuscations in the core test suite.

        I don't accept the counter-argument "They test features not tested elsewhere", not in the least because I've added tests for features not otherwise tested (and my tests tend to be somewhat more maintainable).

        Reply to This

        Parent

        • Re: (Score:2)

          by Ovid (2709)

          I suspect that the deliberate obfuscation tests are necessary due to Perl's heuristic parsing. With Perl 6, I doubt there would be as much of a need for them.
          • Re: (Score:1)

            by chromatic (983)

            I suspect that the deliberate obfuscation tests are necessary due to Perl's heuristic parsing.

            That's an excuse for not figuring out what the heuristics should be and writing maintainable tests for them. Remember, these are tests intended to prevent the breakage of code which no one can prove actually exists.