|Keep It Simple, Stupid|
I'm sure those who have worked developing products for companies, the bottom line of the ideal business-man is, it works well enough to sell and keep selling. They don't want the perfect, most efficent, most elegant product. They want it to do X, Y and Z right now, and when A, B and C gets thought up, they'd love it tomorrow.
The ideal programmer wants things to work really well, easy to develop for etc etc.. with infinite time, or at least until it bores them. :)
As an idealist to some degree, I push for refactoring, doing things right, prototyping etc etc.. while I get a huge pushback for getting it done within acceptable deadlines. There are process related routines and standards that companies can get to, so that business can start an idea, and developers can polish off a finished product.
For instance, prototyping. You can test all the points in preliminary prototypes, to show some sorta baseline of comparison to how it should work. Think of it like the omega(), as there is minimal load and users hitting the systems with weird sitatuations. If development is a much slower environment, it may be closer to real life. But you get a feel for what you are doing. Eventually, you can port your prototype to your ideal language or grow it to your final product. A research phase also helps, where you can create pre-prototypes and architectures to play around with.
But at any rate, perl is a great language for at least research and prototypes. It's a VERY quick-to-write language. You can flush out architectual mistakes quickly. Many script languages are like this, and it is typical to have some sorta RAD interface for building these throw-away things. Or create non-throw-away stuff if you wanna grow your final product.
Not sure what you were looking for in a response, but adding my two cents.. for whatever it was worth :)
Play that funky music white boy..