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.
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 thrown in for good measure) and leading ampersands to call functions as old, we can look at a piece of code and say "Your personal style may be different from mine, but you've written in a modern Perl style."
Re:Sticking Power
dagolden on 2009-01-27T03:45:47
I like the idea of a sort of "Strunk and White" for Perl.
The way I see this project as different in intent from PBP is that it can be less dogmatic about what is "best" (highly contextual and often idiosyncratic) and yet dogmatic enough about what is "good" (generally accepted) to be a reference for minimum standards or expectations.
-- dagolden
Re:Sticking Power
chromatic on 2009-01-27T04:26:48
That's a nice metaphor. Do you mind if I borrow it?
Re:Sticking Power
dagolden on 2009-01-27T04:32:28
Please do.
Re:Sticking Power
Aristotle on 2009-01-27T05:01:49
Only if you want all the linguists in the room to huff and go on a rant about the “shallow grammar-bossiness and vapid style-mongering” of Elements, which therefore seems to be analogous more to PBP than to this Modern Perl endeavour. (I would not want to offend Damian so badly as to say it is directly analogous.)
Re:Sticking Power
chromatic on 2009-01-27T07:04:36
If you thought arguments about programming languages were shallow and meaningless, you don't know any academics!
With all due respect to everyone who hates prescriptivism, I'll put on my professional editor hat and say that a gentle dose of Strunk and White could improve the majority of writers with whom I've worked (and anyone who turns into a petty linguistic dictator after reading Orwell was already a petty dictator).
Re:Sticking Power
Aristotle on 2009-01-27T15:05:40
It’s not like they merely trash Elements without ever suggesting a better alternative.
Re:Sticking Power
drhyde on 2009-01-27T12:35:06
Expect furious arguments from those who prefer Fowler's Modern Perl Usage:-) Re:Sticking Power
dagolden on 2009-01-27T12:50:39
As I'm not British, I'll stick with the The Columbia Guide to Standard American English, thank you.
:-) N.B. It's great fun using it to rebut language pedants at work.
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 marketing is where I'm hopeful.
Perl's a great language, but with a horribly dense echo chamber that few people want to enter. Enlightened Perl's success will come easier with the Perl Community (or rather, a part of the Perl community; I don't think it is possible to have the whole thing
If I can get people who have never used Perl to evaluate something, I'll view my time as a success.
Even if it is just a temporary fad... who knows, it may only last until Christmas.
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.
Perl Cookbook
vek on 2009-01-27T17:44:20
To be fair, the 2nd Edition of the Perl Cookbook came out in 2003, but I get the point you were trying to make.
Re:The issues are...
moritz on 2009-01-27T18:13:37
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.
Re:The issues are...
chromatic on 2009-01-27T18:39:35
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.
Re:The issues are...
jplindstrom on 2009-01-28T00:39:27
What makes that different from what's called "best practice"?
Re:The issues are...
chromatic on 2009-01-28T00:50:26
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 great, but it's sad it is needed
Ed Avis on 2009-01-28T01:15:51
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.)
Re:PBP is great, but it's sad it is needed
zby on 2009-01-28T13:01:48
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 designed the same way. It's not just a random collection of features. It's a bunch of features that look like a decent way to get from here to there. If you look at the diagram of an airline, it's a network. Perl is a network of features... It's more like glue than it is like Legos."
- An interview with Larry Wall (1999). But then people got tangled into the political disucssions about deciding what to depreciate - about deciding where really are the trails in the grass.
Re:PBP is great, but it's sad it is needed
Ed Avis on 2009-01-28T15:32:20
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.Re:PBP is great, but it's sad it is needed
jrockway on 2009-01-28T19:29:03
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 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.
Sure, maybe. But that's not going to happen. So you can either document the problems (which are not problems once you are fluent in Perl), or you can switch to Python. 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.
Re:PBP is great, but it's sad it is needed
chromatic on 2009-01-28T20:43:35
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).
Re:PBP is great, but it's sad it is needed
Ovid on 2009-02-03T10:07:58
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:PBP is great, but it's sad it is needed
chromatic on 2009-02-03T18:59:20
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.
Re:PBP is great, but it's sad it is needed
Ed Avis on 2009-01-28T22:08:30
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.
Re:PBP is great, but it's sad it is needed
chromatic on 2009-01-29T01:04:05
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
tieand overloading work.)Re:The issues are...
hex on 2009-02-01T00:33:05
> 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.
Re:The issues are...
autarch on 2009-02-01T05:54:23
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
;) Re:The issues are...
zby on 2009-02-05T09:51:13
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.Re:The issues are...
jrockway on 2009-05-14T21:25:44
Yeah, let's pretend that your minority opinion is relevant in some way.Re:The issues are...
hex on 2009-05-15T12:24:05
Oh noes! Clearly you have the larger e-penis. I yield.
