Select wisely the idioms you use.

Believe me, I do!

I, for one, would not use that one because I find it is just for the sake of brevity without its being worth one more thought every time it is read.

So you optimise your code in order to save the maintenance programmer, "one more thought", during each of his occasional visits over the future life of the code.

Say that "one more thought" requires 5 seconds; or 10, and the code stays in use for 10 years and the maintenance programmer visits it one every 6 months, or three; over the lifetime of the code you've "saved" a maximum of 400 seconds (0.11 hours) of programmer time.

Now. let's say that the difference in performance of that one usage, is 1% on the overall runtime; and over that 10 year lifetime the program runs for 8 hours a day every work day for those 10 years, then you have cost the users of that program 208 hours of their time. The owners 208 hours of extra processor wear, electricity and air conditioning costs.

Now lets say there are 3 uses of that idiom; and half a dozen uses each of half a dozen other efficient idioms that you reject; and the difference in runtime isn't just 1% but 25%.

Now your "potential" savings in programmer time over 10 years becomes 1236 seconds, A whole 20 minutes!

But your cost to the users and owners is: 5000 hours! Of user time, cpu resource, energy.

Now, perhaps you are a webcoder

and the entire idea of code running for 8 hours per working day is an anathema; so think of it in terms of potential customers lost because your maintenance programmer friendly code causes the page load time to move from 2.75 seconds to 3.25 seconds and your impatient target audience of millennial teens are known to move on if a load takes more than 3 seconds.

How many "one more thoughts" do you need

to save the maintenance programmers during their occasional visits over the next 10 years to make up for hundreds or thousands or tens of thousands of incomplete loads per day of your middling-sized 365/24/7 commercial website?

Now consider that much of the code I write runs on tens (and sometimes thousands) of cores concurrently,

and for days and weeks at a time. 1% saving can save my clients thousands of dollars. On at least one occasion hundreds of thousands; per run. And it is not unusual for my code and algorithms to save not 1% or 10% of runtime; but frequently 50% or 80% and on occasion 96%. Ie. runtimes projected to be multiple years, now complete in weeks or even days.

And these are not one-offs, but regular gigs over the last 15 years -- I've made a pretty good living at it. And beyond the occasional novel algorithm, a large part of that work has been underpinned by writing what is often fairly prosaic algorithms as efficiently as Perl allows. Ie. Using Perl to its best effect.

And finally,

everyone who has read my post and your reply -- including you -- will, barring a catastrophically short memory, now always instantly recognise the idiom we are discussing and almost subconsciously recognise its equivalence to your preferred form.

That is the very purpose of, nay even the definition of, "idioms". They are 'patterns of usage'; short forms of more complex code that, with regular usage and familiarity become as recognisable as the languages native constructs. They become as a part of the language to those who have taken the time to become familiar with them.

If your Perl code is used as a training aid -- you're a teacher, lecturer, or book writer -- then your "optimise code for the casual reader, newbies and maintenance programmers" stance has some merit; otherwise it is the very definition of premature (naive, unfounded, illogical and thoughtless) pessimisation.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.