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.

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

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...

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.

• The First System is the 'management simulation' for the Powers-That-Be; something they can look at and decide that the title-bar should be puce and not magenta.
• The First System is the 'limited functionality' demo for the End-Users; so they can see how the various widgets interact with each other.
• The First System is the one with the 'abstract data-base interface'; so that the DBA's can try different databases out and find the best one for the User's needs and Management's requirements.
• The First System is the 'We Think It'll Look Like This' system that Operations uses to write the Run-Books and Procedures from.
• The First System is the one that supplies 80% of the needed functionality after a week's worth of work by two people.

And once you have your "First System" up and running, then is the time to decide whether or not it's worth while to re-write something works and something that people are familiar with in C/C++/Java.

I am very fond of building mock-ups of The System in Perl so the various parties can all get their hands on something early on in the design process. Changes are much easier in scripting languages. I can give Them almost instantaneous feed-back ("Here it is in magenta; (click-click) now here is puce"). And if my "mock-up" is good enough, I get my System designed and out the door that much faster.

Yes, it's not as "fast" or as "sexy" as it might be if it were written in C/C++; but it's here, right now, in your hands; not sixteen months (if we are very lucky) away. Yes, The System is written in Perl (or Python or Visual Basic or REXX) -- so? It serves our needs now while the new super-whiz-bang is being developed by the Crack Infrastructure Development Team. Think of it as a bridge between today and the day that the Crack Team finishes....

I have had a lot of experience in bridge-building. And I build them as if I will be using them still in five years time. I may over-engineer my bridge a bit, but I get to sleep better at night because of it.

Good example, and it may have well been given in answer to the original question. All in all seems like a particular instance of optimizing developer time...

"Bridge building"... I like it.
It did leave me with an image of a mile-long bridge extending out into the ocean, with nothing on the other side...

"The Crack Infrastructure Development Team needs to push back implementation another three months."
"No problem. We can just add another span to the bridge!"

:-)

Note that adding cooks *increases* cooking time...
-- WARNING: You are logged into reality as root.

Note that adding cooks *increases* cooking time...

Hehe! And also:

• "The bearing of a child takes nine months, no matter how many women are assigned."
• "Adding manpower to a late software project makes it later."

(Both from Frederick P. Brooks's "The Mythical Man-Month".)

But... is the person you're answering to really talking about adding cooks or about adding ingredients? Well, I guess it may well be a matter of personal taste and interpretation, or pov. And anyway... does adding ingredients increase cooking time? In principle yes - obviously. It all depends on whether it does so negligibly or considerably, and how good the final taste will be!