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.

"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;

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;

I'm pretty sure that DEBUG and will be optimized out when DEBUG is 0.

Likewise, I'm pretty sure that if DEBUG would be optimized out when DEBUG is 0.

I'm guessing it's the use constant DEBUG part that other people think is not simple.

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.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)

In the absence of evidence, opinion is indistinguishable from prejudice.

I have no problem with until or unless. I'm just conceding that using or (or and) for flow control is not as clear as it could be - and admitting that my own use of or (or and) for flow control is more out of laziness than anything else.

As for until or unless, I will use those when I would use them in prose describing what's going on. For simple conditions, readability and maintainability isn't hard and the of until or unless is, arguably, more natural¹.

I'm thinking that complex conditions run into problems because the conditions are written in mathematical/logical notation (as they should be), so making the (implicit) surrounding not ( ... ) progressively more awkward to factor in.

---

¹ some would argue that using until or unless is harder for new coders. Every day language of people I hear in places I visit as I go about my daily life has a lot of "until" and/or "unless" in it.

Side note: Pascal has both a while ... do begin ... end loop and a repeat ... until ... loop. Very different syntax for the 2 loop styles, but functionally the same as while and until in Perl (and some other languages).