Archive for April, 2010

Why Padre is important

April 29, 2010 7 comments

I’ve been doing a little bit (that is, a very little bit) of hacking on Padre. Partly because I wanted to do something different (it’s been a long time since I’ve worked on a non-web UI). Partly because I wanted to contribute to an OSS project. And partly because I think Padre is pretty important to the Perl community.

Why is it important? One thing we can probably all agree on is that it’s vital for Perl (or really any community) to have a steady stream of new blood joining its ranks. Without new people, even an impressive clan of grey-beards will struggle to prevent the community from going stale. Perl needs to attract new people, both novices and experienced developers.

How do we do that? Obviously, by making the language and key modules awesome. I think it’s safe to say we’re on the right track here, with the improvements to the Perl release process, Moose, Catalyst, etc. Plenty of words have already been blogged on this, so I won’t go into it further. Making the community accessible is also a big plus. Perl Monks has always been the envy of other communities, and innovations like Iron Man help too.

But there’s one other area that helps attract prospective developers: tools. As chromatic pointed out recently (and as confirmed by a poll run by Gabor Szabo), Perl is a community very strongly biased towards *nix. It’s not surprising given Perl’s heritage. There are even a bunch of unix-like commands built into the language. On top of this, another poll by Gabor shows a huge percentage of Perl developers using vi or emacs as their main editor when developing Perl. (Obviously there are biases in the samples of these polls, but they’re probably more reflective of people active in the community, who tend to have the most influence).

vi and emacs may work for you, but they don’t for a large part of the rest of the world. If you talk to a Java developer (probably the biggest group of developers in the world, right now) about taking up another language, one of the first questions they’ll ask is “what’s the IDE like?” There are very few Java devs who don’t use Eclipse, or some other IDE. OK, so they may have to, because that’s what work makes them use (or because Java has become so unwieldy that it’s near impossible to develop without one), but the point is that that’s what they’re used to. That’s one of the first things they’ll be looking for, just as a Perl dev might look at the regex support of a language they’re considering.

One of the goals of Padre has always been to help get beginner developers involved with Perl. That’s a no-brainer. If you’ve lived your whole life on Windows and not really programmed before, you’re hardly going to want to wrestle with a unix command-line, vi, and Perl all at once. Padre can hopefully help those people.

But just as important is the more experienced developer, who’s maybe heard about some of the cool stuff going on in Perl, and wants to have a go. Again, going back to the Java world – many Java devs spend most of their time on Windows. Despite Java being pretty cross-platform, development on Linux can often be trickier than on Windows. Not to mention, a lot of them are trapped in corporate hell (a place from which I’ve recently escaped – thankfully), where they don’t have a choice.

For me, the ideal situation would be that, if a reasonably experienced developer wants to try out Perl, they can be pointed to a simple step-by-step guide that let’s them download a version of Perl for Windows, Mac or *nix, install an IDE, and be up-and-running within an hour. Without that, we may find our potential recruits giving up in frustration before they’ve had a chance to play with the things that we think makes Perl worthwhile.

The point is, while Perl may have come from a *nix, vi/emacs background, that doesn’t mean it has to be that way forever. There’s a lot more competition in the language market these days, so it makes sense to broaden your appeal as much as possible. I hope Padre can go some way towards that.

(By the way, I realise there are other IDEs around that work well with Perl. But as far as I know, Padre is the only one that’s open source and written in Perl.)

Categories: Programming Tags: ,

Is Test::Class the standard yet?

April 20, 2010 8 comments

Recently, I’ve been coming across a few Perl projects (both at work, and in the wild) that are reasonably large and complex, have test suites, but don’t use Test::Class. And I really struggle to understand why. Most of them have decent test suites, at least in terms of coverage. But, personally, I have a hard time looking at the test files and understanding exactly what’s going on.

Most other widely used languages have at least one class-based testing framework that is the de-facto standard, usually based around xUnit. I find there are several benefits to using a framework like Test::Class:

  1. As I mentioned, it makes your tests more readable by breaking them up into methods (I blogged a while ago about breaking them up even further for maximum readability). This ensures you’re clear about what you’re testing in every test, and you don’t get a really complex setup, used by a whole lot of different tests. Not only is that difficult to read, but it quickly becomes complex to maintain, and the tests become fragile, throwing you false negatives.
  2. Makes code-reuse easier, with inheritance (ok, so we all use roles now, but inheritance is still better than nothing).
  3. Makes it easy to setup fixtures by storing them in $self, using setup, teardown, etc. methods, all of which encourages more code-reuse
  4. Helps with test driven development, by allowing you two map one application class to one test class, or set of classes where necessary. You can do it with a bunch of .t scripts as well, I guess, but I usually find it easier with classes.
  5. And many more…!

We like to have a lot of options in Perl, and I’m fine with that, but you usually should have a good reason for deviating from the norm. So is Test::Class the norm (or did I just get a bad sample)? If it’s not the standard, why isn’t it? It seems to have a pretty thin set of dependencies, is stable and mature code, and fits right in with Test::Builder and friends.

In my opinion, you should use Test::Class unless you have a damn good reason not to!

Categories: Programming Tags: , ,