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.

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

 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 pair nicely with Perl OO Persistence, "poop". LOL.)

    Anyway, the problem with PBP was that best practices didn't really exist when the book was written. Not many people were thinking about it. Damian tried to use his own modules to fill in the gaps, but they were simply not production-tested yet. That makes them fun toys, not best practices. Get a few people to use them, *then* write a book about it! (This is easy to slip into -- as I plan my next book, I have to make a conscious effort to resist the urge to tell everyone to use my super-cool experimental modules that only I use. They're super-cool... to me, but they are certainly not "best practices".)

    Anyway, now were are here today. Real "best practices" are emerging. Use Moose for OO. Use Catalyst for web development. Use DBIx::Class to talk to your database. Use DateTime for dates. These are solid modules that are used by tens of thousands of critical applications. You can use them as "buzzwords" on your resume, and end up with a job doing something with Perl that you actually like. And, these modules are really good pieces of software. It is time that they are marked to the wider world, because they are not only the best of Perl, they are the best among *all* the languages.

    Enlightened Perl is a marketing push to make sure that people realize that there are good parts of Perl, and that they start with those (instead of opening up the Perl Cookbook from 1998 and using what was the state of the art 10 YEARS AGO). Enlightened Perl has the advantage that most of its members are the people and companies creating this new technology. A lot of the cool stuff in Perl comes out of II, BPS, Shadowcat, etc., and those are the companies involved with EPO right now. So in addition to "this is good for Perl", there is some of the "come play with my cool stuff" that keeps us hackers (as opposed to marketers or managers) interested. I think it will be a good thing.

    (I can't say much about Modern Perl other than it's a good name and that I think chromatic is going to do a good job with it. The key is that he actually writes real Perl applications from time to time, which will make for a good book. Theory, practice, and all that. When was the last time Damian submitted code implementing new perl features to p5p?)

    Anyway, PBP was a great first step, and really helped the Perl community. Now it's time to take the second and third steps, and Modern Perl and Enlightened Perl are here to do that.

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

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

    • > Use DBIx::Class to talk to your database.

      Ugh. Endless tedious faffing with objects when plain old SQL (plus something snappy to use it with like DBIx::Simple) works perfectly well. If that's a "best practice", I guess I'm happy not being the best.

      • 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 ;)

      • ORMs give you nice abstraction that can be used to base other generic libraries - like generic html form handlers or records browsers or full CRUD frameworks. Without it it you don't have the meta information about the rows and columns and you need to fiddle with all the SQL variants.
      • Yeah, let's pretend that your minority opinion is relevant in some way.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.