Talk:Loops/Do-while

self-contradictory task?

If value is supposed to start at "zero" and looping is to be performed "while value mod 6 is not equal to zero", then it follows that the loops should be executed zero times since 0 mod 6 == 0. Requiring that the loop should execute at least once is in conflict with the other requirements.Sgeier 04:54, 15 September 2009 (UTC)

I believe the goal is to demonstrate a post-execute condition check, but I don't have a good idea of precise-yet-clear ways to describe it, and that interpretation of the behavior is specific to imperative programming. "Process at least once, or while condition is true" might be closer. --Michael Mol 06:31, 15 September 2009 (UTC)

Start with a value at 0. Loop while value mod 6 is not equal to 0. Each time through the loop, add 1 to the value then print it. It is not clear (maybe the title do-while should suggest that, at least to C-or-similar coders), but the condition is tested at the end of the loop, so that the value has get incremented already (each time through the loop ad 1 to the value). Anyway the final The loop must execute at least once can be read as: (if needed) fix it so that the loop is executed at least once. --ShinTakezou 09:18, 15 September 2009 (UTC)

is this a task at all ? Certainly not a Rosetta task ...

Fortunately the Rosetta scribes were given a task, which they solved across a range of very different types of syntax and writing system – they weren't asked to footle around in the superficial syntax or hieroglyphics of a particular type of language or orthography.

I see no sign of a task here at all – no statement of a problem (just a slightly parochial focus on some surface syntax of a kind which many languages don't even use), and no specification of inputs or target outputs.

Something drifted completely loose from the Rosetta project here ...

Helpful, I think to check off the basic Rosetta goals before signing off on a task – this one needed much more work before it could even qualify as a task.

Look at the landing page and remember the goals:

1. The idea is to present solutions to the same task in as many different languages as possible
2. demonstrate how languages are similar and different
3. and to aid a person with a grounding in one approach to a problem in learning another

'Loops/Do-while' fails to qualify as a Rosetta task in all three respects. (That is, in fact, its main computational achievement :-)

1. Many languages make no use of 'Loops' or 'Do-While'. That is not how they approach problems.
2. Far from showing how languages are similar and different, it appears to assume that all languages will obviously be the same. Short on insight and depth.
3. Too parochial and superficial to help learners build any insight. More of an obstacle to insight than a resource for learning.

What is to be learned ?

- Use the 3 Rosetta goals as a basic editorial checklist

- Raise the game on depth and insight

- Actually state a problem and a task

I disagree - the task requirements seem well enough defined and the solutions do demonstrate how the languages differ in syntax. There are also a number of solutions in languages that don't have while loops. These are interesting too.

Absolutely – there is certainly a potential task here, and posters have responded creatively despite its defective formulation. The main problem in this (and in a set of related (aspirant) tasks) radiates out from defects in the way they are framed and named. (A secondary problem here is the lack of a required output, which is a necessary stimulus to richer and more transparent comparability. These tasks should have been (and could still be):

1. Gathered around a less superficial and more revealing concept and word. Perhaps, for example repetition.
2. Presented in terms of the general problems that arise with repetitive processes, rather than in terms of "loops".

Instead of offering deeper insight and a clear framework for comparability and contrast, the use of a narrowly imperative idiom was procrustean and distorting.

It should have stated an actual problem (in more general and insightful terms than loops), and an invitation to solve the problem in the manner best suited to each language.

Instead, it forced several languages into artificial and potentially misleading exercises. The comment following the J example is symptomatic:

"Though it's rare to see J code like this."

Editorial suggestions:

1. Raise the game in terms of breadth (relevance to more languages), depth (insight and generality in lieu of superficial syntax fetishism) and usefulness to users (clear problems, good comparability, and encouragement of undistorted code) in the framing of future tasks.
2. Rename the 'Loop' tagged tasks in terms of 'Repetition', and clearly frame the general problem in each case, without limiting or distorting presumption about how languages should tackle that problem.

Perhaps, for example:

Conditional repetition

Halting repetition

Repetition - special terminating cases

Repetition - handling exceptions

etc etc.

Even more eloquent than the name, however, is a clear example of input and output. (Missing, in this case). Hout (talk) 20:21, 21 September 2015 (UTC)