<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>

CC BY-SA 4.0
2020-12-04T23:36:31.237Z
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.
Ben I.
CC BY-SA 4.0
2020-12-07T01:06:28.407Z
Functions come first.  They are a key way of avoiding "repeating yourself." Remembering a procedure under a name is key.
ncmathsadist
CC BY-SA 4.0
2020-12-04T21:08:35.140Z
2020-12-04T21:08:35.140Z
ncmathsadist
<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>

CC BY-SA 3.0
2017-07-20T18:58:14.183Z
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.
Buffy
CC BY-SA 3.0
2017-07-22T17:25:19.943Z
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.
hotpaw2
CC BY-SA 3.0
2017-07-20T18:24:35.783Z
2017-07-20T18:24:35.783Z
ctrl-alt-delor
<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>

CC BY-SA 4.0
2020-12-04T17:29:01.553Z
2020-12-04T17:29:01.553Z
danbst
<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>

CC BY-SA 3.0
2017-07-20T18:39:15.933Z
setup and draw are procedures not functions (though C and its derivative incorrectly call them functions).
ctrl-alt-delor
CC BY-SA 3.0
2017-07-20T18:42:01.257Z
@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.
Kevin Workman
CC BY-SA 3.0
2017-07-20T18:51:44.230Z
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.
ctrl-alt-delor
CC BY-SA 3.0
2017-07-20T19:00:28.323Z
@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
Kevin Workman
CC BY-SA 3.0
2017-07-20T19:53:51.560Z
@nocomprende What is your comment replying to?
Kevin Workman
CC BY-SA 3.0
2017-07-20T20:28:12.460Z
@nocomprende You aren't being a bother, I just didn't understand whether you were replying to me or Richard.
Kevin Workman
CC BY-SA 3.0
2017-07-22T00:15:02.033Z
+1 to its depending on the programming language. The rest of your answer is good too. :-)
Ellen Spertus
CC BY-SA 3.0
2017-07-25T08:35:49.633Z
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.
Gypsy Spellweaver
CC BY-SA 3.0
2017-08-07T18:23:22.713Z
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).
Michel Billaud
CC BY-SA 3.0
2017-08-07T18:39:40.030Z
@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.
Kevin Workman
CC BY-SA 3.0
2017-08-07T19:36:52.677Z
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.
Michel Billaud
CC BY-SA 3.0
2017-08-07T20:35:50.153Z
@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!
Kevin Workman
CC BY-SA 3.0
2017-08-07T21:22:25.253Z
@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.
Michel Billaud
CC BY-SA 3.0
2017-08-07T21:34:23.570Z
@MichelBillaud Sounds good to me. I'm just saying for that first exercise, you don't need `draw()` or `setup()` at all.
Kevin Workman
CC BY-SA 3.0
2017-07-20T18:25:45.250Z
2017-07-24T22:28:41.650Z
2017-07-24T22:28:41.650Z
Kevin Workman
<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>

CC BY-SA 3.0
2017-07-21T17:03:14.407Z
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.
Federico Poloni
CC BY-SA 3.0
2017-07-21T18:57:20.720Z
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.
EvSunWoodard
CC BY-SA 3.0
2017-07-21T20:22:34.970Z
@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.
auden
CC BY-SA 3.0
2017-07-21T00:09:48.060Z
2017-07-24T18:48:53.970Z
2017-07-24T18:48:53.970Z
auden
<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>

CC BY-SA 3.0
2017-07-20T18:05:23.127Z
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. ;-)
Buffy
CC BY-SA 3.0
2017-07-20T18:30:08.097Z
@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.
ctrl-alt-delor
CC BY-SA 3.0
2017-07-20T18:35:17.690Z
@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.
ctrl-alt-delor
CC BY-SA 3.0
2017-07-20T18:46:15.330Z
@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.
ctrl-alt-delor
CC BY-SA 3.0
2017-07-20T18:48:36.293Z
@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.
Buffy
CC BY-SA 3.0
2017-07-20T17:56:16.090Z
2017-07-20T21:49:58.303Z
2017-07-20T21:49:58.303Z
ctrl-alt-delor
<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>

CC BY-SA 3.0
2017-07-21T22:20:07.990Z
The omission of this approach is why [Schlemiel the Painter](https://www.joelonsoftware.com/2001/12/11/back-to-basics/) is so common.  +1.
Wildcard
CC BY-SA 3.0
2017-07-20T20:11:47.233Z
2017-07-21T23:33:30.463Z
2017-07-21T23:33:30.463Z
hotpaw2
<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>

CC BY-SA 3.0
2017-07-20T18:44:30.767Z
Yes, I understand and agree. But we would likely still disagree.
Buffy
CC BY-SA 3.0
2017-07-20T18:56:24.463Z
@nocomprende top down or bottom up: what we are trying to do first, or how it is done first: human first or machine first.
ctrl-alt-delor
CC BY-SA 3.0
2017-07-20T21:27:19.977Z
@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.
ctrl-alt-delor
CC BY-SA 3.0
2017-07-21T05:40:22.563Z
@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.
alephzero
CC BY-SA 3.0
2017-07-21T10:08:57.153Z
@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).
ctrl-alt-delor
CC BY-SA 3.0
2017-07-21T23:09:37.567Z
@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.
hotpaw2
CC BY-SA 3.0
2017-07-21T23:19:48.370Z
@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.
ctrl-alt-delor
CC BY-SA 3.0
2017-07-21T23:31:30.170Z
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?
hotpaw2
CC BY-SA 3.0
2017-07-22T00:07:04.083Z
@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.
Buffy
CC BY-SA 3.0
2017-07-22T21:15:33.570Z
(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.
Buffy
CC BY-SA 3.0
2017-07-22T21:18:54.967Z
(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.
Buffy
CC BY-SA 3.0
2017-07-20T17:55:26.790Z
2017-07-20T17:55:26.790Z
Buffy
<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>

CC BY-SA 3.0
2017-07-20T17:43:36.450Z
What about functions and procedures.
ctrl-alt-delor
CC BY-SA 3.0
2017-07-20T17:57:54.693Z
You also need to consider separately mutating variables, and non-mutating variables. The later should be taught first.
ctrl-alt-delor
CC BY-SA 3.0
2017-07-20T17:58:45.477Z
Also consider using Objects as easier (to be done before) creating objects.
ctrl-alt-delor
CC BY-SA 3.0
2017-07-20T19:51:04.130Z
@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?
hotpaw2
CC BY-SA 3.0
2017-07-20T21:31:42.950Z
@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.
ctrl-alt-delor
CC BY-SA 3.0
2017-07-20T21:51:20.170Z
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.***
Draco18s no longer trusts SE
CC BY-SA 3.0
2017-07-20T22:35:53.697Z
Related: [When to introduce OOP in teaching programming](https://cseducators.stackexchange.com/q/666/660)
Bergi
CC BY-SA 3.0
2017-07-21T14:52:08.300Z
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).
Guy Schalnat
CC BY-SA 3.0
2017-07-22T04:17:27.513Z
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.
ThisClark
CC BY-SA 3.0
2017-07-24T18:39:23.673Z
Related: [The order of subjects in beginner's curriculum](https://cseducators.stackexchange.com/questions/2903/the-order-of-subjects-in-beginners-curriculum)
TuringTux
CC BY-SA 3.0
2017-07-25T08:50:32.860Z
@richard Other than the _real computer hardware_ referenced by hotpaw2, how else have you seen _real computer hardware_ made?
Gypsy Spellweaver
CC BY-SA 3.0
2017-07-25T09:19:52.487Z
@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.
ctrl-alt-delor
CC BY-SA 3.0
2017-07-25T09:29:31.133Z
@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.
ctrl-alt-delor
<curriculum-design><variables>
Order to Teach Topics in an Intro Programming Class
# 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**: @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.  
> **username_1**: @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.  

---

## 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, 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. 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**: @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.  
> **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**: @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!  
> **username_15**: @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.  
> **username_13**: @MichelBillaud 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 - 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**: @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.  

---

### 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 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.  
> **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.


---

