[Catalyst] Why I chose Perl and Catalyst

[Jay K]

Let me start by saying that I've led projects with both Java /
Struts / etc.  and Perl / Catalyst, what follows is based on my
experience with both.  I have no experience with .Net, so can't
comment there, though I suspect some of the Java points, especially
those related to support and black boxes, apply there too.

 From a purely personal development perspective, I much prefer Perl /
Catalyst - mainly because in my experience Perl / Catalyst is more
flexible and easier to work with as you build.  Add to that the fact
that almost any functionality you might want probably exists as a
CPAN module... and you have quite a jump start on your development.

 From an executive management perspective, here are the things that I
believe are the big points when deciding between Perl and Java:

1) Development time - projects based in Java require much more
development time to build the same functionality - I think partly
because of the strictness of the language, and the overhead of code
required to glue everything together.  (and point 3 below, of course)

2) Development Resources - All the java-based applications that I've
been a part of generally wind up with more developers / resources
allocated - usually in an attempt to shorten the development time /
keep some developers focussed on development while others focus on
trying to maintain the existing application.  In my experience, Perl
developers tend to be more able to handle both tasks, probably due to
how much more transparent the App and supporting software tend to be.

3) CPAN - There are over ten thousand modules available that do
almost any subtask you can imagine, from encryption to email to
network services.   This provides functionality 'for free' that you
would otherwise have to write.  And most of it is documented to boot.

4) Administration.  This is a big one.  To get java services running
- there is quite a lot that needs to be configured and maintained.
Administration of application server software is not a simple task.
Getting things set up correctly in the first place takes quite a bit
of knowledge, and maintaining and growing it requires more
knowledge.  This means your admins have to be familiar with Java
applications, the various app server software (JBoss, Weblogic, etc.)
and the JVMs that are out there, along with what is compatible and
not compatible with each version of each app server.  This is quite a
challenge on it's own, and can be damn near impossible to get right
using 'officially supported' configurations - meaning if you want
support from BEA on weblogic, for example, you need to be running on
one of a handful of operating systems, with one particular JVM, with
a particular version.   I speak from experience when I say that this
can be quite difficult, and if anything is not right based on those
supported configs, you wind up paying for much more in terms of
support, if they will help you at all.

Which brings me to item 5)  Debugging.

The JVMs are very black box-y - You can tell what is going on to a
certain degree, and if you are very familiar with the debugging tools
and logging as a developer you can get a fair view into what is going
on... but only to a certain level.  There are many things which are
very hard to debug even with the right tools, and often, when working
with large web-apps you run into problems using those tools.    Never
mind the difficulty you will run into when your VM is running out of
memory because some unknown piece of code is leaking memory
somewhere.  You won't see a lot of these things until the code goes
into production and has real production load on it.  Anyone who has
tried to run a profiler on a java-based webapp with even a portion of
production load can tell you it is not a fun excercise, if you can
get it to go at all.

There are certainly admins who have the skills to manage these
servers and to track down these kinds of problems. Those that can,
however, are not plentiful and expect high pay... And much of the
time there will be the age-old war of 'send it to the developers,
it's a code issue' and the response 'it doesn't have this problem on
our development servers, it must be a server problem'...

This usually ends in either a) the admins calling in BEA or other
support organizations to try to track down the problem, or b) the
developers spending time chasing the bugs instead of doing new
development... (which often means more developers get hired to do the
development, while others are chasing production code problems full
time.)  Both of these add expense to maintenance.

Contrast these last two points, Debugging and Administration, with a
Perl environment.

First of all, debugging Perl is much easier - there are no black
boxes, almost everything you can use you have the source to, so if
you are having a problem you can a) trace the problem through the
code all the way to the perl built-ins and b) change the code
yourself, regardless of where the problem lies.  Furthermore, the
tools you have available to you for debugging are plentiful.  Just
searching 'debug' on CPAN gives you nearly 2000 module hits.

Add to this that practically every administrator on the planet has at
least some experience with Perl, Perl modules, and with the tools you
use when deploying a Perl app - Apache / Lighttpd - etc. and is
familiar at least on some level with how to track down errors and
resolve module issues.   Furthermore, those that aren't skilled in
these can learn the skills required more quickly and cheaply than
those required for a java based web-app.

This means you have a much larger pool of potential admins for your
company, and that they are generally cheaper.  It also means that the
interaction between admin and developer will most likely be more
productive, because the information returned to the developer from
the admin is usually more complete and more useful.  Because the
admins can go further in tracking down / debugging a problem,
developers can spend more time doing what is important - developing
new code.

Long story short, in my experience Perl wins in both the short and
the long term.

In the short term - the benefits of Perl are faster development with
fewer developers required.  In the long term,  the staffing and
maintenance costs are lower because the apps are more transparent and
more easily managed and debugged.

Finally, pure opinion here, again based on my own experience, the
Perl development community is much more open and supportive than the
Java community.   That's not to say that the Java community is not
supportive, just that when you start to get into the real stumper
problems, in Java-land the number of folks who can help you rapidly
dwindle.  So you wind up talking to people you have to pay, BEA
support, etc... The Perl folks seem to be more willing to point you
in the right direction and lend a hand, even into areas that aren't
strictly Perl related - such as configuring apache or mysql or
whatever.  This, above all else, makes Perl the most attractive
choice for me.

Hope that helps!

JayK

On Feb 13, 2007, at 8:25 AM, Hermida, Leandro wrote:

>
> Hi everyone,
>
> Do not want to start any kind of language war or anything - just need
> some concrete, objective opinions and advice.  We are starting a brand
> new web application + services + database project and my boss ("those
> who make the decisions") asked me as project lead why I am chosing the
> Perl/Catalyst/DBIx::Class/CPAN stack instead of Java/J2EE/Some Java
> framework or .NET/C#/Microsoft.  In the case of this project since we
> are starting from scratch there is no initially evident reason
> (like in
> the previous example where there was already existing code that would
> influence the decision).  From my experience with Java and C# we could
> do it using those languages.
>
> Any insight or advice as to why would one prefer a Perl stack over a
> Java or .NET one?  It seems that a lot of people (including my boss)
> think that Perl cannot compete when one is trying to do "enterprise"
> applications.  In some ways (please tell me if I am wrong) it might be
> true because Perl exhibits very few rules and standards and very
> little
> built-in control over how you write your code when compared to the
> Java
> and C# paradigm, syntax and compilation rules.  This seems to make it
> much more difficult when writing very modular, reusable OO code in a
> distributed team of developers.
>
> In general are there people out there using Perl for some things and
> then finding the need to step to a more controlled and standardized
> language like Java, C#, others??
>
> Thanks,
>
> Leandro
>
>
>
>> -----Original Message-----
>> From: Jon [mailto:jon+catalyst at youramigo.com]
>> Sent: Tuesday, February 13, 2007 14:08
>> To: catalyst at lists.rawmode.org
>> Subject: [Catalyst] Why I chose Perl and Catalyst
>>
>> Following the discussion late last year about Perl not being
>> selected as the language of choice by those who make the
>> decisions, I thought I should write up my experience (as the
>> CTO who gets to make the
>> decisions) as to why we chose Perl, Catalyst, DBIx::Class for
>> our system platform.
>>
>> I've finally done that - here it is for anyone who has an interest:
>>
>> "Perl + DBIx::Class + Catalyst - Our Technology Choice"
>>
>> http://software-reviews.summer-snowstorm.com/content/view/17/27/
>>
>>
>> --
>>
>> Jon
>
> _______________________________________________
> List: Catalyst at lists.rawmode.org
> Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/
> catalyst at lists.rawmode.org/
> Dev site: http://dev.catalyst.perl.org/

---
"Those who can make you believe absurdities can make you commit
atrocities." --Voltaire