I have the privilege of working with a development department that is married, with children, to Java. Somehow I've managed to squeak a couple of applications written in Perl through, but now I've come to a point that I've expectantly dreaded: having to justify, in writing, the use of a Perl CGI in lieu of a JSP or Servlet for a particular project.

Here's quick and dirty background on the project, our environment, and why I feel I should use Perl instead of Java --

Project:
The requirements for my part of the project are asking for an Intranet-based "GUI" that will essentially list the contents of a particularly large subset of filesystem directories, parse the file names and parts of the files into organized chunks of information, show this to the user, and allow them to manually flag files for use in another application (short description: lots of filesystem interaction and text parsing with a little bit of database work, tied to an HTML front end. Not so much a GUI, but more like a text crunching, file slurping monster with a pretty face).

Environment:
We're using the iPlanet HTTP server, which of course doesn't support FastCGI (or anything similar, that I'm aware). This is the main argument that our architecture governance committee hangs on whenever CGI programming is brought up, saying that the resource overhead of starting CGI processes is too inefficient (on two load-balanced, 4 processor machines which run 98% idle most of the time). To top it off, only 1 person at a time will be using this particular application at any given time, making that argument irrelevant anyway.

Perl instead of Java:
Whereas I seem to have at least some ability to weigh practicality over marketing spiel, my colleagues regularly regurgitate the Java Rhetoric^TM that encourages developers to write bloated and ultimately inefficient software. I agree that, in our environment, JSP is a fine technology for writing database-driven applications used by thousands of employees, compared to CGI. But in this case, Java is simply the wrong tool for the job.

For those unfamiliar with Java's java.io.File package, consider yourselves lucky. In comparison to Perl's File modules, Java's API is clumsy, slow, and incomplete. The text processing piece is a no brainer; clearly Perl has the upper hand.

So why am I posting this Meditation?
Because, other than the generalities that I've listed above, I don't have what I believe is a case that can sway the argument in my favor. I have no extensive hard and fast data dealing with this very specific comparison/contrast of Perl & Java. I'm starting from a disadvantaged position; I fear that if I push the issue any further without proving my stance, I'll be digging my own grave, or at best I'll look like a complete jerk. This is my conundrum.

I don't have time to do benchmark testing with both languages, and I haven't been successful in finding benchmarks on the Web that deal with these specific issues. So I pretty much have to wing it, if I choose to follow through this time. On the project level, it really doesn't matter a whole lot if we end up using Java and have a slow application as a result. But in the big picture, I will have effectively been assimilated, Perl will lose more face in our organization, and I will be trifectively pissed off (not to mention that I'll be known as the guy who wrote the slow program).

Should I just give in? Is my hubris leading me down the path to Disaster? I don't know. I just don't know.

  higle

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.