Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

geoff (2013)

  reversethis-{gro ... om} {ta} {ffoeg}

see [] for personal information, links to presentations, GPG key, and so on.

Journal of geoff (2013)

Thursday December 19, 2002
09:06 AM

"Is PERL the most optimal way?"

[ #9546 ]
I've been working on a smallish but vital system (written in Perl, or course) for the past few months. The other day a question came down from VP to Director to me: "Is PERL the most optimal way for us to do that?"

now, that's about the most loaded question I can think of - probably rooted in the old Perl == CGI idea, washed down with an unhealthy dose of java kool-aid.

so, after deciding that being able to handle 4000 transactions a minute (when we only get 3000 a day) probably wouldn't be a sufficient answer, this morning I took a moment to analyze my smallish system in ways that would matter to me if I were an (unbiased) VP:

- 14 OO classes (with inheritance, etc)
- 7645 lines of (well commented) code
- 3687 lines of documentation (real pod, not including above comments)
- 654 tests (that have saved me more than once)

I'd wager that the test suite alone makes it the most optimal piece of software in the company, but I don't think that's what he meant :)
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Unless you're certain that the VP meant "optimal" in terms of performance, I'd look at the question again. Answering that you can handle the transaction load might not address his concerns. He could be worried about several other things, such as "If you write that in Perl, will we be able to maintain and support it?" or "If you leave, will we be able to find someone else to pick it up?" or "Is Perl really a serious language?"
    • what I was trying to do in my own (brief) analysis is defend exactly the three points you bring up: yes, the software is supportable (well documented); yes, others will be able to maintain it (with a test suite, at least they can't break anything that currently works); yes it's a serious language (it can take advantage of OO like everyone else).

      I actually didn't expect that he meant performance :)
  • What are your choices? Saying how much longer in time and code would it be in Java, .NET, or PHP is a good response.


    • actually, I suspect that he's leaning either toward java (the company standard) or something more abstract, like "XML" - both of which fit the nature of the project. What he will likely be shocked to find is that I've been advocating (and capable of supporting) the use of direct SOAP calls to my API for a while (as opposed to the daemon approach it uses now - SOAP::Lite++). I keep hoping somebody will take me up on it so I can giggle as the Java people try and keep up :)