Of course, perl allows you to enable stricter coding guidelines with various pragmas such as 'use strict', and 'use warnings' (and actually 'use Module' in general makes for less-dirty code...). Hence the mantra "Perl makes the easy things easy and the hard things possible."

-Blake

I understand the context of 'dirty'.

we can very well use "for onetime only" instead of "dirty".

It's actually, in my opinion, the best feature of the language - the support for development efforts of all shapes and sizes.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Besides when it comes to getting a job done expeditiously, quick and dirty are two of the most revered adjectives that can be ascribed to code.

especially these days, with hardware so cheap. i've implemented viable solutions at work with cast-off hardware using debian and perl. my primary scripting host is a p75 with 64 mb ram and a 1 gb hard drive. i can leave it sitting there, running all day on various and sundry tasks that deliver real value in a very unobtrusive way, seemingly out of nowhere. as time goes on i revisit some of the stuff and clean it up, enhance it as my skills develop, but when the marginal utility of developing something new exceeds that of smoothing functional code by several orders of magnitude, it's hard to justify worrying about being fancy.

optimizaqtion, in a mathematical decision-making context, refers to finding the appropriate balance between resources expended and return. when the hardware you are using would be valued at $50-75, it's hard to justify spending $150 of my time squeezing cycles until i've reached the point at which the new stuff i want to add is contrained by what is already running (or the other way around, whichever way you want to look at it.)

look at it this way. i work in the labs of a state health department. if i deliver three solutions that occupy 6 hours a day on a machine that would be surplussed if i weren't using it, is that less optimal than delivering two applications that run in two hours? which solution do you think the taxpayers would prefer?

Liberating words. A theme I've read dragonchild on, more than once. Code needs lots of different kinds of resources to run. CPU, memory and all that stuff, sure, but also Write Time and Fix Time. Perl seems to shine when those last two are the ones you want to minimise. And given that everything else is getting cheaper and cheaper, that's a good strategy (as well as being one instinctively favoured by the geeks who do the Write 'n' Fix). For me, self-"employed" (quotes meant to dispel any illusion I might be getting paid) writing an application for a web site well past its launch date, this translates into "if the site goes live a month earlier, it'll make enough money in that extra month to pay for the RAM and processor speed you would have saved by farting around getting the code to go quicker."

Nevertheless, I always find myself worrying about little improvements that take a long time to get done. Perhaps this confession will help me to cut to the chase with renewed vigour.

§ George Sherston

For better of worse,
I don't like the word dirty, It some how associates with the word 'bad'.
Nothing personal towards anyone
It's just me.. ------------------------------- print 'just another perl lover';