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

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

Alias
  (email not shown publicly)
http://ali.as/

Journal of Alias (5735)

Monday January 26, 2009
06:30 PM

I do appreciate the effort...

[ #38347 ]

But we've had Perl Enterprise Edition, and Best Practise Perl, and now Enlightened Perl, and Modern Perl...

A wise man (who I'll credit because I'm too lazy to do the research) once said that the definition of "Best Practice" is generally "My Practice".

I like the idea of a definition for some kind of better thing, but what prevents the idea becoming a temporary fad. What gives this one sticking power.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

I do appreciate the effort... 25 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • I think many well-versed Perl hackers can agree that using lexical filehandles is better than passing around raw typeglobs, and that given/when is better than long chains of if/else statements. I'm pretty sure that most of us can agree that a novice Perl programmer should look to the CPAN to solve common problems.

    I'm sure that the definition of "modern" will change over the coming years, but I'm also sure that just as we can look at a piece of code which uses global variables (with perhaps a local or two t

  • We see lots of creative people pouring heart and soul into Perl. The alternative might be lots of creative people ignoring Perl. I certainly know which I prefer.

    The fact that so many people are working on these issues makes me happy.

  • There is nothing that the EPO is doing that couldn't be done by others, but it can be said that the difference between a successful entrepreneur and a failure is simply doing it.

    If the EPO fails and collects dust, some will say that it is a failure. I'll view it as a learning experience about what to fix the next time something comes around.

    Also, my focus on EPO is to help Perl's external facing image. The EPO Extended Core is good for the various Best Practiceâ„¢ stuff, but the market

    --
    Killing two stones with one bird.

  • 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

    • To be fair, the 2nd Edition of the Perl Cookbook came out in 2003, but I get the point you were trying to make.

    • Why does it have to be different than previous efforts? I'd say that PBP was a success, and whoever writes a book now can try to both tie to its success, and learn from its failures.

      I'd say that a newly revised PBP with a more technical focus could also be a success.

      • Why does it have to be different than previous efforts?

        I don't want to define best practices. I want to explain how Perl works and how to write good Perl code in 2009 taking advantage of the best features of the language and our ecosystem as it stands right now.

        • What makes that different from what's called "best practice"?

          • In general? I suppose little.

            PBP attempted to define some best practices where consensus is murky. That's fine. My goal with Modern Perl is just to teach people how to think to write good Perl, not to create coding standards.

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

        • 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

      • A lot of folks out there are looking for an ORM. If they're not, hopefully they already know about DBI and don't need help from EPO on that one ;)

        For those folks looking for an ORM, having some standard somewhere say "use this one" isn't a bad thing.

        And note that I say this as the author of a competing ORM ;)

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.