> First: Perl jobs are not decreasing. While there is not a ton of 'Buzz' > around perl anymore... If you look at actual jobs stats: > > http://tiny.cc/kkcCM > > Perl is above all the others by some margin.
Short version: that graph is misleading. Click the "Relative" link. Longer version: Yes, Perl is above the rest by some margin, thanks to its history. There are existing Perl applications that need to be maintained, and some momentum that keeps the demand for Perl jobs going. But click the "Relative" link in the graph, and see the percentage growth for Ruby jobs. It skyrockets when compared with both PHP and Perl. > There are two problems I see, really. One problem I think David points out > correctly... there is precious little 'easily accessible' means to learn > about catalyst and what the conventional 'preferred' pieces are... so those > that learn it are those that really need it's power, and have come searching > for it. Those that are just trying to pick something and go will piss off > to some more spoonfeed-easy-to-learn framework. > > I'm not convinced that's a bad thing. The second problem I see is that we > don't seem to know who we want to market Catalyst to. We look over and see > Rails and Django getting a lot of press and raves and such, and think 'I > want to go to there.' > > Overall, though, I think that most of us who have used Catalyst for any > period of time know that it is not a beginners platform. It is a powerful > set of tools to solve difficult and complex problems. > > I think we need to take a page out of the old Unix'ers handbook. Stop > looking to be as accessible to newbies as the other options, and embrace our > true position... which is simply Catalyst is better. Not because it's > easier to learn, and certainly not because it forces you into one (easy or > not) way of doing things.... but because you can bend it to whatever form > you need to solve whatever problem you have, even the ones that are less > computer science-y and more computer-room-in-the-office-y. (though we can > certainly do the former as well) > When someone says 'well, Why isn't catalyst as > clear-cut and simple to use like Rails?' we should encourage them... tell > them 'Go... Go play with rails... and when you grow out of it, we'll be > waiting for you.' After someone makes the decision to learn Rails (at the expense of Catalyst - this is important), and the investment to keep learning, then build a web application, and maintain it for a year or two, what happens if they run into issues? They'll ask for support. And they'll find a way to solve the problem. It may be an ugly solution, but in the vast majority of cases, the issues will not be serious enough to warrant ditching Rails, picking up Catalyst, learning its quirks, then rewriting the web application from scratch in a framework they won't be nearly as familiar with. In other words, I estimate the deconversion rate from almost any web framework to Catalyst to be very low. When that happens, it will most likely be in the form of the same developer taking on a new project, but the old app won't be rewritten. > We should position Catalyst as the big-sister framework, the one whose there > for you when you are ready to take on big problems that can't be solved by a > bit of automatic CRUD, the ones that can't be stuffed into the channels that > someone else has already dug. We should communicate an attitude of 'yes, > we can solve easy problems too, but we are particularly good at solving the > harder ones.' > > The fact is that Oracle does not try to compete for the low end of the > market with MySQL. They don't want it. They never did. Why do we? I think I can agree with that. What I'm saying is that there's simply too much useless choice. Random example: Data::Dumper vs. Data::Dump. I've just discovered Data::Dump but it appears to beat the crap out of Data::Dumper. Yet does it say anywhere "Hey, if you're getting started with Perl and need to dump variables, use Data::Dump, and don't waste your time investigating other modules"? If I were the author of Data::Dumper, I'd somehow retire the module, or plaster a note in the POD redirecting people to Data::Dump. Imagine a programmer new to Perl picks up an example that uses Data::Dumper. Will they find out about Data::Dump? No. Someone picks up the Catbook and learns about FormBuilder. Does http://www.formbuilder.org/ mention FormFu anywhere? No. It mentions its last update, March 2007. Positive feedback (does it count as "feedback" if it's from the author? :) idea #1: module conflation. Kinda hard to do because people tend to feel strongly for their pet projects even when there are clearly better alternatives. The list goes on. As Octavian noted, the wheel is reinvented and solutions are forked off all the time. Mojolicious - yet another Perl web framework. I remember wasting a few hours looking into it a while ago, trying to figure out how it's different from Catalyst and if there are grounds to reconsider my choice of a Perl web framework. Is there some sort of comparison matrix of Perl solutions, like http://wikimatrix.org? Not really. There's CPAN ratings, but that's very rudimentary and very few bother to use it. Positive feedback idea #2: Use CPAN ratings. And this is ideas #3, that could really reduce the amount of choice: it should be WAY easier to make an informed choice. Imagine you're looking for a wiki software. Go to http://www.wikimatrix.org/wizard.php. Brilliant. Dan _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
