Anyway, I feel that you are entitled to a full refund on any module that doesn't include a changelog.
Who uses their good password for a discussion site, though? I can see if this was a list of online bank passwords how it'd be valuable, but honestly, if I could use a blank string as a password for these sites, I would. Who cares if someone posts a message "as me"?
I liked larry's password the best, ">=6chars". (Presumably in response to a message like, "your password must be greater than or equal to 6 chars". Brilliant!)
Apparently people can't install modules if they have dependencies, but they can install modules if they don't have dependencies. I don't really get it.
But anyway, reinvention aside, Mojolicious::Lite is basically the same tired CGI.pm ideas repackaged as new syntax. Great for blogging (like so many ideas from the Ruby community), but not so great for solving problems web application developers actually have.
It is exactly like this in Chicago. We have a very nice bike trail along Lake Michigan. When it is cold or rainy, it is a wonderful place to ride -- beautiful scenery, no road crossings, and hardly any people to speak of. I can ride as fast as I want.
Then it gets warm and sunny... and the trail becomes all things for all people. People ride on the wrong side. People lay their beach-towels down on the trail and sunbathe. (In the middle of a paved bike path. Who says Americans aren't stupid?) Unsupervised kids walk into oncoming cyclists, causing bloody accidents. It's not just annoying, it's incredibly dangerous. People have no clue about safety, then they get hurt.
Fortunately, we have nice roads to use on days like this... but the scenery is very boring and there are traffic lights every 500 feet. By the time you get up to speed you have to stop again. Annoying.
Some day they will ban pedestrians and cars, and then I will be truly happy.
I think you are misinterpreting your diagram. When I see all those modules, I think: "Aha, look at all those subtle complexities I don't have to understand." If DBIC wasn't there, you'd be doing that all yourself.
Unicode is complicated. SQL databases are extremely complicated. Object/relational mapping is complicated. DBIC takes on complexity to hide it from the rest of your app.
Think about what a mess your app would be if you had a home-grown ORM -- you'd have all these complexities, but you'd have to handle them yourself. At least that nightmare is shared among the collective open source community, instead of just you.
I will agree that the mixin-based design is a bit of a relic from the past. If DBIC used roles (via Moose), then all the DBIC stuff would be appear to be one or two classes. But the complexity is the same either way -- meaning that your diagram doesn't really say much.
(If I were to psychoanalyze, I would probably come to the conclusion that you don't like your work app very much, and are taking out your frustration on things that don't deserve it.
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.
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.