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.
  • 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 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 Python does? Unfortunately that seems to be impossible. Ditto two-arg open or $[ or hundreds of other fossilized linguistic warts which were surely useful in perl 4.036 but mostly serve to obfuscate or create subtle bugs today.

      Moose is a great piece of work. But Perl 5 today (and its biggest asset, the CPAN) uses a mishmash of different object systems. In the same timespan Python has successfully moved from one object system to another (so-called "new-style" classes) by first adding the better variant, then marking the old one as deprecated, then adding warnings, and finally (in 3.0) dropping support for the old model.

      We end up with a state of affairs where the language to use is not perl, but 'perl that passes perlcritic', where perlcritic is doing the duty of many things that really ought to be fixed in the language proper.

      (I think a marketing push in favour of the best CPAN modules is a great idea BTW.)

      --
      -- Ed Avis ed@membled.com
      • Perl was designed to have lots of non-orthogonal features - Larry did not want to decide what is useful for us but instead let us try them out and see what works for us. So we had this big number of features and this was good - this was part of the evolutionary design:

        "I am told that when they built the University of California at Irvine, they did not put in any sidewalks the first year. Next year they came back and looked at where all the cow trails were in the grass and put the sidewalks there. Perl is d

        • Non-orthogonal features are great. I don't agree with PBP's advice to avoid 'unless', for example. There is a difference between that and things which are just plain useless; or worse than useless - appearing to work most of the time but introducing subtle bugs, for example glob()'s behaviour with spaces in filenames.
          --
          -- Ed Avis ed@membled.com
      • 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

        • 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

          • 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.

            • 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.

        • The semantics of local are quite clear.

          Oh, having dynamically scoped variables is very useful and not difficult to understand. I was referring to the semantics of 'local $x;' in particular. What does that statement do? Is it useful and clear, or is it a fairly useless behaviour and a gotcha for the unwary? PBP makes a good argument for the latter.

          --
          -- Ed Avis ed@membled.com
        • The semantics of local are quite clear.

          They're murky when you add in Perl 5 magic. (For everyone who doesn't follow p5p regularly, "magic" is a specific term of art you might recognize as that magic code which makes tie and overloading work.)