Answers.Body: <p>Here is my recipe.</p>
  <ol>
  <li>Begin with the language's type system.  If the language has a REPL, use it.</li>
  <li>Introduce variables.  Indicate if variables have type (statically-compiled languages) or if they are typeless names (a la Python).</li>
  <li>Introduce the idea of object (state/identity/behavior).  Objects are smart data and they can do work for you.  Have the students manipulate the fundamental types of objects in the REPL.  At this juncture, all programs are &quot;boring&quot; because they run their lines in seriatum</li>
  <li>It's time to divide the world into two types of statements, worker statements and boss statements.<br />
  Worker statements are imperative statements with the tacit subject &quot;computer.&quot;  Boss statements &quot;own&quot; chunks of code.  They are grammatically incomplete sentences.  They alter the flow of execution in a program.</li>
  <li>It's time for the first boss statement, the function.  Explain how computing functions differ from mathematical ones.  Make sure you do a careful explanation of mathematical functions and show examples (such as string length) of mathematical functions that occur often in computing.</li>
  <li>Time for three more boss statements:  if, elif/else if, and else.</li>
  <li>A little recursion please, before we break out loops.</li>
  <li>Iteration: indefinite (while) and definite(for) loops.  This opens the door to fileIO.</li>
  <li>Creating custom objects using classes and OO.</li>
  </ol>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-12-04T23:36:31.237Z
Answers.Text: This is quite an interesting and different ordering than I'm used to.  I assume that recursion (and functions in general) don't entirely "stick" yet, but must be revisited later.  Is this impression correct?  If so, this is an excellent ordering to begin a nice spiral through introductory programming.
Answers.UserDisplayName: Ben I.
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-12-07T01:06:28.407Z
Answers.Text: Functions come first.  They are a key way of avoiding "repeating yourself." Remembering a procedure under a name is key.
Answers.UserDisplayName: ncmathsadist
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-12-04T21:08:35.140Z
Answers.LastActivityDate: 2020-12-04T21:08:35.140Z
Answers.UserDisplayName: ncmathsadist
Answers.Body: <p>In touch of class — Bertrand Meyer, He start with the big stuff: object orientation, working programs. And then breaks it down toward the detail.
  So an top down approach, as opposed to the often seen bottom up. </p>
  
  <p>e.g. bounded loops (foreach) before unbounded loops (and how to implement bounded loops using unbounded once).</p>
  
  <p>Using objects before creating them.</p>
  
  <p>I can not see how to teach by starting with explaining each of the bricks, before teaching how to but the bricks together. I think it is better to explain what a house is, and then break it down, to explain how to make one, and as you do this explain the properties of the bricks.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-20T18:58:14.183Z
Answers.Text: To support "using objects before creating them" start with an already built framework that the students work within, so that the most "primitive" thing they see is an object with behavior and that can interact with others. You build this, or find one, and the students extend it. Karel J Robot is an example of this way of thinking. Unfortunately it overuses inheritance a bit so needs to be used with some care and thought.
Answers.UserDisplayName: Buffy
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-22T17:25:19.943Z
Answers.Text: To explain houses from bricks, I like using a historical approach.  Show them an abacus, human computers with mechanical adders, Baggage engine, core memory big enough to see each bit.  Throw in some stories about Ada, Turing, Shannon, and Hopper (the recent movie "Hidden Figures") to keep them interested.  Humans made lots of bricks way before learning to make beautiful cathedrals.  Teaching engineering and science is a bit different from teaching Art appreciation.
Answers.UserDisplayName: hotpaw2
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-20T18:24:35.783Z
Answers.LastActivityDate: 2017-07-20T18:24:35.783Z
Answers.UserDisplayName: ctrl-alt-delor
Answers.Body: <p>I feel like &quot;loops&quot;, &quot;variables&quot;, &quot;conditionals&quot;, etc is a pretty loose distinction. For example, even that technically eternal loop is just a an example of <code>while</code> loop, mentally it is a much much bigger thing, completely different. Or, another example, temporary variable is mentally different from initial or result variables.</p>
  <p>What makes it worse, &quot;conditionals&quot; are simple to define, but vastly increase possible ways to write a program. Like:</p>
  <ul>
  <li>without loops and conditionals you can write programs, though those look simple (slightly more interesting if events are already introduced)</li>
  <li>with loops (but without conditionals) you can write repetetive programs, a big class of programs. For example, you can now compute <span class="math-container">$\pi$</span></li>
  <li>with conditionals (but without loops) you can't write much sensible programs. Even if you write one, it doesn't look fun</li>
  <li>with both loops and conditionals program space EXPLODES, however, beginner can't see that this explosion is zillion times larger than what was before.</li>
  </ul>
  <p>FWIW, is to introduce &quot;incomplete&quot; concepts, kinda &quot;cliff-hangers&quot;. The eternal loop allows you to iterate things. Uh-oh, that you can't use to bound iterations, otherwise you could do X1, X2, X3, X4, .... (here students have to feel that &quot;uh-oh&quot;). Next lesson: Hang on, but we actually can do bounded iteration! (introduce for loop, students should recall which things they should be able to implement now).</p>
  <p>Cliffhanger stuff (know ahead stuff you have no way doing at this point of learning) is underestimated in education.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-12-04T17:29:01.553Z
Answers.LastActivityDate: 2020-12-04T17:29:01.553Z
Answers.UserDisplayName: danbst
Answers.Body: <p>I think this depends entirely on the programming language you use. Or maybe more accurately, you should choose a language that allows you to introduce the concepts in the order you want.</p>
  
  <p>I would use a language called <a href="https://processing.org/" rel="nofollow noreferrer">Processing</a>, which is built on top of Java and allows you to create visual, animated programs without any boilerplate code.</p>
  
  <p>I'd start with <strong>calling functions</strong>. Here's an entire Processing program:</p>
  
  <pre><code>ellipse(20, 30, 40, 50);
  </code></pre>
  
  <p>This program shows a window and draws a 40x50 oval at coordinates <code>20,30</code>. There are other functions in Processing. Have the students draw a basic scene.</p>
  
  <p>Then I'd talk about <strong>using variables</strong>. Processing has a few predefined variables that come in handy:</p>
  
  <pre><code>size(500, 500);
  ellipse(width/2, height/2, 200, 200);
  </code></pre>
  
  <p>This program creates a 500x500 window and shows a circle in the middle of it. Have the students modify their scenes so they stretch to fit the screen, using the <code>width</code> and <code>height</code> variables.</p>
  
  <p>Then I'd talk about <strong>creating variables</strong>. Have students create their own variables that allow them to move their scene around, or easily change the color, etc.</p>
  
  <p>Then comes <strong>creating functions</strong>. Here's an example program:</p>
  
  <pre><code>void setup(){
     size(500, 500);
  }
  
  void draw(){
     ellipse(mouseX, mouseY, 25, 25);
  }
  </code></pre>
  
  <p>This program shows a window that draws a circle wherever the mouse is, 60 times per second.</p>
  
  <p>Hopefully this gives you an idea of Processing and the general approach. From here I'd cover these topics:</p>
  
  <ul>
  <li>Debugging</li>
  <li>If Statements</li>
  <li>Animation</li>
  <li>For Loops</li>
  <li>Arrays</li>
  <li>User Input</li>
  <li>Using Objects</li>
  <li>Creating Classes</li>
  <li>ArrayLists</li>
  <li>Images</li>
  <li>Libraries</li>
  <li>Deploying your code</li>
  </ul>
  
  <p>Shameless self-promotion: I've put together a series of tutorials that cover all of these topics, available at <a href="http://HappyCoding.io" rel="nofollow noreferrer">HappyCoding.io</a>. I'd be happy to help adapt these tutorials into an introductory curriculum.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-20T18:39:15.933Z
Answers.Text: setup and draw are procedures not functions (though C and its derivative incorrectly call them functions).
Answers.UserDisplayName: ctrl-alt-delor
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-20T18:42:01.257Z
Answers.Text: @richard In an introductory course, the distinction does not matter. (I would go a step further and say the distinction doesn't matter in real life either, but I digress.) Processing calls these functions, so they're functions in Processing. In more advanced courses you can make a distinction between procedures and functions, but at an introductory level "functions tell the computer to do stuff" is about all you should be saying.
Answers.UserDisplayName: Kevin Workman
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-20T18:51:44.230Z
Answers.Text: The importance of the distinction between function and procedures is that if we make the distinction, then they have the same meaning as in real life: functions as in maths, procedures as in follow the correct procedure. The other importance is in which one we teach first.
Answers.UserDisplayName: ctrl-alt-delor
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-20T19:00:28.323Z
Answers.Text: @richard I guess I'll respectfully disagree with you here. At no point in my career have I needed to stop and remember whether I was writing a function or a procedure. So I wouldn't recommend spending any time making the distinction in an intro course, where students are already going to be inundated with new information. Maybe you just teach a different kind of course than I would. :p
Answers.UserDisplayName: Kevin Workman
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-20T19:53:51.560Z
Answers.Text: @nocomprende What is your comment replying to?
Answers.UserDisplayName: Kevin Workman
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-20T20:28:12.460Z
Answers.Text: @nocomprende You aren't being a bother, I just didn't understand whether you were replying to me or Richard.
Answers.UserDisplayName: Kevin Workman
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-22T00:15:02.033Z
Answers.Text: +1 to its depending on the programming language. The rest of your answer is good too. :-)
Answers.UserDisplayName: Ellen Spertus
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-25T08:35:49.633Z
Answers.Text: Depending on the programming language is 100% correct. Some languages make a distinction between functions and procedures, to varying degrees, others do not. @richard Using the mathematical concept of a function is misguided. It may or may not apply to the situation and can be harmful to student comprehension. Some languages even allow a given subroutine to be called with and without a return value in the same program. The importance of making a distinction between them in any course is dictated _only_ by the language used. The language handles the rest will determine the order of the topics.
Answers.UserDisplayName: Gypsy Spellweaver
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-07T18:23:22.713Z
Answers.Text: This year I'll try something similar with processing, but with a difference at the beginning : first settings/draw with some "actions" like ellipse (), rect (), fill ().... Then definition and execution of their own functions (void, without parameters).
Answers.UserDisplayName: Michel Billaud
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-07T18:39:40.030Z
Answers.Text: @MichelBillaud Note that you don't need to have `setup()` or `draw()` functions in a Processing sketch. You can have a "static" sketch that just calls functions directly. I'd recommend starting out with that, as it's even less overheard to learn.
Answers.UserDisplayName: Kevin Workman
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-07T19:36:52.677Z
Answers.Text: Yes, but my objective is to introduce problem decomposition as quickly as possible. Afaik, as soon as there are user defined functions, setup or draw is needed to call them.
Answers.UserDisplayName: Michel Billaud
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-07T20:35:50.153Z
Answers.Text: @MichelBillaud That last part is true. I just think you should spend some time on basic "here's how to call a function" before "here's how to write your own functions" (even if it's just setup and draw). But of course, it's up to you!
Answers.UserDisplayName: Kevin Workman
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-07T21:22:25.253Z
Answers.Text: @KevinWorkman in the first exercises they'll draw pictures with lots of function calls (ellipse etc). Then they'll learn to decompose the work into more manageable code units : void draw() {  draw_background ();  draw_forest ();  draw_farm (); ... } later use several calls to draw_tree (x,y) etc.
Answers.UserDisplayName: Michel Billaud
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-07T21:34:23.570Z
Answers.Text: @MichelBillaud Sounds good to me. I'm just saying for that first exercise, you don't need `draw()` or `setup()` at all.
Answers.UserDisplayName: Kevin Workman
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-20T18:25:45.250Z
Answers.LastActivityDate: 2017-07-24T22:28:41.650Z
Answers.LastEditDate: 2017-07-24T22:28:41.650Z
Answers.UserDisplayName: Kevin Workman
Answers.Body: <p>I'm self-taught, but here are my thoughts.</p>
  
  <p><strong>0. Language</strong></p>
  
  <p>I learned using a combination of Python (once I started to get more serious about programming, I actually don't remember how I stumbled across it) and JavaScript. Consequently, I have good indentation habits, and I haven't had to worry about problems you do have to worry about with some lower level languages. It also allows you to dabble in OOP but also not if you don't want to, which is also nice. Here's the general order of events for me, as best as I can remember it.</p>
  
  <p><strong>1. Motivation</strong></p>
  
  <p>Drawing shapes in JavaScript, printing things in Python, all stuck out to me as "whoa, cool" moments that made me want to keep going. I also saw cool projects that others had made on Khan Academy, where I started learning. It was exciting, and I wanted to be able to do all the stuff that the other users did.</p>
  
  <p><strong>2. Printing</strong></p>
  
  <p>This is almost step -1, but just thought I'd point it out here. This is also useful for the next thing.</p>
  
  <p><strong>3. Variables</strong></p>
  
  <p>Here, you can progress from</p>
  
  <pre><code>print("Hello, World!")
  </code></pre>
  
  <p>to </p>
  
  <pre><code>print_this = "Hello, World!"
  print(print_this)
  </code></pre>
  
  <p>I learned using the classic buckets analogy - when you define a variable, you put something in a bucket that's labelled whatever you name the variable. When you call the variable elsewhere, the computer looks for the name, and grabs whatever's inside the bucket.</p>
  
  <p><strong>4. <code>if</code> statements</strong></p>
  
  <p>This again builds off the previous concept - for example, you might do</p>
  
  <pre><code>print_this = "Hello, World!"
  do_i_print = True
  if do_i_print == True: #this can also be written as 'if do_i_print:'
      print(print_this)
  else:
      print("Nobody's home!")
  </code></pre>
  
  <p><em>Project 1</em></p>
  
  <p>All learning is more fun when it's motivated by something. With the information students have learned so far, they can now create a choose-your-own-adventure story with the introduction of one simple built-in in python - <code>input()</code>. For example, a very simple one might be:</p>
  
  <pre><code>first_choice = input("Your sister is missing when you wake up. Do you go to the kitchen to eat first, or go straight out to the barn to check if she's there? Input 'barn' or 'kitchen': ")
  if first_choice = 'barn':
      print("You found your sister!")
  elif first_choice = 'kitchen':
      print("Your mom scolds you for being a glutton and sends you to do your chores. Maybe you can find your sister later.")
  </code></pre>
  
  <p>You might also introduce basic input sanitization, and tell them this is what working programmers have to consider.</p>
  
  <p><strong>5. Numbers/math</strong></p>
  
  <p>Previously, you've used strings in the variables. Now, generalize to other types of variables - numbers, which can be whole or with decimals (integers and floats), lists, etc. Starting with numbers, you can then teach math operations (this'll become useful in a couple of steps). For example:</p>
  
  <pre><code>my_num = 5
  print(my_num**2)
  </code></pre>
  
  <p><strong>6. Functions</strong></p>
  
  <p>You can now generalize the previous step - </p>
  
  <pre><code>a = 5
  b = 2
  
  def multiply(a, b):
      return a*b
  
  multiply(a, b)
  </code></pre>
  
  <p><em>Project 2</em></p>
  
  <p>Now, a bigger project, and one they'll really enjoy (or at least, nerdy me did). If this is early highschool or middle school, they'll appreciate a program to solve quadratic equations for them. (I can provide my own, probably overly long solution if you want. Provide bonus points if they get their program to accommodate imaginary numbers. Hint: it has to do with the difference between the square root functions in <code>math</code> and <code>cmath</code>.)</p>
  
  <p><strong>7. More types - lists and dictionaries</strong></p>
  
  <p>Lists can be fun for later projects. Lists should probably be explained first, and then dictionaries.</p>
  
  <p><strong>8. <code>while</code> loops</strong></p>
  
  <p>Here, we can do something to all the elements in a list, which flows nicely into 9 and 10. </p>
  
  <pre><code>classmates = ['Bob', 'Jerry', 'Joe', 'Anna', 'Joan', 'Teresa']
  ages = []
  counter = 0
  while counter &lt; len(classmates):
      student = classmates[counter]
      print(student)
      age = input("What is the age of " + student + "?")
      ages.append(age)
      counter+=1
  </code></pre>
  
  <p>Rather a poor example, because that really should be a dictionary, but then you could I suppose do <code>dict(zip(classmates, ages))</code> - either way, it's a poor scheme. I'll try to replace it if I think up something better. Anyway.</p>
  
  <p><strong>9. <code>for</code> and <code>foreach</code> loops</strong></p>
  
  <p>Now, this gets shorter. For loops progress from while loops:</p>
  
  <pre><code>classmates = ['Bob', 'Jerry', 'Joe', 'Anna', 'Joan', 'Teresa']
  ages = []
  for(i = 0; i &lt; len(classmates); i++):
      student = classmates[i]
      print(student)
      age = input("What is the age of " + student + "?")
      ages.append(age)
  </code></pre>
  
  <p>Or, you could just do</p>
  
  <pre><code>classmates = ['Bob', 'Jerry', 'Joe', 'Anna', 'Joan', 'Teresa']
  ages = []
  for student in classmates:
       print(student)
       age = input("What is the age of " + student + "?")
       ages.append(age)
  </code></pre>
  
  <p><em>Project 3</em></p>
  
  <p>And now, another project! This one you can do something in the lines of <a href="https://www.codecademy.com/courses/python-beginner-en-qzsCL/0/1?curriculum_id=4f89dab3d788890003000096" rel="nofollow noreferrer">codecademy's python project</a> - using functions, dictionaries, lists, math, etc - to build a project.</p>
  
  <p><strong>10. OOP</strong></p>
  
  <p>I don't think I understand/have used OOP enough to suggest analogies/etc, but I do suggest introducing it last along with an accompanying project.</p>
  
  <p><em>Project 4</em></p>
  
  <p>OOP focused project.</p>
  
  <p><strong>11. Exploration</strong></p>
  
  <p>From here, perhaps let them explore. One kid might be excited for robotics, another, for the theoretical stuff, another, for scientific programming, another, game programming. Perhaps an ideal method: a unit on programming to control peripherals, using, say, the arduino, a unit on some theoretical stuff - logic gates, truth tables, and so forth, and a unit on specific programming applications - GUIs, game programming, scientific programming, websites - and allowing students to dabble in all of these.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-21T17:03:14.407Z
Answers.Text: Why `while` before `for`? A `for` loop (the Python-like version with `in`, not the C-like version) seems simpler to me: you know in advance how many iterations there are, and it can be introduced simply as a shortcut to write many similar lines. `While` loops usually rely on complex, mutating state.
Answers.UserDisplayName: Federico Poloni
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-21T18:57:20.720Z
Answers.Text: This is basically what I was taught in my first college course. For loops before while loops though. Python was a great learning tool, and we used turtles to draw for the "Whoa, cool" moment.
Answers.UserDisplayName: EvSunWoodard
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-21T20:22:34.970Z
Answers.Text: @FedericoPoloni I find `for` loops a condensed version of `while` loops - see for example [this answer](https://cseducators.stackexchange.com/a/2634/919) and the others to that question. The Python version of a while loop, the for each loop, is nice, but it's better to know what that syntax really means, and the for each is basically a condensed while loop.
Answers.UserDisplayName: auden
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-21T00:09:48.060Z
Answers.LastActivityDate: 2017-07-24T18:48:53.970Z
Answers.LastEditDate: 2017-07-24T18:48:53.970Z
Answers.UserDisplayName: auden
Answers.Body: <p>In <a href="https://mitpress.mit.edu/sicp/full-text/book/book.html" rel="nofollow noreferrer"><em>Structure and Interpretation of Computer Programs</em> (<em>SICP</em>)</a>  (a book, video series, and university course), they do not cover variable mutation until around half way. They covered what seemed like everything I know before this. Including functions (not procedures) and object orientation.</p>
  
  <p>My thought are that these partial sequences makes sense: </p>
  
  <p>statements → sequences → functions → parametrised functions → just about everything else → variable mutation</p>
  
  <p>infinite loops → bounded loops <code>for each</code> → unbounded loops <code>for(int i=0; i&lt;10; i++)</code> (while this is bounded, the construct is unbounded).</p>
  
  <p>non-mutating variables (possibly function parameters) → selection</p>
  
  <p>If these partial sequences are correct (work), then they need to be interleaved to make a sequence.</p>
  
  <p><em>SICP</em> may do it a bit different, so worth a look.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-20T18:05:23.127Z
Answers.Text: I think that in SICP they would much rather not have included explicit state (variables) at all, but then decided that Functional Programming wasn't the _entire_ world. Sadly. An somewhere, optimization of programs would, perhaps, need to be done. ;-)
Answers.UserDisplayName: Buffy
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-20T18:30:08.097Z
Answers.Text: @Buffy they had to do mutation, because without it a random-number function is a complete mess. A random number function is not a function, it has internal state (if you have mutation). With out mutation, you end up with a pure function, now the only place for the state is in the stack, this breaks modularity as now the user of the function is keeping the state and it is well ugly. In most other cases it is best to avoid mutation; It is more elegant without it. Secondly a functional language with lambdas, can just go and implement mutation, and banning lambdas would be a big mistake.
Answers.UserDisplayName: ctrl-alt-delor
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-20T18:35:17.690Z
Answers.Text: @nocomprende variables are not a problem, mutation is a problem (mostly see comment to buffy). If you avoid ever reusing a variable then your code will be more elegant, easier to read, easier to optimise, less buggy … The only place where this is impossible is in loop counters. This is why scheme uses recursion. However sometimes it is better to use mutation (but not much). Programs should be 80% to 90% functional, and mutation should be encapsulated.
Answers.UserDisplayName: ctrl-alt-delor
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-20T18:46:15.330Z
Answers.Text: @nocomprende I can't remember when they covered domain specific languages in SICP, probably before mutation. They use scheme (the language that they are teaching in), to define the language, all but the lexer. Then they wrote the lexer in scheme. All functional. — the real power of functional is that it will make you program better in other languages.
Answers.UserDisplayName: ctrl-alt-delor
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-20T18:48:36.293Z
Answers.Text: @richard, actually I would say that variables (explicit capture of state for later testing especially) **is** a problem. But this isn't the place for such a discussion. Why "remember" something for later action, if you can capture the action itself (either in an object (OOP) or an expression (Functional). Your background leads you to a different conclusion than mine, of course.
Answers.UserDisplayName: Buffy
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-20T17:56:16.090Z
Answers.LastActivityDate: 2017-07-20T21:49:58.303Z
Answers.LastEditDate: 2017-07-20T21:49:58.303Z
Answers.UserDisplayName: ctrl-alt-delor
Answers.Body: <p>I am of the school of thinking that starting at an abstract level causes too many students to consider computation as inscrutable magic.  And that can lead to broken mental models and buggy ideas about how to code stuff.</p>
  
  <p>A 1970's vintage UC Berkeley Intro to Computing course (for non-EECS majors) used a cardboard computer with pencil-and-eraser-mutable memory cells ( <a href="https://en.wikipedia.org/wiki/CARDboard_Illustrative_Aid_to_Computation" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/CARDboard_Illustrative_Aid_to_Computation</a> ). The professor also talked about physical adding machines (maybe Pascaline or abacus equivalents) before diving into coding in an HLL.  Programming became something that controlled a visualizable machine, not math that became transmuted by magic incantations.</p>
  
  <p>I would start there (at a very non-abstract level), and then show how modern HLL's make it so much easier to solve higher level problems.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-21T22:20:07.990Z
Answers.Text: The omission of this approach is why [Schlemiel the Painter](https://www.joelonsoftware.com/2001/12/11/back-to-basics/) is so common.  +1.
Answers.UserDisplayName: Wildcard
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-20T20:11:47.233Z
Answers.LastActivityDate: 2017-07-21T23:33:30.463Z
Answers.LastEditDate: 2017-07-21T23:33:30.463Z
Answers.UserDisplayName: hotpaw2
Answers.Body: <p>My answer, for the past 20 years is</p>
  
  <ul>
  <li>OOP - but primarily as enabling composition, not inheritance. The notion of a class as a "bundle of behavior". Inheritance via interfaces, not classes, or the equivalent when not in a statically typed language. </li>
  <li>reference variables (no primitive data)</li>
  <li>Some design patterns to reinforce good OOP thinking (Strategy especially)</li>
  <li>problem solving ......</li>
  <li>collections (list, set, ...) Not ALL collections, just enough. </li>
  <li>selection</li>
  <li>recursion if I can manage it. </li>
  <li>looping - while before for, but iterators before all.  </li>
  <li>recursion here if not earlier</li>
  <li>.....</li>
  <li>primitive data (int, char, ...)</li>
  <li>arrays</li>
  </ul>
  
  <p>The focus is on design and on building things, not mathematical puzzles. This needs a graphical system in which to work. Greenfoot is a good UI for this.</p>
  
  <p>Also. Classes should be simple and methods (very) short and very simple. At statement number 5 in a method I start to itch. Put the complexity into the interactions between objects, not in the methods of the class. This may be the most transformational message of all, here.  Another way to think of it is to capture "state" in the program counter, not in fields and variables - the "state of the computation", not in explicitly "remembered" values. </p>
  
  <p>Note that this "mind set" is radically different from that of a C or even (the typical) C++ programmer. It is as radical as the mindset of a functional programmer. </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-20T18:44:30.767Z
Answers.Text: Yes, I understand and agree. But we would likely still disagree.
Answers.UserDisplayName: Buffy
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-20T18:56:24.463Z
Answers.Text: @nocomprende top down or bottom up: what we are trying to do first, or how it is done first: human first or machine first.
Answers.UserDisplayName: ctrl-alt-delor
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-20T21:27:19.977Z
Answers.Text: @nocomprende I hardly use the memory register of my calculator. You don't need it if the calculator does BODMAS, or is stack based (reverse polish). I guess to understand functional, you have to understand functional. But I agree that starting at both ends seems like the way to go.
Answers.UserDisplayName: ctrl-alt-delor
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-21T05:40:22.563Z
Answers.Text: @Richard You are missing the point. *The number that is shown on the calculator display is stored in a variable.* And if you insist that calculators should have a reverse polish interface because that satisfies your prejudices about the one and only way to design software properly, IMO your whole philosophy is bass ackwards so far as real world computer system design is concerned.
Answers.UserDisplayName: alephzero
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-21T10:08:57.153Z
Answers.Text: @alephzero no I have the point, I know where you are coming from, I just don't think it is the **best** place. And reverse polish is just one option, the other as stated is BODMAS. If you have ether of these, then you need no explicit registers. However you may reuse an answer from the display, not because you have to, but because it is easier. Usually to avoid typing the formula in again. But if you can recall the formula, it is usually easier, in the long run, to fix the formula (that way there is no implicit program, than making it easier to fix, and reason with).
Answers.UserDisplayName: ctrl-alt-delor
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-21T23:09:37.567Z
Answers.Text: @Richard : If a calculator seems to do either RPN or BODMAS, it is just an illusion.  There are registers connected to an ALU actually doing the real grunt work.  Kids have built simple calculators out of Lego's.  That's a real (and realizable) foundation.
Answers.UserDisplayName: hotpaw2
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-21T23:19:48.370Z
Answers.Text: @hotpaw2 see my first comment to this answer, What or how: the how is probably as you say ( and I mean probably). But the what is as I say. The user only cares about the interface. They do not think about it in terms of this particular implementation.
Answers.UserDisplayName: ctrl-alt-delor
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-21T23:31:30.170Z
Answers.Text: Is the goal of Intro to CS to create users of interfaces?  Or start kids on the path to becoming competent computer scientists, programmers, and software engineers who really understand how to make stuff that works?
Answers.UserDisplayName: hotpaw2
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-22T00:07:04.083Z
Answers.Text: @hotpaw2, Are those inconsistent goals? Or is one just a part of the other. Of course, I think students should be writing interfaces and extending them as part of a larger goal.
Answers.UserDisplayName: Buffy
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-22T21:15:33.570Z
Answers.Text: (1) why - I don't believe that students need to recapitulate the history of computing to learn how to program. A modern language provides a complete, consistent, model in which to think and program without needing to map to lower level abstractions. The mapping is, in fact, extra work.
Answers.UserDisplayName: Buffy
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-22T21:18:54.967Z
Answers.Text: (2) how - I don't start with a bare machine and a sort of "math-y" problem. I start with a simulation of some type that already has objects in it (I use Java, mostly) that can be (a) composed and (b) extended. Look at http://greenfoot.org or better http://greenroom.greenfoot.org for many examples that you can utilize and adapt. It is also a good beginner user environment that shows both program structure and graphic simulations. Start high. Move higher. When they get some experience with the "complete consistent language environment" then (only then) show the map to the netherworld of bits.
Answers.UserDisplayName: Buffy
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-07-20T17:55:26.790Z
Answers.LastActivityDate: 2017-07-20T17:55:26.790Z
Answers.UserDisplayName: Buffy
Body: <p>This is a question for those of you who have an intro class before AP Computer Science (or maybe even just an intro class). What order do you teach the topics in your intro class? I start with if statements, then go in the following order:</p>
  
  <ul>
  <li>While Loops</li>
  <li>Variables (I do some hand-waving with variables before this point)</li>
  <li>For Loops</li>
  <li>Arrays</li>
  <li>OOP</li>
  </ul>
  
  <p>I used to start with variables a few years ago, but students seemed to have trouble getting the concept that early in the course. I'm not sure if I should go back to that now that I have more teaching experience and have a better idea of how to teach variables.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-07-20T17:43:36.450Z
Comments.Text: What about functions and procedures.
Comments.UserDisplayName: ctrl-alt-delor
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-07-20T17:57:54.693Z
Comments.Text: You also need to consider separately mutating variables, and non-mutating variables. The later should be taught first.
Comments.UserDisplayName: ctrl-alt-delor
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-07-20T17:58:45.477Z
Comments.Text: Also consider using Objects as easier (to be done before) creating objects.
Comments.UserDisplayName: ctrl-alt-delor
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-07-20T19:51:04.130Z
Comments.Text: @richard : In real computer hardware, functions, and non-mutating variables as computation results don't exist.  The program counter jumps, and state bits mutate.  Why jump to an abstraction so early?
Comments.UserDisplayName: hotpaw2
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-07-20T21:31:42.950Z
Comments.Text: @hotpaw2 that is just one way to make the hardware. **As for why: mutation is one of the hardest concepts to grasp.** And even after you get/grok it there are a lot of mistakes to be made, even by experienced experts.
Comments.UserDisplayName: ctrl-alt-delor
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-07-20T21:51:20.170Z
Comments.Text: Regardless of the other answers, I want to highlight *refactoring* (including the IDE's refactoring tools) and *source organization* (packages/namespaces) as two things to at least touch on early. I didn't get either throughout my entire acedemic career and had to discover it later on...After ***five years working professionally.***
Comments.UserDisplayName: Draco18s no longer trusts SE
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-07-20T22:35:53.697Z
Comments.Text: Related: [When to introduce OOP in teaching programming](https://cseducators.stackexchange.com/q/666/660)
Comments.UserDisplayName: Bergi
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-07-21T14:52:08.300Z
Comments.Text: It is language dependent.  When teaching my daughter JavaScript on a webpage, events and functions have to happen very early, and using objects soon thereafter, but making your own objects is in the advanced class (after closures).
Comments.UserDisplayName: Guy Schalnat
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-07-22T04:17:27.513Z
Comments.Text: I thought it was interesting that the CodeHS curriculum for AP CS A started with Karel language, commanding a dog character to navigate various obstacles. There's a trend in K-12 CS education to develop computational thinking skills, independent of programming languages. Computational thinking skill can be developed without the use of computers. On that note, http://csunplugged.org/ is a great supplemental resource that can add some variety to class and make it more interesting for everyone.
Comments.UserDisplayName: ThisClark
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-07-24T18:39:23.673Z
Comments.Text: Related: [The order of subjects in beginner's curriculum](https://cseducators.stackexchange.com/questions/2903/the-order-of-subjects-in-beginners-curriculum)
Comments.UserDisplayName: TuringTux
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-07-25T08:50:32.860Z
Comments.Text: @richard Other than the _real computer hardware_ referenced by hotpaw2, how else have you seen _real computer hardware_ made?
Comments.UserDisplayName: Gypsy Spellweaver
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-07-25T09:19:52.487Z
Comments.Text: @GypsySpellweaver as well as Von-Neumann/Harvard Architecture (where Harvard is just a type of Von Neumann) there are many others. The ALU is a functional component, however it is wrapped in mutation `add r0, r1 →r3`. There are stack based, where there is no data addresses, all data is on a stack `add` this takes to values from stack, adds them, and puts result onto stack. (This is a pure functional language implemented in hardware). I know there is a forth cpu out there. However ever if no one has made one, it would not disprove that there are not alternatives.
Comments.UserDisplayName: ctrl-alt-delor
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-07-25T09:29:31.133Z
Comments.Text: @GypsySpellweaver Single instruction machines have no program counter, so no instruction addresses, and possibly no data addresses. One of my peers an university made a massively parallel single instruction computer. It used a counter as data input (Von Neumann uses a counted for Program counter input). On each clock tick it would test the input. If test succeeded, then the input data was captured into a small ram. Apart from this result capture, the rest was functional. It ran at only 0.1Mz because of complex instruction. It ran over night & did what fastest supercomputer would take 20 years.
Comments.UserDisplayName: ctrl-alt-delor
Tags: <curriculum-design><variables>
Title: Order to Teach Topics in an Intro Programming Class
ThreadText: # Order to Teach Topics in an Intro Programming Class
  
  (Asked by: username_0 on 2017-07-20)
  
  This is a question for those of you who have an intro class before AP Computer Science (or maybe even just an intro class). What order do you teach the topics in your intro class? I start with if statements, then go in the following order:
  
  * While Loops
  * Variables (I do some hand-waving with variables before this point)
  * For Loops
  * Arrays
  * OOP
  
  I used to start with variables a few years ago, but students seemed to have trouble getting the concept that early in the course. I'm not sure if I should go back to that now that I have more teaching experience and have a better idea of how to teach variables.
  
  **Tags:** curriculum-design, variables
  
  > **Comments:**
  > **username_1**: What about functions and procedures.  
  > **username_1**: You also need to consider separately mutating variables, and non-mutating variables. The later should be taught first.  
  > **username_1**: Also consider using Objects as easier (to be done before) creating objects.  
  > **username_2**: @richard : In real computer hardware, functions, and non-mutating variables as computation results don't exist.  The program counter jumps, and state bits mutate.  Why jump to an abstraction so early?  
  > **username_1**: @username_2 that is just one way to make the hardware. **As for why: mutation is one of the hardest concepts to grasp.** And even after you get/grok it there are a lot of mistakes to be made, even by experienced experts.  
  > **username_3**: Regardless of the other answers, I want to highlight *refactoring* (including the IDE's refactoring tools) and *source organization* (packages/namespaces) as two things to at least touch on early. I didn't get either throughout my entire acedemic career and had to discover it later on...After ***five years working professionally.***  
  > **username_4**: Related: [When to introduce OOP in teaching programming](https://cseducators.stackexchange.com/q/666/660)  
  > **username_5**: It is language dependent.  When teaching my daughter JavaScript on a webpage, events and functions have to happen very early, and using objects soon thereafter, but making your own objects is in the advanced class (after closures).  
  > **username_6**: I thought it was interesting that the CodeHS curriculum for AP CS A started with Karel language, commanding a dog character to navigate various obstacles. There's a trend in K-12 CS education to develop computational thinking skills, independent of programming languages. Computational thinking skill can be developed without the use of computers. On that note, http://csunplugged.org/ is a great supplemental resource that can add some variety to class and make it more interesting for everyone.  
  > **username_7**: Related: [The order of subjects in beginner's curriculum](https://cseducators.stackexchange.com/questions/2903/the-order-of-subjects-in-beginners-curriculum)  
  > **username_8**: @richard Other than the _real computer hardware_ referenced by username_2, how else have you seen _real computer hardware_ made?  
  > **username_1**: @username_8 as well as Von-Neumann/Harvard Architecture (where Harvard is just a type of Von Neumann) there are many others. The ALU is a functional component, however it is wrapped in mutation `add r0, r1 →r3`. There are stack based, where there is no data addresses, all data is on a stack `add` this takes to values from stack, adds them, and puts result onto stack. (This is a pure functional language implemented in hardware). I know there is a forth cpu out there. However ever if no one has made one, it would not disprove that there are not alternatives.  
  > **username_1**: @username_8 Single instruction machines have no program counter, so no instruction addresses, and possibly no data addresses. One of my peers an university made a massively parallel single instruction computer. It used a counter as data input (Von Neumann uses a counted for Program counter input). On each clock tick it would test the input. If test succeeded, then the input data was captured into a small ram. Apart from this result capture, the rest was functional. It ran at only 0.1Mz because of complex instruction. It ran over night & did what fastest supercomputer would take 20 years.  
  
  ---
  
  ## 8 answers
  
  ### Answer by username_13 on 2017-07-20. Score: 11 | Accepted answer
  
  I think this depends entirely on the programming language you use. Or maybe more accurately, you should choose a language that allows you to introduce the concepts in the order you want.
  
  I would use a language called [Processing](https://processing.org/), which is built on top of Java and allows you to create visual, animated programs without any boilerplate code.
  
  I'd start with **calling functions**. Here's an entire Processing program:
  
  ```
  ellipse(20, 30, 40, 50);
  
  ```
  
  This program shows a window and draws a 40x50 oval at coordinates `20,30`. There are other functions in Processing. Have the students draw a basic scene.
  
  Then I'd talk about **using variables**. Processing has a few predefined variables that come in handy:
  
  ```
  size(500, 500);
  ellipse(width/2, height/2, 200, 200);
  
  ```
  
  This program creates a 500x500 window and shows a circle in the middle of it. Have the students modify their scenes so they stretch to fit the screen, using the `width` and `height` variables.
  
  Then I'd talk about **creating variables**. Have students create their own variables that allow them to move their scene around, or easily change the color, etc.
  
  Then comes **creating functions**. Here's an example program:
  
  ```
  void setup(){
     size(500, 500);
  }
  
  void draw(){
     ellipse(mouseX, mouseY, 25, 25);
  }
  
  ```
  
  This program shows a window that draws a circle wherever the mouse is, 60 times per second.
  
  Hopefully this gives you an idea of Processing and the general approach. From here I'd cover these topics:
  
  * Debugging
  * If Statements
  * Animation
  * For Loops
  * Arrays
  * User Input
  * Using Objects
  * Creating Classes
  * ArrayLists
  * Images
  * Libraries
  * Deploying your code
  
  Shameless self-promotion: I've put together a series of tutorials that cover all of these topics, available at [HappyCoding.io](http://HappyCoding.io). I'd be happy to help adapt these tutorials into an introductory curriculum.
  
  > **Comments:**
  > **username_1**: setup and draw are procedures not functions (though C and its derivative incorrectly call them functions).  
  > **username_13**: @richard In an introductory course, the distinction does not matter. (I would go a step further and say the distinction doesn't matter in real life either, but I digress.) Processing calls these functions, so they're functions in Processing. In more advanced courses you can make a distinction between procedures and functions, but at an introductory level "functions tell the computer to do stuff" is about all you should be saying.  
  > **username_1**: The importance of the distinction between function and procedures is that if we make the distinction, then they have the same meaning as in real life: functions as in maths, procedures as in follow the correct procedure. The other importance is in which one we teach first.  
  > **username_13**: @richard I guess I'll respectfully disagree with you here. At no point in my career have I needed to stop and remember whether I was writing a function or a procedure. So I wouldn't recommend spending any time making the distinction in an intro course, where students are already going to be inundated with new information. Maybe you just teach a different kind of course than I would. :p  
  > **username_13**: @nocomprende What is your comment replying to?  
  > **username_13**: @nocomprende You aren't being a bother, I just didn't understand whether you were replying to me or Richard.  
  > **username_14**: +1 to its depending on the programming language. The rest of your answer is good too. :-)  
  > **username_8**: Depending on the programming language is 100% correct. Some languages make a distinction between functions and procedures, to varying degrees, others do not. @richard Using the mathematical concept of a function is misguided. It may or may not apply to the situation and can be harmful to student comprehension. Some languages even allow a given subroutine to be called with and without a return value in the same program. The importance of making a distinction between them in any course is dictated _only_ by the language used. The language handles the rest will determine the order of the topics.  
  > **username_15**: This year I'll try something similar with processing, but with a difference at the beginning : first settings/draw with some "actions" like ellipse (), rect (), fill ().... Then definition and execution of their own functions (void, without parameters).  
  > **username_13**: @username_15 Note that you don't need to have `setup()` or `draw()` functions in a Processing sketch. You can have a "static" sketch that just calls functions directly. I'd recommend starting out with that, as it's even less overheard to learn.  
  > **username_15**: Yes, but my objective is to introduce problem decomposition as quickly as possible. Afaik, as soon as there are user defined functions, setup or draw is needed to call them.  
  > **username_13**: @username_15 That last part is true. I just think you should spend some time on basic "here's how to call a function" before "here's how to write your own functions" (even if it's just setup and draw). But of course, it's up to you!  
  > **username_15**: @username_13 in the first exercises they'll draw pictures with lots of function calls (ellipse etc). Then they'll learn to decompose the work into more manageable code units : void draw() {  draw_background ();  draw_forest ();  draw_farm (); ... } later use several calls to draw_tree (x,y) etc.  
  > **username_13**: @username_15 Sounds good to me. I'm just saying for that first exercise, you don't need `draw()` or `setup()` at all.  
  
  ---
  
  ### Answer by username_16 on 2017-07-21. Score: 10
  
  I'm self-taught, but here are my thoughts.
  
  **0. Language**
  
  I learned using a combination of Python (once I started to get more serious about programming, I actually don't remember how I stumbled across it) and JavaScript. Consequently, I have good indentation habits, and I haven't had to worry about problems you do have to worry about with some lower level languages. It also allows you to dabble in OOP but also not if you don't want to, which is also nice. Here's the general order of events for me, as best as I can remember it.
  
  **1. Motivation**
  
  Drawing shapes in JavaScript, printing things in Python, all stuck out to me as "whoa, cool" moments that made me want to keep going. I also saw cool projects that others had made on Khan Academy, where I started learning. It was exciting, and I wanted to be able to do all the stuff that the other users did.
  
  **2. Printing**
  
  This is almost step -1, but just thought I'd point it out here. This is also useful for the next thing.
  
  **3. Variables**
  
  Here, you can progress from
  
  ```
  print("Hello, World!")
  
  ```
  
  to
  
  ```
  print_this = "Hello, World!"
  print(print_this)
  
  ```
  
  I learned using the classic buckets analogy - when you define a variable, you put something in a bucket that's labelled whatever you name the variable. When you call the variable elsewhere, the computer looks for the name, and grabs whatever's inside the bucket.
  
  **4. `if` statements**
  
  This again builds off the previous concept - for example, you might do
  
  ```
  print_this = "Hello, World!"
  do_i_print = True
  if do_i_print == True: #this can also be written as 'if do_i_print:'
      print(print_this)
  else:
      print("Nobody's home!")
  
  ```
  
  *Project 1*
  
  All learning is more fun when it's motivated by something. With the information students have learned so far, they can now create a choose-your-own-adventure story with the introduction of one simple built-in in python - `input()`. For example, a very simple one might be:
  
  ```
  first_choice = input("Your sister is missing when you wake up. Do you go to the kitchen to eat first, or go straight out to the barn to check if she's there? Input 'barn' or 'kitchen': ")
  if first_choice = 'barn':
      print("You found your sister!")
  elif first_choice = 'kitchen':
      print("Your mom scolds you for being a glutton and sends you to do your chores. Maybe you can find your sister later.")
  
  ```
  
  You might also introduce basic input sanitization, and tell them this is what working programmers have to consider.
  
  **5. Numbers/math**
  
  Previously, you've used strings in the variables. Now, generalize to other types of variables - numbers, which can be whole or with decimals (integers and floats), lists, etc. Starting with numbers, you can then teach math operations (this'll become useful in a couple of steps). For example:
  
  ```
  my_num = 5
  print(my_num**2)
  
  ```
  
  **6. Functions**
  
  You can now generalize the previous step -
  
  ```
  a = 5
  b = 2
  
  def multiply(a, b):
      return a*b
  
  multiply(a, b)
  
  ```
  
  *Project 2*
  
  Now, a bigger project, and one they'll really enjoy (or at least, nerdy me did). If this is early highschool or middle school, they'll appreciate a program to solve quadratic equations for them. (I can provide my own, probably overly long solution if you want. Provide bonus points if they get their program to accommodate imaginary numbers. Hint: it has to do with the difference between the square root functions in `math` and `cmath`.)
  
  **7. More types - lists and dictionaries**
  
  Lists can be fun for later projects. Lists should probably be explained first, and then dictionaries.
  
  **8. `while` loops**
  
  Here, we can do something to all the elements in a list, which flows nicely into 9 and 10.
  
  ```
  classmates = ['Bob', 'Jerry', 'Joe', 'Anna', 'Joan', 'Teresa']
  ages = []
  counter = 0
  while counter < len(classmates):
      student = classmates[counter]
      print(student)
      age = input("What is the age of " + student + "?")
      ages.append(age)
      counter+=1
  
  ```
  
  Rather a poor example, because that really should be a dictionary, but then you could I suppose do `dict(zip(classmates, ages))` - either way, it's a poor scheme. I'll try to replace it if I think up something better. Anyway.
  
  **9. `for` and `foreach` loops**
  
  Now, this gets shorter. For loops progress from while loops:
  
  ```
  classmates = ['Bob', 'Jerry', 'Joe', 'Anna', 'Joan', 'Teresa']
  ages = []
  for(i = 0; i < len(classmates); i++):
      student = classmates[i]
      print(student)
      age = input("What is the age of " + student + "?")
      ages.append(age)
  
  ```
  
  Or, you could just do
  
  ```
  classmates = ['Bob', 'Jerry', 'Joe', 'Anna', 'Joan', 'Teresa']
  ages = []
  for student in classmates:
       print(student)
       age = input("What is the age of " + student + "?")
       ages.append(age)
  
  ```
  
  *Project 3*
  
  And now, another project! This one you can do something in the lines of [codecademy's python project](https://www.codecademy.com/courses/python-beginner-en-qzsCL/0/1?curriculum_id=4f89dab3d788890003000096) - using functions, dictionaries, lists, math, etc - to build a project.
  
  **10. OOP**
  
  I don't think I understand/have used OOP enough to suggest analogies/etc, but I do suggest introducing it last along with an accompanying project.
  
  *Project 4*
  
  OOP focused project.
  
  **11. Exploration**
  
  From here, perhaps let them explore. One kid might be excited for robotics, another, for the theoretical stuff, another, for scientific programming, another, game programming. Perhaps an ideal method: a unit on programming to control peripherals, using, say, the arduino, a unit on some theoretical stuff - logic gates, truth tables, and so forth, and a unit on specific programming applications - GUIs, game programming, scientific programming, websites - and allowing students to dabble in all of these.
  
  > **Comments:**
  > **username_17**: Why `while` before `for`? A `for` loop (the Python-like version with `in`, not the C-like version) seems simpler to me: you know in advance how many iterations there are, and it can be introduced simply as a shortcut to write many similar lines. `While` loops usually rely on complex, mutating state.  
  > **username_18**: This is basically what I was taught in my first college course. For loops before while loops though. Python was a great learning tool, and we used turtles to draw for the "Whoa, cool" moment.  
  > **username_16**: @username_17 I find `for` loops a condensed version of `while` loops - see for example [this answer](https://cseducators.stackexchange.com/a/2634/919) and the others to that question. The Python version of a while loop, the for each loop, is nice, but it's better to know what that syntax really means, and the for each is basically a condensed while loop.  
  
  ---
  
  ### Answer by username_1 on 2017-07-20. Score: 6
  
  In [*Structure and Interpretation of Computer Programs* (*SICP*)](https://mitpress.mit.edu/sicp/full-text/book/book.html) (a book, video series, and university course), they do not cover variable mutation until around half way. They covered what seemed like everything I know before this. Including functions (not procedures) and object orientation.
  
  My thought are that these partial sequences makes sense:
  
  statements → sequences → functions → parametrised functions → just about everything else → variable mutation
  
  infinite loops → bounded loops `for each` → unbounded loops `for(int i=0; i<10; i++)` (while this is bounded, the construct is unbounded).
  
  non-mutating variables (possibly function parameters) → selection
  
  If these partial sequences are correct (work), then they need to be interleaved to make a sequence.
  
  *SICP* may do it a bit different, so worth a look.
  
  > **Comments:**
  > **username_11**: I think that in SICP they would much rather not have included explicit state (variables) at all, but then decided that Functional Programming wasn't the _entire_ world. Sadly. An somewhere, optimization of programs would, perhaps, need to be done. ;-)  
  > **username_1**: @username_11 they had to do mutation, because without it a random-number function is a complete mess. A random number function is not a function, it has internal state (if you have mutation). With out mutation, you end up with a pure function, now the only place for the state is in the stack, this breaks modularity as now the user of the function is keeping the state and it is well ugly. In most other cases it is best to avoid mutation; It is more elegant without it. Secondly a functional language with lambdas, can just go and implement mutation, and banning lambdas would be a big mistake.  
  > **username_1**: @nocomprende variables are not a problem, mutation is a problem (mostly see comment to username_11). If you avoid ever reusing a variable then your code will be more elegant, easier to read, easier to optimise, less buggy … The only place where this is impossible is in loop counters. This is why scheme uses recursion. However sometimes it is better to use mutation (but not much). Programs should be 80% to 90% functional, and mutation should be encapsulated.  
  > **username_1**: @nocomprende I can't remember when they covered domain specific languages in SICP, probably before mutation. They use scheme (the language that they are teaching in), to define the language, all but the lexer. Then they wrote the lexer in scheme. All functional. — the real power of functional is that it will make you program better in other languages.  
  > **username_11**: @richard, actually I would say that variables (explicit capture of state for later testing especially) **is** a problem. But this isn't the place for such a discussion. Why "remember" something for later action, if you can capture the action itself (either in an object (OOP) or an expression (Functional). Your background leads you to a different conclusion than mine, of course.  
  
  ---
  
  ### Answer by username_2 on 2017-07-20. Score: 4
  
  I am of the school of thinking that starting at an abstract level causes too many students to consider computation as inscrutable magic. And that can lead to broken mental models and buggy ideas about how to code stuff.
  
  A 1970's vintage UC Berkeley Intro to Computing course (for non-EECS majors) used a cardboard computer with pencil-and-eraser-mutable memory cells ( <https://en.wikipedia.org/wiki/CARDboard_Illustrative_Aid_to_Computation> ). The professor also talked about physical adding machines (maybe Pascaline or abacus equivalents) before diving into coding in an HLL. Programming became something that controlled a visualizable machine, not math that became transmuted by magic incantations.
  
  I would start there (at a very non-abstract level), and then show how modern HLL's make it so much easier to solve higher level problems.
  
  > **Comments:**
  > **username_19**: The omission of this approach is why [Schlemiel the Painter](https://www.joelonsoftware.com/2001/12/11/back-to-basics/) is so common.  +1.  
  
  ---
  
  ### Answer by username_11 on 2017-07-20. Score: 3
  
  My answer, for the past 20 years is
  
  * OOP - but primarily as enabling composition, not inheritance. The notion of a class as a "bundle of behavior". Inheritance via interfaces, not classes, or the equivalent when not in a statically typed language.
  * reference variables (no primitive data)
  * Some design patterns to reinforce good OOP thinking (Strategy especially)
  * problem solving ......
  * collections (list, set, ...) Not ALL collections, just enough.
  * selection
  * recursion if I can manage it.
  * looping - while before for, but iterators before all.
  * recursion here if not earlier
  * .....
  * primitive data (int, char, ...)
  * arrays
  
  The focus is on design and on building things, not mathematical puzzles. This needs a graphical system in which to work. Greenfoot is a good UI for this.
  
  Also. Classes should be simple and methods (very) short and very simple. At statement number 5 in a method I start to itch. Put the complexity into the interactions between objects, not in the methods of the class. This may be the most transformational message of all, here. Another way to think of it is to capture "state" in the program counter, not in fields and variables - the "state of the computation", not in explicitly "remembered" values.
  
  Note that this "mind set" is radically different from that of a C or even (the typical) C++ programmer. It is as radical as the mindset of a functional programmer.
  
  > **Comments:**
  > **username_11**: Yes, I understand and agree. But we would likely still disagree.  
  > **username_1**: @nocomprende top down or bottom up: what we are trying to do first, or how it is done first: human first or machine first.  
  > **username_1**: @nocomprende I hardly use the memory register of my calculator. You don't need it if the calculator does BODMAS, or is stack based (reverse polish). I guess to understand functional, you have to understand functional. But I agree that starting at both ends seems like the way to go.  
  > **username_20**: @Richard You are missing the point. *The number that is shown on the calculator display is stored in a variable.* And if you insist that calculators should have a reverse polish interface because that satisfies your prejudices about the one and only way to design software properly, IMO your whole philosophy is bass ackwards so far as real world computer system design is concerned.  
  > **username_1**: @username_20 no I have the point, I know where you are coming from, I just don't think it is the **best** place. And reverse polish is just one option, the other as stated is BODMAS. If you have ether of these, then you need no explicit registers. However you may reuse an answer from the display, not because you have to, but because it is easier. Usually to avoid typing the formula in again. But if you can recall the formula, it is usually easier, in the long run, to fix the formula (that way there is no implicit program, than making it easier to fix, and reason with).  
  > **username_2**: @Richard : If a calculator seems to do either RPN or BODMAS, it is just an illusion.  There are registers connected to an ALU actually doing the real grunt work.  Kids have built simple calculators out of Lego's.  That's a real (and realizable) foundation.  
  > **username_1**: @username_2 see my first comment to this answer, What or how: the how is probably as you say ( and I mean probably). But the what is as I say. The user only cares about the interface. They do not think about it in terms of this particular implementation.  
  > **username_2**: Is the goal of Intro to CS to create users of interfaces?  Or start kids on the path to becoming competent computer scientists, programmers, and software engineers who really understand how to make stuff that works?  
  > **username_11**: @username_2, Are those inconsistent goals? Or is one just a part of the other. Of course, I think students should be writing interfaces and extending them as part of a larger goal.  
  > **username_11**: (1) why - I don't believe that students need to recapitulate the history of computing to learn how to program. A modern language provides a complete, consistent, model in which to think and program without needing to map to lower level abstractions. The mapping is, in fact, extra work.  
  > **username_11**: (2) how - I don't start with a bare machine and a sort of "math-y" problem. I start with a simulation of some type that already has objects in it (I use Java, mostly) that can be (a) composed and (b) extended. Look at http://greenfoot.org or better http://greenroom.greenfoot.org for many examples that you can utilize and adapt. It is also a good beginner user environment that shows both program structure and graphic simulations. Start high. Move higher. When they get some experience with the "complete consistent language environment" then (only then) show the map to the netherworld of bits.  
  
  ---
  
  ### Answer by username_9 on 2020-12-04. Score: 2
  
  Here is my recipe.
  
  1. Begin with the language's type system. If the language has a REPL, use it.
  2. Introduce variables. Indicate if variables have type (statically-compiled languages) or if they are typeless names (a la Python).
  3. Introduce the idea of object (state/identity/behavior). Objects are smart data and they can do work for you. Have the students manipulate the fundamental types of objects in the REPL. At this juncture, all programs are "boring" because they run their lines in seriatum
  4. It's time to divide the world into two types of statements, worker statements and boss statements.  
     Worker statements are imperative statements with the tacit subject "computer." Boss statements "own" chunks of code. They are grammatically incomplete sentences. They alter the flow of execution in a program.
  5. It's time for the first boss statement, the function. Explain how computing functions differ from mathematical ones. Make sure you do a careful explanation of mathematical functions and show examples (such as string length) of mathematical functions that occur often in computing.
  6. Time for three more boss statements: if, elif/else if, and else.
  7. A little recursion please, before we break out loops.
  8. Iteration: indefinite (while) and definite(for) loops. This opens the door to fileIO.
  9. Creating custom objects using classes and OO.
  
  > **Comments:**
  > **username_10**: This is quite an interesting and different ordering than I'm used to.  I assume that recursion (and functions in general) don't entirely "stick" yet, but must be revisited later.  Is this impression correct?  If so, this is an excellent ordering to begin a nice spiral through introductory programming.  
  > **username_9**: Functions come first.  They are a key way of avoiding "repeating yourself." Remembering a procedure under a name is key.  
  
  ---
  
  ### Answer by username_1 on 2017-07-20. Score: 1
  
  In touch of class — Bertrand Meyer, He start with the big stuff: object orientation, working programs. And then breaks it down toward the detail.
  So an top down approach, as opposed to the often seen bottom up.
  
  e.g. bounded loops (foreach) before unbounded loops (and how to implement bounded loops using unbounded once).
  
  Using objects before creating them.
  
  I can not see how to teach by starting with explaining each of the bricks, before teaching how to but the bricks together. I think it is better to explain what a house is, and then break it down, to explain how to make one, and as you do this explain the properties of the bricks.
  
  > **Comments:**
  > **username_11**: To support "using objects before creating them" start with an already built framework that the students work within, so that the most "primitive" thing they see is an object with behavior and that can interact with others. You build this, or find one, and the students extend it. Karel J Robot is an example of this way of thinking. Unfortunately it overuses inheritance a bit so needs to be used with some care and thought.  
  > **username_2**: To explain houses from bricks, I like using a historical approach.  Show them an abacus, human computers with mechanical adders, Baggage engine, core memory big enough to see each bit.  Throw in some stories about Ada, Turing, Shannon, and Hopper (the recent movie "Hidden Figures") to keep them interested.  Humans made lots of bricks way before learning to make beautiful cathedrals.  Teaching engineering and science is a bit different from teaching Art appreciation.  
  
  ---
  
  ### Answer by username_12 on 2020-12-04. Score: 1
  
  I feel like "loops", "variables", "conditionals", etc is a pretty loose distinction. For example, even that technically eternal loop is just a an example of `while` loop, mentally it is a much much bigger thing, completely different. Or, another example, temporary variable is mentally different from initial or result variables.
  
  What makes it worse, "conditionals" are simple to define, but vastly increase possible ways to write a program. Like:
  
  * without loops and conditionals you can write programs, though those look simple (slightly more interesting if events are already introduced)
  * with loops (but without conditionals) you can write repetetive programs, a big class of programs. For example, you can now compute $\pi$
  * with conditionals (but without loops) you can't write much sensible programs. Even if you write one, it doesn't look fun
  * with both loops and conditionals program space EXPLODES, however, beginner can't see that this explosion is zillion times larger than what was before.
  
  FWIW, is to introduce "incomplete" concepts, kinda "cliff-hangers". The eternal loop allows you to iterate things. Uh-oh, that you can't use to bound iterations, otherwise you could do X1, X2, X3, X4, .... (here students have to feel that "uh-oh"). Next lesson: Hang on, but we actually can do bounded iteration! (introduce for loop, students should recall which things they should be able to implement now).
  
  Cliffhanger stuff (know ahead stuff you have no way doing at this point of learning) is underestimated in education.
  
  
  ---
  
  