A case for Catalyst

| 2 Comments

By Jay Shirley

Software is like any other product that is depended upon for doing any particular function. Software, vehicles and computer hardware are all simply tools intended for a particular audience; audiences that tend to become polar, enthusiastic and fanatical. Whether it is the car tuning crowd, the overclockers or the Perl hackers, they share the same thing in common: being devoted to something.

This devotion drives a great number of innovations, and this is where Software really stands out. Particularly amongst the Open Source crowd, where Software is bound with something even more polarizing: Personality

The merging of software and personality is both a blessing and a curse. People are seldom more motivated than when working with something that feels alive; but to attack or criticize is, by definition, personal.

The people who are the most knowledgeable to defend, market, recommend (or even attack) are the ones already entrenched. They are part of the personality mesh, and as such it is exceedingly difficult to try to promote and defend a software product without going into the years of positive experiences one has shared with the product.

This article is no different. I love Catalyst and have used it for years. I will, however, attempt to back up my passion with articles of reason and rational points rather than espouse virtues that are little more than anecdotal.

To get started down this path, I think it is important to properly frame Catalyst in scope. On its own, it doesn't do much. It certainly doesn't do much well, but Catalyst by itself is really little more than a web server; it is a request handler and dispatcher and sends the response to the client.

By itself, it fails to talk to a database or handle sessions. It won't even authenticate a user. It has no template system, and no caching. So why does Catalyst have a fanatical fanbase and successful sites with it?

Quite simply, it's the CPAN.

The Catalyst philosophy is populist, not dictatorial. A belief that tools should be built to do a specific feature or function, but not require usage of any given tool; granting flexibility to a developer to solve problems the Catalyst community has not thought of how to solve.

Catalyst doesn't require you to use Template Toolkit or Mason. It doesn't push DBIx::Class as The One True ORM. It lets you pick. It trusts that you are a software developer and you are solving a problem. Catalyst just makes it easy to make your decision, and integrate that solution and start working. Between helper scripts and thin model adaptors (Catalyst::Model::Adaptor), there is virtually no hassle in integrating any CPAN module or custom code directly into your applications. The side-effect of the "trust the user" philosophy, aside from a fantastic framework, is that it is quite simply just that: a framework. It operates and evolves on the principles of synergy alone, striving to make the whole greater than the sum of its parts. A simple goal of striving to make a developers life easier, more productive and deliver higher quality results.

The results are easily quantifiable. Software development, at its core, is about solving a specific and well-defined problem. The more advanced the software is (in evolutionary, organic growth), the tasks at hand are solved more efficiently, properly and faster. The most significant improvements in development speed and quality come in the form of frameworks and libraries that have been peer reviewed, tested, poked and approved by the fanatical masses.

This lowers the barrier of entry to solve problems, and in general increases the supply of developers to meet the seemingly inelastic demand of problems that need solving. In effect, there is a framework for everybody, from the novice tinkerer who simply has an itch to scratch to the mathematically minded engineers that operate on puritan principles. Catalyst strives to match the pace of the whole spectrum, which is significant work. It makes the upfront learning curve a bit steeper than it could be. Looking historically over the documentation and tutorials, this will change and the learning curve will be greatly reduced.

The important thing that every developer, whether extending Catalyst or using just the minimums, Catalyst is simply a tool. Tools in the software sense are different than in the tangible world, they can change shape and function. They can easily be used incorrectly, or adapted and accidentally solve an unexpected problem.

Catalyst developers understand this, and the goal is to simply develop a robust foundation, particularly in the web application space, to solve problems. How those problems are solved is left up to the developer, though. The Catalyst community, just as the Perl or any other community, has suggestions and opinions but ultimately the responsibility lies on the developer. A core tenant of the Catalyst (and the greater Perl philosophy) is to trust that the developer knows enough to solve the problem. The tool should never impose philosophical beliefs; imagine if a hammer would only hammer specific nails, what problems could be solved then?

This lack of capability, or rather tools being an obstacle rather than an aid, was what drove Catalyst to grow and evolve. Taking original concepts from other frameworks (like Maypole) and extending those ideas in an open minded fashion, and also to use more modern development practices and factor out common code to be shared outside of Catalyst.

When Catalyst hit version 5.5 several years ago, the codebase was solid enough to call mature. It was grown up, but not done growing. At this point, the mature development cycle began and rather than a rapidly growing and changing framework, a stable and robust framework was in existence. This started a chain of high-quality (and some high-traffic) sites that were built on Catalyst. There was much rejoicing.

There are a lot of websites running on Catalyst, for a full list please view the Catalyst wiki.

Jay Shirley is a Catalyst evangelist, an EPO founding member and just another Perl hacker. He's launched and managed several large scale projects on Catalyst, as well. He is the co-founder of Cold Hard Code, LLC, a company set up to use Perl and open source technologies to spawn quality websites.

2 Comments

Regarding successful sites: many more are listed at CatalystSites.org and at the Sites running Catalyst wiki page on the Catalyst Framework wiki, which itself is powered by MojoMojo, a Catalyst-based wiki.

I recently suggested that Catalyst be used for a new web application we're developing and the manager in charge said the Perl was considered legacy in the company and prohibited from use for new projects. Has anyone seen this? I'm new at a mid-size to large east coast (USA) company. If you have seen this, how do you combat it?

Leave a comment

Job hunting for programmers


Land the Tech Job You Love, Andy Lester's guide to job hunting for programmers and other technical professionals, is available in PDF, ePub and .mobi formats, all DRM-free, as well as good old-fashioned paper.