in reply to [Quote] When should I use Perl?

I start from the position that there is no answer to such simplifications of projects. No language is always the best tool (and, by extension, any advocacy that always pushes a certain language for all situations just shows everyone that it's just hype instead of valuable advice).

The thoughtful planner should also note that using Perl doesn't automatically come with savings in developer time. If you're somewhere that already has a big investment in another language, good libraries to do the things you need, and good programmers who truly know that language, you probably will be able to develop faster in that language. Starting from scratch in Perl can have a lot of ramp up time, and if you are new to Perl you're going to spend a lot of time just figuring out how to do all the things the monks take for granted.

Even bringing a good Perl programmer into a non-Perl shop can be especially slow. There may be long term benefits, but in the short term development will not necessarily be that fast. It really depends on the particular developer and the work environment.

The last big code review I did optimized for developer time and lost so poorly on execution time and memory that it ended up killing them later. They switched to Java, which I think was a good thing for them considering their in-house skill sets. Perl will let a less-than-good programmer get something going quickly, but without a more-than-good programmer you may have to pay for that later.

So, the question of "Why should I use Perl?" almost answers it for you: if you don't know the trade-offs involved and you don't know what's more important to you, any answer is pretty much worthless because it's just a guess.

--
brian d foy <brian@stonehenge.com>
Subscribe to The Perl Review

Replies are listed 'Best First'.
Re^2: [Quote] When should I use Perl?
by demerphq (Chancellor) on Dec 27, 2006 at 08:26 UTC

    The last big code review I did optimized for developer time and lost so poorly on execution time and memory that it ended up killing them later.

    IMO this illustrates a problem I've long felt existed in the "optimise for maint/development time" school of thinking. I call the problem "death of a thousand cuts". Each decision in writing a program when answered with "do whatever is easiest to code" adds a tiny of bit of fat to the code. Once the app is complete the code becomes like a nice steak, marbled with fat. And just as its nearly impossible to remove the fat without turning the steak into something rather different (groundbeef) its nearly impossible to remove the fat from such a program without a pretty much complete rewrite.

    I really think that the "optimise for maint/development time" needs to always be tempered by "so long as unnecessarily wasteful constructs are avoided" and "as long as the dev/run time benefits are aligned". It is possible to write reasonably maintainable code that is also lean and efficient. It just takes a little care and knowledge. The problem is that a lot of this knowledge is what most people (even me) would call premature optimisation when looked at in isolation.

    ---
    $world=~s/war/peace/g

[reply]
      It is possible to write reasonably maintainable code that is also lean and efficient. It just takes a little care and knowledge. The problem is that a lot of this knowledge is what most people (even me) would call premature optimisation when looked at in isolation.

      All nice points! But wrt this last point I feel like differing: the vast majority of all instances of premature optimization I find worth pointing out, and "condemning", as such are for speed, not certainly for maintainability...

[reply]
Re^2: [Quote] When should I use Perl?
by blazar (Canon) on Dec 27, 2006 at 12:47 UTC
    I start from the position that there is no answer to such simplifications of projects. No language is always the best tool (and, by extension, any advocacy that always pushes a certain language for all situations just shows everyone that it's just hype instead of valuable advice).

    Well, indeed any quote like that, i.e. a witty remark, has no pretension of telling a Grand Truth(TM) -or, well, it not necessarily has- even if/when it is deliberately thought to sound as if it did. (And most certainly I don't expect it to.) Given that it is easy to agree with you on the fact that there is no answer to such simplifications, and this tells much about the value of the original question, I still think it clearly, concisely, wittily underlines one of the aspects involved in the matter: not certainly the only one, but possibly the "biggest", thus providing a gross, first order approximation.

    So, the question of "Why should I use Perl?" almost answers it for you: if you don't know the trade-offs involved and you don't know what's more important to you, any answer is pretty much worthless because it's just a guess.

    Nearly a witty quote too. Just slightly too verbose for my tastes. It's a sorta Zen thing: if you need to ask, then any answer is pretty much pointless.

[reply]

In Section Meditations