Re: Program size and effeciency.

[davido]

Your boss has to weigh the cost of a few more seconds of processor time versus the cost of paying you to rewrite the script, and then to debug what you wrote (a rewrite is going to introduce new, unexpected bugs).

Perl is about getting things done. While you may be itching to fix the code you've been charged with, it may not be cost effective to do so.

One of the biggest mistakes a programmer can make is to go and make a bunch of significant changes to something that's been working fine for a long time. Change may be warranted, but take the time to understand before jumping in to big changes.

[biosysadmin]

Definitely. Paul Graham is a well-reknowned software guru who has written a lot about this idea. I've read one of his essays (available on his website) in which he talks about the early days of his online e-commerce venture, and how using a very high-level language (LISP in his case) translated to a great deal of productivity.

He's a LISP hacker, but once you forgive him for that he really has some interesting stuff to say. :)

It sounds like one of the concepts that you are attempting to convey to your boss is that very functional Perl code can very quickly grow into an unmaintanable mess. If that's the case, then I think that you could point out to your boss that it's very difficult to make Perl get things done when your programmers cannont understand the codebase with which they are interacting. Your company may gain value by refactoring and redesiging (or at least properly documenting) your Perl codebase. In making a case to your boss, there are a number of software engineering books on refactoring, design and documentation.