Answers.Body: <p>Some programming and coding workflows\patterns make the repetition rather insignificant. </p>
  
  <p>For example, if one teaches to have constants set from the beginning, something like:</p>
  
  <pre><code>init:
      questionText="Do you wish to continue?
      accept="good"
      finished="good bye"
  
  main code:
      answer=input(questionText)
      while answer=="yes":
          print(accept)
          answer=input(questionText)
  
      print(finished)
  </code></pre>
  
  <p>and then if there was a mistake in the text,  (as there is in my example), it's very easy to fix, without needing to copy-paste.</p>
  
  <p>As for elegance, I agree that the second option is a bit more elegant. However, it forces the code to enter  the loop, and when teaching, it's far better to break an example into smaller parts, so as to allow students to understand each component separately, before they tackle the entire thing.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-29T15:31:51.743Z
Answers.LastActivityDate: 2018-01-29T15:31:51.743Z
Answers.UserDisplayName: ItamarG3
Answers.Body: <p>There are different loop structures for very good reasons. In my early introductory programming examples, I stress at least three types of loops which are <strong>not interchangeable</strong>:<br>
  1. Loops that read data require a <em>priming read</em> before the test at the top.<br>
  2. Loops that test at the top can use a flag variable which is changed in the body.<br>
  3. Loops that test at the bottom must execute at least once.  </p>
  
  <p>These must be explained clearly and with good explanations of why they are used in different circumstances, otherwise you will be condemning people to making many painful bugs which could be easily avoided.</p>
  
  <p>The other vital concept is that every loop (including recursive method calling, as in Functional programming) has three requirements:<br>
  1. The control variable must be <em>initialized</em> before the loop begins.<br>
  2. The control variable must be <em>updated</em> in the body of the loop.<br>
  3. The test that controls the loop must have an <em>achievable end condition</em>.  </p>
  
  <p>Without those basics in place, students will flounder.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-24T17:44:52.010Z
Answers.Text: Welcome to [cseducators.se].  This is a great first answer, and we're always glad to have CS educators join us here.  :)  It sounds like you'll have a lot to contribute.  Feel free to ping me if you need any help navigating around while you get started.  (Just add another comment to this answer and start typing `@b` and my name should pop up.)
Answers.UserDisplayName: Ben I.
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-24T15:51:46.100Z
Answers.LastActivityDate: 2018-01-24T15:51:46.100Z
Answers.UserDisplayName: user4143
Answers.Body: <p>I don't particularly care for either as a <em>first</em> program, but the second version makes the case for <em>Say It Once</em>, i.e. don't repeat code. </p>
  
  <p>However (a) it is awfully early to be stressing that rule and there are better examples that can come along soon, and (b) making the case for the rule requires showing (and discussing) <strong>both</strong> programs. </p>
  
  <p>Showing both can also help make the case (in a smallish way) that different programs have the same effect. </p>
  
  <p>On the other hand, I wouldn't rate one over the other based on just the fact that you mis-typed, but rather that programs change. Saying the same things twice doesn't hold up well if the prompt needs changing and you want it to be the same on the first and subsequent responses. </p>
  
  <p>However, you might want them to <em>not be</em> the same. That again requires some explanation and discussion. </p>
  
  <p>But that is a lot of weight for the <em>first program</em> to carry. </p>
  
  <hr>
  
  <p>For the mis-typing issue I'd rather use a UI that makes the syntax error visible before you progress any further making that moot. </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-24T18:33:49.293Z
Answers.Text: Not the firs program, but the first program is like one I have seen early in a course. The error I made is just an example of why you may need to re-edit.
Answers.UserDisplayName: ctrl-alt-delor
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-24T18:37:41.927Z
Answers.Text: Could you add some advice as to how to introduce loops? (in python). I like to start with a `forever` loop in scratch. But python does not have them. [May be this is a new question]
Answers.UserDisplayName: ctrl-alt-delor
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-24T18:52:56.643Z
Answers.Text: What you have is fine, but it is a lot for a first program. In python you can say while true:, of course. You can also write a function that just loops forever and call it. Since you write it, you can have it expect a lambda expression. (Caveat - I haven't worked out the details of this and tried to integrate it early, but I think it would work.) Python is pretty flexible.
Answers.UserDisplayName: Buffy
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-24T12:50:26.280Z
Answers.LastActivityDate: 2018-01-24T13:02:22.990Z
Answers.LastEditDate: 2018-01-24T13:02:22.990Z
Answers.UserDisplayName: Buffy
Answers.Body: <p>Sure, start with the infinite loop, then teach ending conditions later. That is kind of how people learn lots of things: eat, later worry about getting overweight. Maybe we should simply teach all the kinds of <em>bugs</em>, then get to how to actually think through a problem later. After all, doctors are taught about all the kinds of diseases. Health is just a byproduct, maybe, eventually. </p>
  
  <p>Structuring thought and approaching a problem are less important than the initial struggle to grasp the idea that some things in life repeat. It will come after a while. If they repeat the struggle enough. Wait...</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-29T14:38:55.877Z
Answers.Text: This doesn't really sure like an answer to the question (beyond the first sentence). Can you please add a more direct answer to the question as asked?
Answers.UserDisplayName: thesecretmaster
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-29T14:28:26.000Z
Answers.LastActivityDate: 2018-01-29T14:28:26.000Z
Answers.UserDisplayName: user4225
Answers.Body: <p>This is a really good place to introduce boolean variables (or just to use them, if they've already been introduced. It also introduces the idea of descriptive variable names.  </p>
  
  <pre><code>user_wishes_to_continue = True
  
  while user_wishes_to_continue:
      answer = raw_input("Do you wish to continue?")
      if answer != "yes":
          user_wishes_to_continue = False
  
  print ("Good bye")
  </code></pre>
  
  <p>Note: here I use <code>raw_input</code>, which returns the user input as a string, rather than <code>input</code>, which interprets the  user input as python code (meaning that you have to put <code>"yes"</code> <em>with the quotation marks</em> each time. </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-30T10:05:41.227Z
Answers.Text: nice answer. As I think that conditionals are over used, I would prefer this: `user_wishes_to_continue = (answer == "yes")`
Answers.UserDisplayName: ctrl-alt-delor
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-02-11T12:57:24.953Z
Answers.Text: `raw_input` vs `input` I don't get it. Was this true in python 2? I don't remember. In python3 I get `name 'raw_input' is not defined`.
Answers.UserDisplayName: ctrl-alt-delor
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-02-11T13:02:30.100Z
Answers.Text: It’s true for python 2; with regular old “input” it tries to interpret the input as a python expression
Answers.UserDisplayName: Alecto
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-29T22:35:29.347Z
Answers.LastActivityDate: 2018-01-29T22:35:29.347Z
Answers.UserDisplayName: Alecto
Answers.Body: <p>I think too much emphasis is placed on the "kind" of loop (e.g while vs. repeat until), and on how to structure a <code>while</code> loop if you need to pre fetch some values before you can consider exit condition(s).</p>
  
  <p>Instead, I tutor my students about the infinite loop construct.  And then about testing for exit condition(s), and advancing the loop (e.g. fetching), but that those two should occur in the order they naturally arise for the situation (and that we can have multiple exit conditions as needed).</p>
  
  <p>I feel that the while and repeat-until constructs are false source-code optimizations and code should not be considered better for their use over more general looping constructs.</p>
  
  <p>Using the infinite loop method tends to simplify mental task of writing a loop, since you can think about what to do inside the loop instead of how to write what you need in terms of one of the other more limited/specialized looping constructs before you even know what's needed.  We also don't have to think in terms of priming before/outside the loop (with code that is then repeated inside the loop).</p>
  
  <p>If it turns out that the exit test is at the beginning then it can be simply and mechanically transformed into a while loop, though I explain that they should not feel this transformation is necessary and might even have to be reversed/undone later (just like they should not feel it necessary to remove block <code>{}</code>s for single line then and else statements).</p>
  
  <p>If the language in question doesn't have an infinite loop construct I advocate <code>while True ...</code>, for the infinite loop, so students can get onto the business of writing the loop instead of thinking about how to structure a loop they haven't even yet written as a while loop.</p>
  
  <p>(The other loop construct I advocate is the counted/bounded for-loop, used when we know up front that some number of iterations are needed instead of a more general exit condition.)</p>
  
  <p>Thus, my answer would be a third option:</p>
  
  <pre><code>while True:
      answer=input("Do you wish to continue?")
      if answer != "yes"
          break;
  
  print ("Good bye")
  </code></pre>
  
  <p>Compared with the first, it is DRY, and compared with the second, you don't require the students to fake the loop condition to "yes" before running the loop.  (Yes, this could be transformed into a repeat-until, but I would say that is an uncessary transformation, though if done, could be done after writing the loop.)</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-29T00:45:53.037Z
Answers.Text: This kind of thinking doesn't scale. The whole purpose of using a meaningful boolean condition in a loop declaration is so that someone (who could well be yourself!) maintaining the code later can determine at a glance the approximate behavior and purpose of the loop. Writing loops this way forces you to later read every line of code to figure out even the most basic of behaviors; inner  `break` statements can be arbitrarily nested, and thus arbitrarily complex.
Answers.UserDisplayName: Ben I.
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-29T01:10:11.350Z
Answers.Text: @BenI.  I see student struggling to write loops, because they're thinking about too many things at once.  Scaling is and should be their last concern when first learning loops.  However, your point is taken, in that we should teach scaling, though perhaps not before the basic concepts of loops.
Answers.UserDisplayName: Erik Eidt
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-29T01:24:50.677Z
Answers.Text: Interesting point, and you may be right. I teach sophomores, so they have already written loops before they see me.  Perhaps this could be a viable approach at the start.
Answers.UserDisplayName: Ben I.
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-29T10:12:00.860Z
Answers.Text: While I don't like the resulting code. I do like the idea of starting with an infinite loop, and then transforming it, to have an exit condition. I have also had problems explaining `while True`.
Answers.UserDisplayName: ctrl-alt-delor
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-28T23:13:09.373Z
Answers.LastActivityDate: 2018-01-29T10:09:13.317Z
Answers.LastEditDate: 2018-01-29T10:09:13.317Z
Answers.UserDisplayName: Erik Eidt
Answers.Body: <p>Of the two alternatives listed, I prefer the second, because it <em>Says It Once</em>. (In this case, it's only a call to <code>input()</code> but it's easy to imagine a case where some computation needs to be done as part of the test).</p>
  
  <p>But there's yet another way to write it. If I were to describe verbally what I'm trying to do, I would say something like "Do some stuff (the body of the loop) at least once, and then keep doing it as long as the user wants to continue". And that can be expressed</p>
  
  <pre><code>first_time = True
  while first_time or answer == "yes":
      first_time = False
      answer=input("Do you wish to continue?")
  
  print ("Good bye")
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-29T20:59:34.523Z
Answers.LastActivityDate: 2018-01-29T20:59:34.523Z
Answers.UserDisplayName: AndyB
Body: <p>I keep seeing examples like the first program bellow, in teaching materials.</p>
  <p>Is there a pedagogical reason to teach this first program, compared to the second?</p>
  <pre><code>answer=input(&quot;Do you wish to continue?&quot;)
  
  while answer == &quot;yes&quot;:
      answer=input(&quot;Do you wish to continue?&quot;)
  
  print (&quot;Good bye&quot;)
  </code></pre>
  <p>2nd program</p>
  <pre><code>answer=&quot;yes&quot;
  
  while answer == &quot;yes&quot;:
      answer=input(&quot;Do you wish to continue?&quot;)
  
  print (&quot;Good bye&quot;)
  </code></pre>
  <hr />
  <h1>An argument for the 2nd one</h1>
  <p>I think the 2nd program is more elegant: it has less repeated code.</p>
  <p>note: when I wrote this I copied the 1st line into the other 2 places, then when I tested it I discovered that I missed the closing <code>&quot;</code>, so had to fix it 3 times. This is an example of why repeated code is a problem, when a program needs re-editing. In the second version, the only repeated code is <code>&quot;yes&quot;</code>, so still some room for improvement.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-01-27T15:45:18.610Z
Comments.Text: Im' not  Python programmer, but I'd expect an equivalent to a "do { answer=input("Do you wish to continue?") } while (answer == "yes")", or even "while (answer = input("....") == yes);"
Comments.UserDisplayName: pojo-guy
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-01-28T10:50:06.127Z
Comments.Text: @pojo-guy python does not have `do …while`, and combining assignment into a predicate has been shown to cause much confusion in professional programmers (I would expect the same for beginners).
Comments.UserDisplayName: ctrl-alt-delor
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-01-30T03:27:52.207Z
Comments.Text: Do you need `answer`?  `while input( "Do you wish to continue?" ) == "yes": ...`
Comments.UserDisplayName: user1692597
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-01-31T19:29:16.963Z
Comments.Text: The reason you teach the 1st before the 2nd is because it is the logical result of a flowchart. You loop if the answer is yes, so, you enter the loop if the answer is yes, then you continue till it is not yes. The 2nd example is an optimization of the 1st.
Comments.UserDisplayName: Gorchestopher H
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-01-31T19:38:20.600Z
Comments.Text: @GorchestopherH you have precisely said a reason why the 2nd is better. We are not in the 1960s any more. We now have structured programming, and don't use flow chart. What is more there is no reason that a flow chart can not model ether of these two programs.
Comments.UserDisplayName: ctrl-alt-delor
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-01-31T20:00:03.790Z
Comments.Text: @ctrl-alt-delor I may have slightly mis-read this, I thought you were asking for a reason to teach one *before* the other, not *instead*. Certainly the second is better, but since the second logically "follows" the first, I would say that the first is a good introduction to the second, regardless of the decade we are in. Also, the existence of structured programming doesn't mean flowcharts are obsolete, especially for teaching purposes...
Comments.UserDisplayName: Gorchestopher H
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-01-31T20:14:59.220Z
Comments.Text: @GorchestopherH you may want to contribute to this question on teaching flowcharts https://cseducators.stackexchange.com/q/3696/204  (I have been convinced that pseudo code is useful in teaching, but not flowcharts, except when teaching machine code, or human processes: how to tread a patent: check airway …)
Comments.UserDisplayName: ctrl-alt-delor
Tags: <looping><imperative-programming>
Title: Pedagogical reasoning behind a minor difference in two loops
ThreadText: # Pedagogical reasoning behind a minor difference in two loops
  
  (Asked by: username_0 on 2018-01-24)
  
  I keep seeing examples like the first program bellow, in teaching materials.
  
  Is there a pedagogical reason to teach this first program, compared to the second?
  
  ```
  answer=input("Do you wish to continue?")
  
  while answer == "yes":
      answer=input("Do you wish to continue?")
  
  print ("Good bye")
  
  ```
  
  2nd program
  
  ```
  answer="yes"
  
  while answer == "yes":
      answer=input("Do you wish to continue?")
  
  print ("Good bye")
  
  ```
  
  ---
  
  # An argument for the 2nd one
  
  I think the 2nd program is more elegant: it has less repeated code.
  
  note: when I wrote this I copied the 1st line into the other 2 places, then when I tested it I discovered that I missed the closing `"`, so had to fix it 3 times. This is an example of why repeated code is a problem, when a program needs re-editing. In the second version, the only repeated code is `"yes"`, so still some room for improvement.
  
  **Tags:** looping, imperative-programming
  
  > **Comments:**
  > **username_1**: Im' not  Python programmer, but I'd expect an equivalent to a "do { answer=input("Do you wish to continue?") } while (answer == "yes")", or even "while (answer = input("....") == yes);"  
  > **username_0**: @username_1 python does not have `do …while`, and combining assignment into a predicate has been shown to cause much confusion in professional programmers (I would expect the same for beginners).  
  > **username_2**: Do you need `answer`?  `while input( "Do you wish to continue?" ) == "yes": ...`  
  > **username_3**: The reason you teach the 1st before the 2nd is because it is the logical result of a flowchart. You loop if the answer is yes, so, you enter the loop if the answer is yes, then you continue till it is not yes. The 2nd example is an optimization of the 1st.  
  > **username_0**: @username_3 you have precisely said a reason why the 2nd is better. We are not in the 1960s any more. We now have structured programming, and don't use flow chart. What is more there is no reason that a flow chart can not model ether of these two programs.  
  > **username_3**: @username_0 I may have slightly mis-read this, I thought you were asking for a reason to teach one *before* the other, not *instead*. Certainly the second is better, but since the second logically "follows" the first, I would say that the first is a good introduction to the second, regardless of the decade we are in. Also, the existence of structured programming doesn't mean flowcharts are obsolete, especially for teaching purposes...  
  > **username_0**: @username_3 you may want to contribute to this question on teaching flowcharts https://cseducators.stackexchange.com/q/3696/204  (I have been convinced that pseudo code is useful in teaching, but not flowcharts, except when teaching machine code, or human processes: how to tread a patent: check airway …)  
  
  ---
  
  ## 7 answers
  
  ### Answer by username_10 on 2018-01-29. Score: 3
  
  This is a really good place to introduce boolean variables (or just to use them, if they've already been introduced. It also introduces the idea of descriptive variable names.
  
  ```
  user_wishes_to_continue = True
  
  while user_wishes_to_continue:
      answer = raw_input("Do you wish to continue?")
      if answer != "yes":
          user_wishes_to_continue = False
  
  print ("Good bye")
  
  ```
  
  Note: here I use `raw_input`, which returns the user input as a string, rather than `input`, which interprets the user input as python code (meaning that you have to put `"yes"` *with the quotation marks* each time.
  
  > **Comments:**
  > **username_0**: nice answer. As I think that conditionals are over used, I would prefer this: `user_wishes_to_continue = (answer == "yes")`  
  > **username_0**: `raw_input` vs `input` I don't get it. Was this true in python 2? I don't remember. In python3 I get `name 'raw_input' is not defined`.  
  > **username_10**: It’s true for python 2; with regular old “input” it tries to interpret the input as a python expression  
  
  ---
  
  ### Answer by username_11 on 2018-01-28. Score: 2
  
  I think too much emphasis is placed on the "kind" of loop (e.g while vs. repeat until), and on how to structure a `while` loop if you need to pre fetch some values before you can consider exit condition(s).
  
  Instead, I tutor my students about the infinite loop construct. And then about testing for exit condition(s), and advancing the loop (e.g. fetching), but that those two should occur in the order they naturally arise for the situation (and that we can have multiple exit conditions as needed).
  
  I feel that the while and repeat-until constructs are false source-code optimizations and code should not be considered better for their use over more general looping constructs.
  
  Using the infinite loop method tends to simplify mental task of writing a loop, since you can think about what to do inside the loop instead of how to write what you need in terms of one of the other more limited/specialized looping constructs before you even know what's needed. We also don't have to think in terms of priming before/outside the loop (with code that is then repeated inside the loop).
  
  If it turns out that the exit test is at the beginning then it can be simply and mechanically transformed into a while loop, though I explain that they should not feel this transformation is necessary and might even have to be reversed/undone later (just like they should not feel it necessary to remove block `{}`s for single line then and else statements).
  
  If the language in question doesn't have an infinite loop construct I advocate `while True ...`, for the infinite loop, so students can get onto the business of writing the loop instead of thinking about how to structure a loop they haven't even yet written as a while loop.
  
  (The other loop construct I advocate is the counted/bounded for-loop, used when we know up front that some number of iterations are needed instead of a more general exit condition.)
  
  Thus, my answer would be a third option:
  
  ```
  while True:
      answer=input("Do you wish to continue?")
      if answer != "yes"
          break;
  
  print ("Good bye")
  
  ```
  
  Compared with the first, it is DRY, and compared with the second, you don't require the students to fake the loop condition to "yes" before running the loop. (Yes, this could be transformed into a repeat-until, but I would say that is an uncessary transformation, though if done, could be done after writing the loop.)
  
  > **Comments:**
  > **username_6**: This kind of thinking doesn't scale. The whole purpose of using a meaningful boolean condition in a loop declaration is so that someone (who could well be yourself!) maintaining the code later can determine at a glance the approximate behavior and purpose of the loop. Writing loops this way forces you to later read every line of code to figure out even the most basic of behaviors; inner  `break` statements can be arbitrarily nested, and thus arbitrarily complex.  
  > **username_11**: @BenI.  I see student struggling to write loops, because they're thinking about too many things at once.  Scaling is and should be their last concern when first learning loops.  However, your point is taken, in that we should teach scaling, though perhaps not before the basic concepts of loops.  
  > **username_6**: Interesting point, and you may be right. I teach sophomores, so they have already written loops before they see me.  Perhaps this could be a viable approach at the start.  
  > **username_0**: While I don't like the resulting code. I do like the idea of starting with an infinite loop, and then transforming it, to have an exit condition. I have also had problems explaining `while True`.  
  
  ---
  
  ### Answer by username_12 on 2018-01-29. Score: 2
  
  Of the two alternatives listed, I prefer the second, because it *Says It Once*. (In this case, it's only a call to `input()` but it's easy to imagine a case where some computation needs to be done as part of the test).
  
  But there's yet another way to write it. If I were to describe verbally what I'm trying to do, I would say something like "Do some stuff (the body of the loop) at least once, and then keep doing it as long as the user wants to continue". And that can be expressed
  
  ```
  first_time = True
  while first_time or answer == "yes":
      first_time = False
      answer=input("Do you wish to continue?")
  
  print ("Good bye")
  
  ```
  
  
  ---
  
  ### Answer by username_4 on 2018-01-29. Score: 1
  
  Some programming and coding workflows\patterns make the repetition rather insignificant.
  
  For example, if one teaches to have constants set from the beginning, something like:
  
  ```
  init:
      questionText="Do you wish to continue?
      accept="good"
      finished="good bye"
  
  main code:
      answer=input(questionText)
      while answer=="yes":
          print(accept)
          answer=input(questionText)
  
      print(finished)
  
  ```
  
  and then if there was a mistake in the text, (as there is in my example), it's very easy to fix, without needing to copy-paste.
  
  As for elegance, I agree that the second option is a bit more elegant. However, it forces the code to enter the loop, and when teaching, it's far better to break an example into smaller parts, so as to allow students to understand each component separately, before they tackle the entire thing.
  
  
  ---
  
  ### Answer by username_5 on 2018-01-24. Score: 1
  
  There are different loop structures for very good reasons. In my early introductory programming examples, I stress at least three types of loops which are **not interchangeable**:  
  1. Loops that read data require a *priming read* before the test at the top.  
  2. Loops that test at the top can use a flag variable which is changed in the body.  
  3. Loops that test at the bottom must execute at least once.
  
  These must be explained clearly and with good explanations of why they are used in different circumstances, otherwise you will be condemning people to making many painful bugs which could be easily avoided.
  
  The other vital concept is that every loop (including recursive method calling, as in Functional programming) has three requirements:  
  1. The control variable must be *initialized* before the loop begins.  
  2. The control variable must be *updated* in the body of the loop.  
  3. The test that controls the loop must have an *achievable end condition*.
  
  Without those basics in place, students will flounder.
  
  > **Comments:**
  > **username_6**: Welcome to [cseducators.se].  This is a great first answer, and we're always glad to have CS educators join us here.  :)  It sounds like you'll have a lot to contribute.  Feel free to ping me if you need any help navigating around while you get started.  (Just add another comment to this answer and start typing `@b` and my name should pop up.)  
  
  ---
  
  ### Answer by username_7 on 2018-01-24. Score: 1
  
  I don't particularly care for either as a *first* program, but the second version makes the case for *Say It Once*, i.e. don't repeat code.
  
  However (a) it is awfully early to be stressing that rule and there are better examples that can come along soon, and (b) making the case for the rule requires showing (and discussing) **both** programs.
  
  Showing both can also help make the case (in a smallish way) that different programs have the same effect.
  
  On the other hand, I wouldn't rate one over the other based on just the fact that you mis-typed, but rather that programs change. Saying the same things twice doesn't hold up well if the prompt needs changing and you want it to be the same on the first and subsequent responses.
  
  However, you might want them to *not be* the same. That again requires some explanation and discussion.
  
  But that is a lot of weight for the *first program* to carry.
  
  ---
  
  For the mis-typing issue I'd rather use a UI that makes the syntax error visible before you progress any further making that moot.
  
  > **Comments:**
  > **username_0**: Not the firs program, but the first program is like one I have seen early in a course. The error I made is just an example of why you may need to re-edit.  
  > **username_0**: Could you add some advice as to how to introduce loops? (in python). I like to start with a `forever` loop in scratch. But python does not have them. [May be this is a new question]  
  > **username_7**: What you have is fine, but it is a lot for a first program. In python you can say while true:, of course. You can also write a function that just loops forever and call it. Since you write it, you can have it expect a lambda expression. (Caveat - I haven't worked out the details of this and tried to integrate it early, but I think it would work.) Python is pretty flexible.  
  
  ---
  
  ### Answer by username_8 on 2018-01-29. Score: -3
  
  Sure, start with the infinite loop, then teach ending conditions later. That is kind of how people learn lots of things: eat, later worry about getting overweight. Maybe we should simply teach all the kinds of *bugs*, then get to how to actually think through a problem later. After all, doctors are taught about all the kinds of diseases. Health is just a byproduct, maybe, eventually.
  
  Structuring thought and approaching a problem are less important than the initial struggle to grasp the idea that some things in life repeat. It will come after a while. If they repeat the struggle enough. Wait...
  
  > **Comments:**
  > **username_9**: This doesn't really sure like an answer to the question (beyond the first sentence). Can you please add a more direct answer to the question as asked?  
  
  ---
  
  