Re^3: next unless condition

[dsheroh]

There is a difference in operator precedence between $cell || next and $cell or next, so they're not quite the same. While they're effectively identical in this case, even the minor modification of adding an assignment results in $x = $cell || next and $x = $cell or next behaving differently.

The efficiency explanation you've heard is accurate when dealing with extremely-close-to-the-metal languages and non-optimizing compilers, since testing whether a memory location already holds the value 0 is one of the fastest tests you can do at the machine level. But optimizing compilers are smart enough to figure out for themselves that if (not $cell) ... is equivalent to $cell || ... while still allowing you to write it the more readable way, and Perl is so far from the metal that these kinds of concerns are completely inapplicable anyhow.

[Marshall]

I agree that you should write the clearest HLL code possible. At the local college I work with ASM students and sometimes we play "beat the compiler". With the right example, even a beginning student can do this vs the highest optimization level. This example would not be a good one because if (not $cell) ... and $cell || ... will code every similarly even with a "dumb" compiler. They are essentially the same. Load from memory, ALU operation to set flags, jump on flags that were just set. The ALU operation could be a or eax,eax(nothing but set flags) or  neg eax (negate and set flags). Different kind of jump instruction required but timing is the same. I wouldn't worry about this at all.

A bigger mistake in source coding is to assume that shorter source code maybe with a bunch of fancy maps, joins, and other functions is faster than longer code that is more straightforward. You can write one line in HLL that takes a lot more work at the low level that something else that takes many HLL lines.

[RonW]

Load from memory, ALU operation to set flags, jump on flags that were just set.

FWIW, in some CPUs, the load instructions will also set/clear the "zero" and "negative" flags.

You are right. As a rule, today's optimizing compilers are very good at producing (near) best machine code.

With Perl, I'd say just write the most understandable and maintainable code you can.

[BrowserUk]

With Perl, I'd say just write the most understandable and maintainable code you can.

It may surprise some here that I wholeheartedly agree with this statement.

The problem comes with defining the target audience, and what they will find understandable.

I personally find $DEBUG or ...; eminently readable; ditto  ... unless <cond>; and  ... until <cond>; where the condition is more accurately or clearly expressed in the negative.

But there are whole chunks of the IT community who have never used Perl -- and seemingly a large part of Perl community -- for whom these constructs are somehow 'difficult to read'.

Many seem to think that if not ...; is somehow *always* more natural or clearer than ...unless...; which I find bewildering. Contrast:

• "I'm here until September or the money runs out."

  "I'm here while not September and not the money runs out."

• "Don't go in unless you're invited."

  "Don't go in if not you're invited."

• "Don't cross the road until you've looked both ways and the road is clear."

  "Don't cross the road while not you've checked both ways and the road is not clear."

And then there are those that suggest that I should not write for me (or those with my level of Perl); but rather for those new to Perl, or perhaps those for whom English is not their first language, or those who are complete newbies to the world of programming.

To which my response is: if we all write all of our code as if the target audience are newbies; then they will never grow as programmers, because they are never stretched to learn new stuff; and we will never grow as programmers because we are ham-strung into targeting the least common denominator; and programming languages will never grow because no one is allowed to utilise their full feature set.

To me: dumbing-down our code, because someone, somewhere may not understand it -- or is too lazy to update their skills in order to understand it -- is the stupidest idea to plague the IT business (in a field full of stupid ideas), in the last 30 years. It is the equivalent of doctors resisting antibiotics in favour of leeches.

[Marshall]

"With Perl, I'd say just write the most understandable and maintainable code you can." I definitely agree with that. Sometimes I see posts that use obscure and unnecessary language features that don't improve the efficiency of the code. Perl is a big language and not every thing that is possible should/needs to be used. The uncommon stuff should be used when it is really needed, not to impress some "new" monk. That is just the wrong way to teach Perl.

Yes, you are quite correct about load instructions. I've written ASM for Intel, DG, DEC, IBM, Motorola, SEL, Zilog and a few other very weird processors. I've even designed the hardware for 2 DSP processors myself. For those there was no ASM language, all code was what is called microcode. That is some hairy stuff to write because there is no O/S and it is possible to code instructions that can actually damage the processor (like say cause a conflict on a bus). If I remember right a load on a DG processor would set the flags, but that is not true on an Intel processor.

I think we both agree that using the Perl language features in a way that describes the algorithm clearly is the best way to go. I'm all for using the full power of the Perl language. I'm not saying that we shouldn't or that the code should be "dumbed down". I just object when the code is unnecessarily complicated. Sometimes it is necessary to be complicated.

We do have the problem where things that I think are simple, others think are complicated. I just wrote a piece of code with "DEBUG and print....", to me that is simple. I used the constant module, use constant DEBUG => 1;. The advantage of this over $DEBUG is supposed to be that Perl will eliminate the "and" if DEBUG => 0;