Some of the comments on Can Perl ever regain its reputation?, as well as a response from Dave Sherohman, made me realise I may not have done a particularly good job of making my (somewhat subtle) point.
Pretty much anyone involved with the Perl community knows that we have an image problem. You don’t have to look far these days to find someone dismissing Perl as obsolete. For instance, this InfoQ interview with Tim Bray (Sun’s Director of Web Technologies) from a couple of months ago. In it, Bray says:
I moved from Perl to Ruby, because Ruby is more modern
It wasn’t always this way, of course. In the early boom days of the web (around ’96-’01), Perl was king. Exactly how this fall from grace occurred is a matter of some debate. Dave Sherohman recently said it wasn’t because of the “line noise” Perl is infamous for, but for poor support for casual users, allowing PHP to fill Perl’s web niche. I think it was also to do with the cowboy practices that the early Web hysteria brought on. Everyone was in a rush to become the next eBay or Amazon, and produced a lot of awful code in the process. The fact that it happened to be in Perl was not necessarily Perl’s fault.
Regardless of how this happened, we are where we are. The question now is: can we ever reverse the trend? We’re certainly trying harder than ever, but will our attempts be in vein? You would think technical people would be rationale and pragmatic, but it seems all humans are emotional and stubborn at the best of times. I’ve encountered good quality programmers who hate Perl with a passion (including ones that have actually done a reasonable amount of Perl themselves). Will these people ever be turned around?
Or perhaps the real question is: does it matter? Do we really care that some people will never like Perl, no matter how good it is? Why worry about something we can never change? After all, surely the truly smart people will recognise when something is genuinely good, and especially when it’s significantly better than anything else available. Maybe that’s Moose. Maybe that’s Perl 6 and Parrot. So long as enough people (outside the community) know about these things, sooner or later, reputation will stop mattering.
So can Perl ever regain its reputation? Probably, but lets stop worrying about it. 🙂
For the last 18 months (or so), I’ve been working on my browser-based RPG “Kingdoms” (in Perl of course). In a decision that I may live to regret, I’ve gone for something large and ambitious, rather than small and easily achievable. There’s a lot more info (including screenshots) on the site, but it’s become obvious I really need some help in developing it. So I figured I’d give an overview of the technical aspects, and see if anyone in Perl-land is interested in helping out.
I’ve tried a lot of different ways of writing testing frameworks for database interaction, but have finally settled on an approach that seems to work pretty well. I figured I’d describe it here in case it’s of use to anyone. Pretty much every project I’ve worked on in the last few years has used an ORM; for Perl I use DBIx::Class, and in Java, Hibernate. This has led me down a particular path in terms of an approach to testing, but it could probably work without an ORM, so long as you have a well-encapsulated data access layer. But for the purposes of this post, I’ll use DBIx::Class code as an example.
One of the reasons why roles could turn out to be a fundamentally better way of doing OO is that they allow classes to be organised in a non-hierarchical way.
As chromatic said in Perl Roles versus Interfaces and ABCs:
This works great when you can model all of the entities in your program in a singly-rooted hierarchy. Many simple programs do this effectively. As the difficulty for creating sane biological taxonomies indicates, the real world does not lend itself to such artificial simplicity.
It’s worth remembering that when we’re writing classes, we’re actually modelling the real world (or attempting to). Sometimes that modelling is very abstract (in the sense that it seems very far removed from what we’re actually trying to model), but each class is a cog in the software machine that we’re building, a machine that (hopefully) produces real output from real input.
The world itself is often not hierarchical. It tends to be a lot more complex, with relationships going in many different directions. So it seems intuitive that modelling in a non-hierarchical way will produce better results. Of course, there are hierarchies in the real world too (middle management wouldn’t exist without them), but roles give us a more complete modelling toolbox.
It’s no coincidence that the IT world has moved from Hierarchical to Relational databases, or that a lot of people now prefer to organise large sets of documents with tags rather than categories. It may turn out that roles are an equally significant step forward in the world of OO.
chromatic’s most recent post on roles at his Modern Perl Books blog compares Roles to duck typing. (If you haven’t read his ongoing series of posts on roles yet, it’s a great way to get up to speed with some of the theory behind roles, in reasonably easy-to-understand terms). Given that duck typing is a favoured technique of Python and Ruby developers, it’s not too surprising that his post got a response, which seems to be fairly skeptical of roles. Read more…
As I said in my previous post, roles are an important advancement in the world of OO. Until now, I’ve mainly been using them because Ovid told me to (not personally, but through his numerous posts on his use.perl journal). When someone like Ovid goes on about something like this as much as he has, I usually find it a good idea to pay attention.
So I’d been using roles for a few weeks (and Moose only a bit longer), but it wasn’t until I had to do a big re-factor of the combat system in my browser-based role-playing game – Kingdoms – that something “clicked” in my head (and not in a bad way). The reason for the re-factor was that I wanted to add Party vs. Party combat. Before that point, parties had only been able to fight against groups of creatures. The only variation was that sometimes combat occurred in the wilderness, sometimes in a dungeon. Read more…