h2g2 The Hitchhiker's Guide to the Galaxy: Earth Edition

You might also want to include a link to the entry about the goto statement on http://www.bbc.co.uk/h2g2/guide/A354629

Infinite loops ARE useful: Eg, in XWindows, the following code is standard:

do forever {
XEvent e = nextEvent(); // blocks until an event is received
dealWithEvent( e );
}

On a smaller scale, I've written quite a few daemon threads which are designed to never terminate - just sit there, continuously doing something (garbage collection, for example, or responding to user input, or listening to a network socket} until the program terminates.

As for jumps inside loops: well sometimes they are the easiest and clearest way to express something - often, yes, such loops can be better written as conditional loops - but sometimes that's not the sensible thing to do - you make the code more complicated for no real gain.

Every rule has occasions where it should be broken, including this one...

I don't think that I said that they were not usefull, only that in most circumstances they should be discouraged. a bit like goto's really. (they are often essential in error trapping).

oh right: I misread you...

I'd prefer a decent exception handling system to GOTOs, myself - it's always seemed like a gross hack in a rather critical part of any system...

oh god.
first it's too simple, too C.
now it's too complex and too C.
Ok, lets try and get a consensus before I change it, again:
1)I should use psuedocode examples of the different types and put the C stuff in an entry of it's own.
2)I should put the assembly stuff in an entry of it's own.
3)Include things that need to be considered when programming loops in the entry with the psuedocode

Is that the right way to go?
Researcher PSG

[delurks]

sounds good!

I'd have a couple of sentences at the beginning explaining that you're using pseudocode and why. That way, folks will understand that real coding is done is various cryptic syntaxes (syntaces?), which it would be pointless to go into in an entry like this.

GTB

[relurks]

[delurks (as has become the industry standard)]

Sounds about right. Definitely lots of user-friendly pseudo-code with lovely real-world examples for the Computer User Non Technicals among us.

As I suggested before, maybe some information about why programmers need to use loops would set the scene.

BBS

[undelurks]

[was never lurking]

That's the way I'd go myself, if writing an entry on "Programming Loops", generally. If you do decide to go the C/assembly route, then that's entirely possible too - in which case, do something like:

1) change the title to "Programming Loops in low level languages" {or something similar}
2) {optional} Include some of the more fun assembly loop stuff - delayed branches, branch prediction, etc.
3) umm - I think that's it.

Either option is possible and could result in a entry worthy of inclusion in the guide. You'd possibly get a larger audience if you chose the non-technical option - but then you may feel happier and more comfortable with the technical option. Or, you could be enthusiastic and write both!

The choice, PSG, is yours!

*ahem* Anyways... as you've already discovered, the difficulty with Peer Review is that we're only peers, not superiors - so often we give bad or conflicting advice, squabble amongst ourselves, and otherwise make a nuisance of ourselves. You're a peer too: if you want to get revenge, most of us here have an entry or two in peer review as well - feel free to find such entries and slag them off in return...

[still isn't lurking]

We are supposed to be offering "CONSTRUCTIVE" criticism here folks. personally, I would copy your source into a text editor, and cut it into an assembly piece, a C piece, and the one on loops. that way you get three entries for the price of 1 peer review, and they should sail through when you submit the others.

[stops ambling around]
Well I've changed the entry yet again, and split it into 3.
please take a look at all 3, and give me questions, comments, criticisms, and feedback in genral on the new form, so I can hopefully put it finally into a final form.
Thanks for your patience.
Researcher PSG
[returns to ambling]

* just stomps into this ongoing discussion *

Hey, it's been some time since I read this entry and forgot to put in my 2p. Well, there's been quite an improvement since!

After dividing the thing into 3 entries, you should cross-reference them in all directions (ok, this might lure readers into infinite loops, but nobody knows which entry somebody finds first).

As to the Java example: does anybody know whether there's an intelligent Compiler around there that issues an alert of some kind or other if it comes across that misplaced semicolon?

Assembly example: is there any web source for the 'GOTO Considered Harmful' paper?

And finally, I'd like to quote Dudemeister on this suggestion: pleeeease, use the word 'hell' as one of the labels in your listings :

>> if { error condition met }
>> then goto hell
>> else { continue useful stuff }

Now isn't that a brilliant example for self-documenting code!?

(Re: Posting 48)
>> You're a peer too: if you want to get revenge,
>> most of us here have an entry or two in peer
>> review as well - feel free to find such entries
>> and slag them off in return...

There's more truth in there than you might believe (can become an infinite loop, hint, hint)

Niiice. I like the three examples of loops in the introduction entry. I just have some nitpicks.

The text in the "The Condition" section is a bit weird, language-wise (look who's talking ). I recommend changing it to the following.

The Condition

This is fairly simple to define; it is a logical or arithmetical[footnote] equation which is either true or false. For example, "A + B = 5" is a condition which is true when the sum of the variables A and B is equal to 5.

In the case of loops, the condition is used to determine whether or not you leave a loop. It depends upon the nature of the loop you're using whether a true or false value is used to let you leave. For the examples I will use True to allow looping, and False will stop looping.

A thing to remember about the condition is that it has to be possible for it to change state, so the loop can stop. Basically this means that within the loop code the value of the variables used in the condition have to change, so in the example above the value of A and B have to be changed by the loop code (for a clearer explanation see The Problems of Infinite Loops).

Nice division, I think.

Myself, I'd put a simple example right at the very start of the entry on loops - and then go on to explain it in terms of condition, body, etc.

Oh, and I believe that java doesn't have the problem with errant semi-colons in while - last I checked the compiler warns that "an EmptyStatement is a deprecated feature" {or some such}.

Thanks for all the feedback, I am glad most of it is positive.
The few small amendments are being looked at.
However on the point of Java not having the semi-colon problem, well I still think it is best to point it out, if nothing else to help them make sense of an obscure error message.

Thanks again

Researcher PSG

I still think that as an introduction to programming loops this entry is far too complex for someone who hasn't been near a computer. Even as an experienced computer person I have to think about what I am reading.

Maybe I'm underrating the Computer User Non-Technicals among us, but I really don't think this entry is going to add any value. Maybe I should go write my own version and put it up for PR and let the world choose between the two ... in fact that's what I'm going to do.

Nothing personal intended, you understand.
BTW could we have the links put on one of these forum entries, please.

BBS

OK here's my effort ... http://www.bbc.co.uk/h2g2/guide/A533864

Actually as an introduction and avoiding code specifics I'm not sure what else can be said.

I just took another look at the entry PSG's entry and noticed the section's in the middle about loops where we pre-check, post-check or set number of occurrences check. It's very good, unfortunately on my previous read I never got past the "Aspects of Loops" section because of it's techy nature.

That said I'm not sure about the counting loops sections accuracy. I don't think it really represents a counting loop (of which I am thinking of a FOR ... NEXT loop). Admittedly it is hard to think of an example for this type.

Nice work.
BBS

OK by popular demand I put the example first and the detail after.
Next I've looked at Bright Blue Short's entry, and no offence it's a little glib and misses the point. The point is looking at programming loops within the area of programs, NOT looking at programming loops in the area of life. In other words, how life would be written in a program, not how the program is written in the story of the real world. Which is why it has been tricky to get right.
So if everyone could take another look and tell me what you think, I'd be grateful.

Researcher PSG

P.S. the counting loop example was the best I could think of, I will gladly look at any better ones.

Hello!
replying to my own entry how boring of me.
OK I may have been a little harsh on Bright Blue Short's entry, I blaim stress and 6 or 7 re-writes.
But I still feel the emphasis should be on life as code, as in the examples in the latest version.
My entrys is there and if anyone has any comments, or offers of psychiatric counselling, I'd be glad to hear from you.

Researcher PSG