Talk:Loops/Do-while: Difference between revisions
(→is this a task at all ? Certainly not a Rosetta task ...: - I disagree) |
|||
Line 36: | Line 36: | ||
: 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. |
: 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): |
|||
:::#Gathered around a less superficial and more revealing concept and word. Perhaps, for example ''repetition''. |
|||
:::#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: |
|||
:::#Raise the game in terms of generality, depth and usefulness to users in the framing of future tasks. |
|||
:::#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). [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 20:21, 21 September 2015 (UTC) |
Revision as of 20:21, 21 September 2015
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:
- The idea is to present solutions to the same task in as many different languages as possible
- demonstrate how languages are similar and different
- 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 :-)
- Many languages make no use of 'Loops' or 'Do-While'. That is not how they approach problems.
- 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.
- 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):
- Gathered around a less superficial and more revealing concept and word. Perhaps, for example repetition.
- Presented in terms of the general problems that arise with repetitive processes, rather than in terms of "loops".
- 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):
- 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:
- Raise the game in terms of generality, depth and usefulness to users in the framing of future tasks.
- 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.
- Editorial suggestions:
- Perhaps, for example:
- Conditional repetition
- Halting repetition
- Repetition - special terminating cases
- Repetition - handling exceptions
- etc etc.
- Perhaps, for example: