All the Perl that's Practical to Extract and Report

Navigation

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

Please Log In to Continue

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.

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.

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

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.

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.

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.

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

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.

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.