There seem to be some projects around for Ruby, Java and possibly Python. But I don’t think they’re recommended as a best practice (yet). It’ll be interesting to see if other languages begin to catch on, and whether they’re at all influenced by Moose or Perl 6. Anyone know of other languages that have roles?
Unfortunately, I have to say I agree with most of the comments. I think the assumption “Perl has a reputation for being line noise due to golf/obfu” is false. In fact, I’ve actually occasionally heard people say “I don’t really like Perl, but the obfu is cool”.
I thought I’d pass on a simple tip that was given to me by a colleague last year. When writing tests, it can help to break it into sections called “Given”, “When”, and “Then”, indicated by comments:
- “Given” – set up the criteria for your test
- “When” – execute the code for the test
- “Then” – inspect the results, and make assertions
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.