<p>I once wrote a course to introduce Java. My order of topics was as follows: (Note: Those are not lessons, just the order I've written the topics down).</p>

<ol>
<li>Obligatory Hello World, console output</li>
<li><p>Comments</p>

<blockquote>
  <p>This is something missing in the curriculum you provided. I don't know how important it really is, but I like the idea to introduce comments because I usually use them in the following examples.</p>
</blockquote></li>
<li><p>Variables, data types (the primitives and <code>String</code>)</p>

<blockquote>
  <p>This already includes <code>boolean</code></p>
</blockquote></li>
<li><p>Arrays</p>

<blockquote>
  <p>Here they are. I've just explained them as some kind of list where you could store multiple variables of the same type (half a page in my script).</p>
</blockquote></li>
<li><p>Operators (mathematical, but also logical)</p></li>
<li><p>Reading user input</p>

<blockquote>
  <p>When writing the course, I put it here; but looking over it again, I'm not particulary happy with it. I think it's a good idea to keep reading user input where it is in your curriculum.</p>
</blockquote></li>
<li><p>Conditionals (<code>if</code>, <code>else if</code>, <code>else</code>)</p>

<blockquote>
  <p>I don't explain <code>switch/case</code> here.</p>
</blockquote></li>
<li>Loops (<code>while</code> and <code>for</code>)</li>
<li><p>Basic exception handling</p>

<blockquote>
  <p>Here I only explain <code>try</code>/<code>catch</code> as a way to do something (like printing a message) when "there are errors with a part of the program".</p>
</blockquote></li>
<li><p>Writing and reading text files</p></li>
</ol>

<p>The course continues with a second part about OOP.</p>

<hr>

<p>When comparing it to your curriculum, I think there are many good elements in it. However, here are a few things I noticed:</p>

<ol>
<li><p>The <code>Math</code> library</p>

<blockquote>
  <p>If there's no special need for it (e.g. class has just discussed trigonometry in Maths and now wants to implement something using a trigonometric function) I wouldn't include it in a starters' curriculum.</p>
</blockquote></li>
<li><p><code>switch/case</code> statements</p>

<blockquote>
  <p>I'm not sure whether you really need to introduce them that early. However, if there's enough time, I also don't see a problem with it. I think I'd just drop it if there are issues with time.</p>
</blockquote></li>
<li><p>Arrays</p>

<blockquote>
  <p>As said, they are missing in this curriculum. If you drop the Math library and/or <code>switch/case</code> statements (for the reasons given above), I think you could integrate this instead. Students should already feel comfortable dealing with variables now, so the "lists of variables" can be introduced on a safe basis.</p>
  
  <p>I think it's a good idea to introduce them before loops, so you can show looping over arrays in the lesson you also introduce loops.</p>
</blockquote></li>
<li><p>Functions</p>

<blockquote>
  <p>When designing my course, I haven't really thought of them. However, the idea teaching "functions" is probably not that bad: Students now know a way how to structure a program's flow and write reusable code without having to dig into object-oriented-programming.</p>
  
  <p>On the other hand, this could also be interpreted as downside: As Java is a strictly object oriented language, it might be bad introducing functions before introducing the concepts of OOP.</p>
</blockquote></li>
</ol>

<hr>

<p>To sum up, the curriculum given by you sounds quite good to me. Except for the adjustments proposed above, I don't see much that needs to be changed.</p>

CC BY-SA 3.0
2017-07-24T22:16:46.127Z
+1 for getting comments in there early. People need to know that code is not just for the compiler/interpreter; it's also for all of the other programmers who will need to maintain the code.

This includes future-you, who will wonder what idiot wrote this crap before seeing your own initials in the comments, and realizing that now-you was in fact an idiot by future-you's standards. (If future-you doesn't think now-you was an idiot, it's because you didn't learn enough between when you wrote and re-wrote the code.)
Monty Harder
CC BY-SA 3.0
2017-07-24T11:53:42.237Z
2017-07-31T14:51:12.713Z
2017-07-31T14:51:12.713Z
TuringTux
<p>We teach AP CS assuming that our students come to us with no prior computing background. Being that the language for AP CS A is Java, we plan our sequencing accordingly. We don't follow the approach of starting with <code>Hello, world.</code> and user input because I think it (<code>main</code>, <code>System.out.println</code>, and <code>Scanner</code>) produces too much of a cognitive load at once . I always try to minimize hand waving as much as possible in the early parts of a CS course to help students build their confidence in navigating code. </p>

<p>While Eclipse is commonly used in industry and higher academia, an introductory course isn't industry or higher academia. So we use an IDE that is more appropriate for the new learner. We utilize <a href="https://www.bluej.org/" rel="noreferrer">BlueJ</a> to begin demystifying Java from the very first day of class. Thanks to BlueJ, we don't have to discuss <code>main</code> or making tester/runner classes to run our code. In our post-AP CS course we can introduce IntelliJ or Eclipse, once the students can comfortably grasp the idea of multiple classes and project directories. </p>

<p>Our decision to introduce objects early was inspired by <a href="https://www.bluej.org/objects-first/" rel="noreferrer">Dr. Kolling's book's</a> sequencing and the fact that Java is the language taught in AP CS. Others may chime in by saying they think objects should be introduced late. I disagree for the reasons previously mentioned. Should we leave AP and teach Python or Javascript, I would wait until later in the course to introduce OOP. That being said, here is our general outline:</p>

<ol>
<li>Introduction to OOP

<ul>
<li>What is a class and what is an object?</li>
</ul></li>
<li>Writing Java Classes

<ul>
<li>What makes up a Java class?</li>
<li>Fields</li>
<li>Constructors </li>
<li>Methods

<ul>
<li>Conditionals</li>
<li>Logical Operators</li>
<li>Java Math and the Math Class</li>
</ul></li>
</ul></li>
</ol>

<p><em>At this point it's September and my students can navigate an entire Java class and the hand waving of <code>public static void main(String[] args)</code> is gone. That's hugely important and beneficial.</em> </p>

<ol start="3">
<li><p>Classes as Data Types for Other Classes</p>

<ul>
<li>Encapsulation</li>
</ul></li>
<li><p>Strings</p></li>
<li><p>1D Arrays</p>

<ul>
<li>Looping</li>
</ul></li>
<li><p>2D Arrays</p></li>
<li><p>The ArrayList Class</p></li>
<li><p>Inheritance, Abstract Classes, and Interfaces</p></li>
<li><p>Algorithms</p>

<ul>
<li>Recursion</li>
<li>Searching</li>
<li>Sorting</li>
</ul></li>
</ol>

<p>Keep the students in mind. Remember where they are coming from and that your goal isn't to turn them into CS researchers or software engineers in a single year. Expose them to the content in an order that appropriately challenges them, while avoiding the statement "You can ignore that for now" as much as possible. </p>

CC BY-SA 3.0
2017-07-24T12:19:46.077Z
and that fits into 1 year? Wow...
ItamarG3
CC BY-SA 3.0
2017-07-24T13:09:05.413Z
it is a lot, but that's the dictated AP curriculum. IMO, I would ditch the higher-level OOP of inheritance and dive deeper into the collections and algorithms or work with GUIs in an intro course, but our hands are tied.
iFrame
CC BY-SA 3.0
2017-07-24T13:11:47.513Z
but is that for 1 year?
ItamarG3
CC BY-SA 3.0
2017-07-24T13:24:16.643Z
Yes. Here I am saying that one year is composed of a fall and spring semester.
iFrame
CC BY-SA 3.0
2017-07-24T13:32:12.720Z
+1 You must absolutely teach data structures. By all means ditch inheritance, but keep interfaces. Generics should probably be in there somewhere, but in Java/C# they are so intuitive that they just slide in naturally when teaching lists (no need to teach co/contravariance just yet, though explicit type constraints are straightforward enough).
VisualMelon
CC BY-SA 3.0
2017-07-25T05:11:35.337Z
iFrame, you're answer is great, but what TuringTux wrote fits what options i have in a better way. (Partly because you address things which I can't change). On the bright side, you can get the populist badge, because you might get a score 2x more than the accepted. ok?
ItamarG3
CC BY-SA 3.0
2017-07-24T12:16:46.853Z
2017-07-24T12:16:46.853Z
iFrame
<p>I would be concerned that there isn't any material on <strong>planning</strong>. In a course that has the goal of building a strong foundation for students, teaching the process of specifying and planning a solution before implementing it will pay huge dividends.</p>
<p>Personally, I am a fan of the course order in <a href="https://sites.google.com/site/cs127a/rick-s-book-2" rel="noreferrer">Rick Mercer's CS1 Textbook</a>. Chapter 1 is <em>Program Development</em>. It could be summed up as &quot;plan before you code&quot;. Of course, Mercer has more specific steps which really show the value.</p>
<blockquote>
<p><strong>Phases of Program Development and related Activities</strong></p>
<ol>
<li><p><em>Analysis</em>:  Understand the problem.</p>
</li>
<li><p><em>Design</em>:  Develop a solution</p>
</li>
<li><p><em>Implementation</em>:  Make the solution run on a computer</p>
</li>
</ol>
</blockquote>
<h2>Analysis</h2>
<p>This can be summarized in a few steps:</p>
<ol>
<li>Read and re-read the problem statement</li>
<li>Determine what the inputs are</li>
<li>Determine what the outputs are</li>
<li>Write down information on the inputs and outputs, including names and sample values</li>
</ol>
<p>For example:</p>
<pre><code>Problem             Data Name       Input or Output   Sample Data
-------             ----------      ---------------   ------------
Count how often     aBardsWork      Input             Much Ado About Nothing
Shakespeare wrote   theWord         Input             the
a particular word   howOften        Output            220
in a particular 
play
</code></pre>
<h2>Design</h2>
<p>This is where the algorithm is figured out, and psuedocode is written. It's also a great place to introduce common patterns in solutions, like the <strong>Input, Process, Output</strong> pattern so common in beginner programs.</p>
<p>For example:</p>
<pre><code>Three-Step Pattern     Pattern Applied to a Specific Algorithm
------------------     ---------------------------------------
1. Input               1. Obtain test1, test2, and finalExam
2. Process             2. Compute courseGrade
3. Output              3. Display courseGrade
</code></pre>
<p>This step could further elaborate on the details of the Process step, of course.</p>
<h2>Implementation</h2>
<p>This is where you finally code! But note that the previous steps require no knowledge of syntax at all. Those steps could be learned in the first few days of class before a single <code>static void main(String[] args)</code> is ever seen.</p>
<p>Here's the full outline of <a href="https://sites.google.com/site/cs127a/rick-s-book-2" rel="noreferrer">Rick Mercer's CS1 text</a> (aimed at college freshmen):</p>
<blockquote>
<ol>
<li>Program Development</li>
<li>Java Fundamentals</li>
<li>Objects and JUnit</li>
<li>Methods</li>
<li>Selection</li>
<li>Repetition</li>
<li>Arrays</li>
<li>Search and Sort</li>
<li>Classes with Instance Variables</li>
<li>An Array Instance Variable</li>
<li>Two Dimensional Arrays</li>
</ol>
</blockquote>

CC BY-SA 3.0
2017-07-24T14:12:59.067Z
Awesome :) In my experience, using this approach (especially the Analysis step) has helped students start tackling problems that they were initially overwhelmed by.
nova
CC BY-SA 3.0
2017-07-24T14:05:36.973Z
2017-07-24T14:05:36.973Z
2020-06-18T08:36:57.023Z
nova
<p>If the set of "allowable" topics is set by a ministry, then you have no power to do anything better, but it is misguided. Tinkering around the edges of an inadequate set will have some effect, but not a lot, I'm afraid. </p>

<p>The problem is this. Students taught this way will solve math-y problems for quite a while before they see more interesting problems. They will build up strong reinforcement patterns that "<strong>this</strong> is the way we program". Then later, when given a difficult problem they will default to those patterns again and their solutions will look like C code even in more modern languages. </p>

<p>One reason that this dominates is that the student has two problems, one is to decompose the problem <em>somehow</em> and the other is to put a solution together. If both problems are hard then they get lost. But if they have already built up strong reinforcement patterns on the second part they can use their mental energy on the first part. But since they "<em>know</em> how to program" (i.e. C) then they will just code it that way to minimize their overall effort. </p>

<p>My preference is to turn it around (though recognizing that you may not have that opportunity), so that students think first about problems and how to decompose them (into objects in my case - OOP). Then they build up the reinforcement patterns on that, so it becomes "obvious" to them and they spend their effort on the coding part. </p>

<p>The overall result is better programs, since they are more likely to have better problem decomposition into small parts that are more easily coded anyway. </p>

<p>Note that I've seen the effect of this kind of learning in industrial practice. While consulting to IBM is was approached by a team member (an employee - and a good and smart one) who wanted me to look at his code. My practice was not to do that since my charter was to talk about higher level process, but he was a good kid so I consented. He showed me a bit of code (less than 2 pages) and started out by saying he could no longer understand it (his own code). It was written (Java) using the tools you describe above. The code was one method that consisted of some deeply nested structure that would be difficult to untangle. Factoring out helper methods (a la Procedural Programming) would be difficult. </p>

<p>My first response was that I wouldn't have started out trying to write anything that looked in any way like that, and that by the time we got to the point of solving the particular problem the method attacked, we would already have a decomposition into parts that made the required (set of) methods quite trivial too write and to understand. </p>

<p>The overall effect of what you propose is that you are, in the long run, reinforcing poor habits of thought. Or at least, poorer than the alternatives allow. That sounds like just opinion, I know, until you consider the effect of reinforcement and the tendency to fall back on what you know "best" which is often what you learned "first", since you've practiced it the longest time. </p>

<p>tl;dr You are starting with the machine and with machine level solutions. Instead, start with problems and their decomposition. Assuming you can. </p>

CC BY-SA 3.0
2017-07-24T12:02:42.907Z
with 9th graders? They don't even know mathematical power rules (useful for binary). They don't have algorithmic thinking and the regular curriculum isn't the place to fix that. Maybe a summer workshop...
ItamarG3
CC BY-SA 3.0
2017-07-24T12:13:43.127Z
Fine if one of the goals is to extend their math knowledge, but early problems don't need to be math-y. They would rather be creating games anyway, I'd guess. Tradition dies hard, though.
Buffy
CC BY-SA 3.0
2017-07-24T12:17:56.760Z
That's one of the reasons I have doubts about that curriculum, which is why I asked for a review. I am simply unsure if the order seems good, and whether arrays should be included. I'm also asking about the functions part. It's overall about the curriculum, but also specific parts in it...
ItamarG3
CC BY-SA 3.0
2017-07-24T12:23:50.923Z
By functions, I assume you mean static methods. I'd (much) prefer non-static methods and polymorphism, of course, but without at least functions students can only write monolithic code. Not even C-like. A disaster for them in my view. FORTRAN. COBOL. ;-)
Buffy
CC BY-SA 3.0
2017-07-24T11:55:26.660Z
2017-07-24T12:29:59.967Z
2017-07-24T12:29:59.967Z
Buffy
<p>I will share two starting points I use for teaching CS topics:</p>

<p>1) CS is about <strong>solving problems</strong> and developing this skill in students. To that end all of our students take a mandatory class in Computer Science - Intro To Java Programming where the focus is on solving problems using a simple visual robot simulator.  In this class students spend much more time discussing and writing down ideas (in english) than "coding". Our focus is on designing advanced robot <em>behaviors</em> and interactions to solve increasingly difficult scenarios.</p>

<p>The important thing to note here is that we focus on developing a foundation of thinking skills and introduce computational thinking and problem solving methods.  The first exposure to "programming" is base on an objects-first approach where much of the details of "coding" is hidden. (for an example see the <a href="https://itunes.apple.com/ca/app/lightbot-code-hour/id873943739?mt=8" rel="nofollow noreferrer">LightBot</a> app in the app store).</p>

<p>2) In the AP CS A class (not Principles which is usually taken first and has a strong focus on algorithms and abstraction, which build naturally upon the previous courses), I usually teach the topics in the historical order of their use, from the Abacus to Artificial Intelligence (or self learning machines like Alpha Go). I use examples that are appropriate to the current stage of CS evolution, and many of these solutions evolve as we learn and use more techniques and tools.</p>

<p>For example:</p>

<p>Early in the course we look at developing a console based guess the number game.
Our first focus is on developing an algorithm for this and evaluating solutions. Along the way we look at how to make our own random number generator, then later we look at using one from the program library, etc.
We <strong>iterate</strong> over various solutions improving its utility: We don't let the computer make duplicate guesses.</p>

<p>Solving the problem of avoiding generated duplicates can be be quite challenging, especially early on.  It's worth trying on your own. You will find many interesting approaches.</p>

<p>1st iteration: use n-1 variables to store previous guesses
 - This brings up the idea of a collection of <em>similar items</em> - arrays.</p>

<p>2nd iteration: use an array of size n to store all guesses 
 - This brings up the question of how to manage the items in the array</p>

<p>3rd iteration: use collections
 - removing the guess as it occurs from this list of unused numbers and randomly selecting from a new, and smaller subset.</p>

<p>By the time we get to collections we also discuss having a collection of <em>heterogeneous</em> items.  Then we talk about the problems with that, leading to strongly typed collections and Generics etc.  Then we move backwards to homogeneous collections but now within the framework of <em>polymorphism</em> which bring us back to behaviors and interactions.</p>

<p>I find that the historic approach combined with the why did we <strong>invent</strong> this / <em>what problems does it solve</em>, works quite well because it gives the students a sense of why something exists, and how it might be used. It allows them to see a variety of possible solutions and be selective in their choices.<br>
(Why did we invent screws? What's wrong with nails?)</p>

<p>I use the same approach for </p>

<ul>
<li>global / local variables and passing parameters</li>
<li>Abstract Data Types to Classes / Objects</li>
<li>Manipulation of data to Interaction of objects</li>
<li>And finally, developing behaviors (having objects doTheRightThing()).</li>
</ul>

<p>and for the evolution of using</p>

<ul>
<li>Sentinels</li>
<li>nulls (missing values)</li>
<li>Null Objects</li>
</ul>

<p>I can also challenge the students if I think they are seeing everything as a nail (overusing their hammers), or suggest if they are designing / coding caveman like solutions (do more efficient or elegant solutions exist).</p>

<p>Along the way their thinking moves from functional to behavioral.</p>

CC BY-SA 3.0
2018-01-04T17:46:00.427Z
Welcome to CSEducators. We hope to see more such contributions in the future.
Buffy
CC BY-SA 3.0
2018-01-04T16:43:48.337Z
2018-01-04T19:13:09.993Z
2018-01-04T19:13:09.993Z
Mr Bradley
<p>If you're an unofficial TA, why are you the one coming up with the curriculum? Anyway, my review is inline:</p>
<blockquote>
<p>introduction and simple printing of text</p>
</blockquote>
<p>I wouldn't limit this to printing text. I would frame it as a lesson on <strong>calling functions</strong>. Printing text is one example. Showing a simple dialog box is another example. Come up with a list of basic functions, and get them into the habit of looking stuff up in that list. Basically you're training them to look stuff up in <a href="https://docs.oracle.com/javase/8/docs/api/" rel="nofollow noreferrer">the Java API</a>.</p>
<blockquote>
<p>Simple Eclipse console Input\Output and user input (print what the user inputs etc.) as well as variables (just primitives, and just int,double,char and String).</p>
</blockquote>
<p>I would absolutely not start them out in Eclipse. Start them out with a basic text editor and the command line. They need to understand what the compiler is doing, and how their code is being run. Eclipse is great for advanced coding, but it hides way too much of the fundamentals to start out in.</p>
<blockquote>
<p>Mathematical operators: +,-,*,/ as well as %. The curriculum has an option to teach increment as well as +=, -= and the rest.</p>
</blockquote>
<p>Make sure you teach these in an engaging way. Have them write programs that play simple math games like higher-lower or the subtraction game.</p>
<blockquote>
<p>Conditionals: if, if\else and nested ifs. Also boolean is introduced.
switch-case. Not much to say about this at this level.</p>
</blockquote>
<p>Boolean needs to come before <code>if</code> statements.</p>
<blockquote>
<p>Math library. This is one of the things that caused me to doubt the order of things in the curriculum.</p>
</blockquote>
<p>I don't know why you need to treat this as a separate thing. Include it in the &quot;mini-reference&quot; that you give them on the first day.</p>
<blockquote>
<p>for loops and various uses. Arrays are not taught in the curriculum at all</p>
</blockquote>
<p>The use cases for <code>for</code> loops in a command-line environment are not very engaging, but if you're stuck with &quot;pure Java&quot; then I guess that's a problem you're going to have throughout the course.</p>
<blockquote>
<p>while loops.</p>
<p>Nested loops.</p>
</blockquote>
<p>You should teach nesting as soon as possible, as it's always a point of confusion. Start with nested <code>if</code> statements above.</p>
<blockquote>
<p>functions. yes, functions</p>
</blockquote>
<p>Not sure why you're saying &quot;yes, functions&quot; here, but this is a reasonable thing to include. I would maybe go a step further and try to get to creating classes.</p>
<p>Here is the order I suggested in my answer to the related <a href="https://cseducators.stackexchange.com/questions/2793/order-to-teach-topics-in-an-intro-programming-class">Order to Teach Topics in an Intro Programming Class</a> question:</p>
<p>Instead of using &quot;pure Java&quot;, I would use a language called <a href="https://processing.org/" rel="nofollow noreferrer">Processing</a>, which is built on top of Java (and can be used as a Java library) and allows you to create visual, animated programs without any boilerplate code.</p>
<p>Even if you can't use Processing, here's the order I would talk about topics:</p>
<ul>
<li>Calling Functions</li>
<li>Using Variables</li>
<li>Creating Variables</li>
<li>Creating Functions</li>
<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>These topics can be covered in Java, albeit with a ton more boilerplate code than if you used Processing.</p>

CC BY-SA 3.0
2017-07-24T20:09:38.203Z
Teaching java is something I can't change. Which is why the question is lagged with Java.
ItamarG3
CC BY-SA 3.0
2017-07-24T20:13:21.580Z
@ItamarG3 Fair enough. I posted this mostly for the order, which wouldn't necessarily be much different for a "pure Java" course. And for what it's worth, Processing is built on top of Java and can be used as a Java library. See also: https://cseducators.stackexchange.com/questions/19/using-processing-as-an-entry-point-in-an-introductory-course
Kevin Workman
CC BY-SA 3.0
2017-07-24T20:06:22.330Z
2017-07-25T16:41:40.750Z
2020-06-18T08:36:57.023Z
Kevin Workman
<p>Consider that the best way to teach Java might not be to teach Java (at first). </p>

<p>For several programming languages (those that were not designed for pedagogy/teaching), starting with a teaching language or environment, and segueing later to the more arcane/abstract coding syntax, might be the easier path, and leave less students out in the cold (or typing magic incantations with near zero understanding).</p>

CC BY-SA 3.0
2017-07-24T20:17:00.143Z
2017-07-24T20:17:00.143Z
hotpaw2
<p>I learned to program by looking at simple program that did things, working out a bit about how they work, and changing them.   So I learned a little bit about each topic in some random order as my overall understanding increased.</p>

<p>Therefore maybe start with LOGO and the class having some <strong>fun</strong> with a Turtle moving about the floor, then loops etc can be introduced along with "if" assuming the Turtle has some sensors on it.  Once the students start having fun you can move onto the formal topics.</p>

<p>Otherwise you risk having everyone that has not already learned that programming is fun from their come computers not seeing the point of learning programming.</p>

CC BY-SA 3.0
2017-07-24T14:28:52.353Z
Welcome to [cseducators.se]! I hope we hear more from you :)
Ben I.
CC BY-SA 3.0
2017-07-24T13:21:52.440Z
2017-07-24T13:21:52.440Z
Ian Ringrose
<p><em>Pure ordering</em> should be dictated by how you intend to interconnect the ideas. For instance, I use arrays as a motivating example for <code>for</code> loops, so it makes sense to introduce arrays to my students before <code>for</code> statements.  Think about segues, motivating examples, and lab assignments, and a sensible order should emerge on its own.</p>

<p>Questions of <em>what to include</em>, however, are not so simple.  Your major curricular goals now become central considerations.</p>

<p>The curriculum you've shown us looks like a pretty reasonable objects-last approach to beginning Java.  I do agree with you that arrays are pretty fundamental, though, particularly when utilizing an objects-last approach, as they are the only tool prior to objects that allow you to deal with variable amounts of data.</p>

<p>There is one additional red flag (for me) that you may want to mention to the instructor. Nowhere in your write-up is a discussion of mutability, with all of the cognitive traps that it brings. Mutability is often the <em>secret trap</em> that kids fall into, because <code>x = x + 1</code> is not a sensible algebraic statement. </p>

<p>If it is not specifically discussed, beginning programmers will take what they know about equality and apply it in an ad-hoc manner to code. Sometimes they get it right, sometimes they get it wrong, and there may be little consistency, <em>even with the same student</em> from one moment to another. </p>

<p>This is because, if mutability is not explicitly taught, folks just kind of drift <em>between</em> all of the contradictory ideas about <code>=</code> that start to float around in their minds, fuzzing from one idea to another, without any fully concrete sense of what it really is.</p>

<p>This notion has been discussed already fairly extensively on this site (such as  my write-up <a href="https://cseducators.stackexchange.com/a/345/27">here</a>, or this question <a href="https://cseducators.stackexchange.com/questions/1300/how-do-i-teach-math-equality-vs-cs-assignment-vs-cs-equality-logic-operat">here</a>.) If you don't call attention to the idea of <code>=</code> as an <em>operation</em>, very different from the declaritive $=$ that kids know from math, they may never dig back out if that hole.</p>

CC BY-SA 3.0
2017-07-25T17:50:10.183Z
It caught me unawares as well. It took me well into my 3rd year of teaching CS and scratching my head at the code students submitted on written exams before a conversation with a kid finally made the lightbulb go on for me.
Ben I.
CC BY-SA 3.0
2017-07-24T15:49:35.370Z
2017-07-24T15:49:35.370Z
Ben I.
<p>This year I'll be an unofficial teacher assistant in the CS class of 9th graders.</p>
<h2>Background</h2>
<p>This question is about a curriculum for introducing students to programming in java.</p>
<p>The students are in 9th grade (14-15 years old) and are not expected to have any background whatsoever in computer science (usually some do have, but that's not relevant to the curriculum. Differentiating it is something relatively easy at this stage).</p>
<p>This curriculum spans 2 terms (1 year - Sept. to June), and is meant to build a firm foundation for students. The subject is compulsory in 9th grade. I have some doubts regarding the ordering of the subjects in the curriculum.</p>
<h2>How it stands</h2>
<p>Students are initially introduced to computers in general.</p>
<p>The first lesson is always brainstorming: <em>&quot;What is computer science?&quot;</em>. It's established from there that programming (&quot;computer science is writing code&quot; is usually a response of a few students) is writing something, and then converting it into binary (it's expected that they know that the binary numbering system <em>exists</em>). The students use the remaining time (<span class="math-container">$\pm$</span>10 minutes) to write the famous:</p>
<pre><code>public static void main(String[] args){ //we don't explain this line
    System.out.println(&quot;Hello, World!&quot;); //sometimes we use a Hebrew alternative:
    System.out.println(&quot;!שלום, עולם&quot;);//which is literally the translation
}
</code></pre>
<p>That's the first lesson. From here, I'll list the subjects (each one is a subject, and not a separate lesson; lessons are ignored, I only address the subjects of the curriculum) taught (the language used to teach is Java)</p>
<p>   0. (First Lesson) introduction and simple printing of text</p>
<ol>
<li><p>Simple Eclipse console Input\Output and user input (print what the user inputs etc.) as well as variables (just primitives, and just <code>int</code>,<code>double</code>,<code>char</code> and <code>String</code>).</p>
</li>
<li><p>Mathematical operators: <code>+</code>,<code>-</code>,<code>*</code>,<code>/</code> as well as <code>%</code>. The curriculum has an option to teach increment  as well as <code>+=</code>, <code>-=</code> and the rest.</p>
</li>
<li><p>Conditionals: <code>if</code>, <code>if\else</code> and nested <code>if</code>s. Also <code>boolean</code> is introduced.</p>
</li>
<li><p><code>switch-case</code>. Not much to say about this at this level.</p>
</li>
<li><p><code>Math</code> library. This is one of the things that caused me to doubt the order of things in the curriculum.</p>
</li>
<li><p><code>for</code> loops and various uses. Arrays are not taught in the curriculum <strong>at all</strong></p>
</li>
<li><p><code>while</code> loops.</p>
</li>
<li><p>Nested loops.</p>
</li>
<li><p>functions. yes, functions:</p>
<pre><code>static returnType functionName ( parameters)
{
    //operations
    return returnValue;
}
</code></pre>
</li>
</ol>
<p>That's it.</p>
<h2>Doubts</h2>
<p>I spotted a few issues in the curriculum. First and foremost: Where are all the arrays? I want to include arrays, but I'm not sure where\instead of what.</p>
<p>Teaching <code>for</code> after arrays seems better than before, because then I can show the <code>foreach</code> in the same lesson. They are essentially the same (but not 100% equivalent. Concurrent modifications is something beginners aren't ready for). So I am uncertain about the order of the subjects.</p>
<p>Secondly: Functions. Again, why? I want to remove them from the curriculum (students learn about them in the following years anyway, as part of OOP), but this might do more damage than good. Students might want to know, after an entire year, what <em>exactly</em> is the meaning of the <code>public <strong>static</strong> <em>void</em> <em><strong>main</strong></em></code> from lesson 1.</p>
<p>Functions can explain that, but other than that, it's pointless at this stage (because they'll learn it anyway, should they major in CS).</p>
<p>So, does the order of subjects in the curriculum, as it stands, make sense (keeping in mind that arrays are not covered at all)?</p>
<p>Note: this question is not a duplicate of <a href="https://cseducators.stackexchange.com/questions/2793">this one</a>, simply because I already have a curriculum, and I am asking for a review of it. I'm also asking about specific aspects of my curriculum, and not general &quot;hand wave-ish&quot; things.</p>

CC BY-SA 3.0
2017-07-24T11:32:17.063Z
A good start for a course in C. Java, not so much.
Buffy
CC BY-SA 3.0
2017-07-24T11:36:22.510Z
@Buffy that, I can't change. But I also don't quite agree with you. I think both are quite ok for introductory classes.
ItamarG3
CC BY-SA 3.0
2017-07-24T13:44:36.813Z
First language I learned was Visual Basic, and we learned it by dragging stuff onto a form, then changing their properties in the IDE, then double clicking them (to auto-generate their event handlers), and changing the properties in code. After that we learned variables. It really helped when it came time to learn OOP, because we had already worked with the visual classes.
Stephen S
CC BY-SA 3.0
2017-07-24T13:46:03.233Z
@StephenS So what do you suggest I do with the curriculum? How should I reorder the subjects (or add\remove subjects)?
ItamarG3
CC BY-SA 3.0
2017-07-24T20:03:46.570Z
Possible duplicate of [Order to Teach Topics in an Intro Programming Class](https://cseducators.stackexchange.com/questions/2793/order-to-teach-topics-in-an-intro-programming-class)
Kevin Workman
CC BY-SA 3.0
2017-07-24T22:04:14.423Z
We teach a camp for iOS development in the summers, which is thankfully more graphical but my suggestions would be:
- keep it visual is possible, interactivity builds interest
- dispel the programming magic as much as possible, if you have a debugger show them how to step through line by line and watch variables
- avoid duplication of concepts where possible (unless it is a real programming class). You have if/else, you don't need switches. Take a second day on if/else, it will pay off more.
- nested loops are trivial, unless you are also covering variable scope
Christophe
CC BY-SA 3.0
2017-07-25T07:37:32.247Z
I'm voting to keep this open. The suggested duplicate is asking for curriculum design, this one is asking for curriculum review, a natural next step _after_ design, and therefore not the same thing. The coincidence of title does not make it a duplicate.
Gypsy Spellweaver
CC BY-SA 3.0
2017-07-25T07:38:26.983Z
@GypsySpellweaver Thank you Gypsy. I think I said that in my edit, but you put it more nicely...
ItamarG3
CC BY-SA 3.0
2017-07-25T09:27:14.257Z
@Christophe You should post your answer below, rather than in a comment; you'll be able to expand further on your viewpoint and others can then vote on your post, too. Comments aren't really suited to posting answers (they're for asking clarification/giving critique, etc)
Aurora0001
<secondary-education><java><curriculum-review>
The order of subjects in beginner's curriculum
# The order of subjects in beginner's curriculum

(Asked by: username_0 on 2017-07-24)

This year I'll be an unofficial teacher assistant in the CS class of 9th graders.
Background
This question is about a curriculum for introducing students to programming in java.
The students are in 9th grade (14-15 years old) and are not expected to have any background whatsoever in computer science (usually some do have, but that's not relevant to the curriculum. Differentiating it is something relatively easy at this stage).
This curriculum spans 2 terms (1 year - Sept. to June), and is meant to build a firm foundation for students. The subject is compulsory in 9th grade. I have some doubts regarding the ordering of the subjects in the curriculum.
How it stands
Students are initially introduced to computers in general.
The first lesson is always brainstorming: "What is computer science?". It's established from there that programming ("computer science is writing code" is usually a response of a few students) is writing something, and then converting it into binary (it's expected that they know that the binary numbering system exists). The students use the remaining time ($\pm$10 minutes) to write the famous:
public static void main(String[] args){ //we don't explain this line
    System.out.println("Hello, World!"); //sometimes we use a Hebrew alternative:
    System.out.println("!שלום, עולם");//which is literally the translation
}

That's the first lesson. From here, I'll list the subjects (each one is a subject, and not a separate lesson; lessons are ignored, I only address the subjects of the curriculum) taught (the language used to teach is Java)
   0. (First Lesson) introduction and simple printing of text

Simple Eclipse console Input\Output and user input (print what the user inputs etc.) as well as variables (just primitives, and just int,double,char and String).

Mathematical operators: +,-,*,/ as well as %. The curriculum has an option to teach increment  as well as +=, -= and the rest.

Conditionals: if, if\else and nested ifs. Also boolean is introduced.

switch-case. Not much to say about this at this level.

Math library. This is one of the things that caused me to doubt the order of things in the curriculum.

for loops and various uses. Arrays are not taught in the curriculum at all

while loops.

Nested loops.

functions. yes, functions:
static returnType functionName ( parameters)
{
    //operations
    return returnValue;
}



That's it.
Doubts
I spotted a few issues in the curriculum. First and foremost: Where are all the arrays? I want to include arrays, but I'm not sure where\instead of what.
Teaching for after arrays seems better than before, because then I can show the foreach in the same lesson. They are essentially the same (but not 100% equivalent. Concurrent modifications is something beginners aren't ready for). So I am uncertain about the order of the subjects.
Secondly: Functions. Again, why? I want to remove them from the curriculum (students learn about them in the following years anyway, as part of OOP), but this might do more damage than good. Students might want to know, after an entire year, what exactly is the meaning of the public static void main from lesson 1.
Functions can explain that, but other than that, it's pointless at this stage (because they'll learn it anyway, should they major in CS).
So, does the order of subjects in the curriculum, as it stands, make sense (keeping in mind that arrays are not covered at all)?
Note: this question is not a duplicate of this one, simply because I already have a curriculum, and I am asking for a review of it. I'm also asking about specific aspects of my curriculum, and not general "hand wave-ish" things.

**Tags:** secondary-education, java, curriculum-review

> **Comments:**
> **username_1**: A good start for a course in C. Java, not so much.  
> **username_0**: @username_1 that, I can't change. But I also don't quite agree with you. I think both are quite ok for introductory classes.  
> **username_2**: First language I learned was Visual Basic, and we learned it by dragging stuff onto a form, then changing their properties in the IDE, then double clicking them (to auto-generate their event handlers), and changing the properties in code. After that we learned variables. It really helped when it came time to learn OOP, because we had already worked with the visual classes.  
> **username_0**: @StephenS So what do you suggest I do with the curriculum? How should I reorder the subjects (or add\remove subjects)?  
> **username_3**: Possible duplicate of [Order to Teach Topics in an Intro Programming Class](https://cseducators.stackexchange.com/questions/2793/order-to-teach-topics-in-an-intro-programming-class)  
> **username_4**: We teach a camp for iOS development in the summers, which is thankfully more graphical but my suggestions would be: - keep it visual is possible, interactivity builds interest - dispel the programming magic as much as possible, if you have a debugger show them how to step through line by line and watch variables - avoid duplication of concepts where possible (unless it is a real programming class). You have if/else, you don't need switches. Take a second day on if/else, it will pay off more. - nested loops are trivial, unless you are also covering variable scope  
> **username_5**: I'm voting to keep this open. The suggested duplicate is asking for curriculum design, this one is asking for curriculum review, a natural next step _after_ design, and therefore not the same thing. The coincidence of title does not make it a duplicate.  
> **username_0**: @GypsySpellweaver Thank you Gypsy. I think I said that in my edit, but you put it more nicely...  
> **username_6**: @username_4 You should post your answer below, rather than in a comment; you'll be able to expand further on your viewpoint and others can then vote on your post, too. Comments aren't really suited to posting answers (they're for asking clarification/giving critique, etc)  

---

## 9 answers

### Answer by username_7 on 2017-07-24. Score: 7 | Accepted answer

I once wrote a course to introduce Java. My order of topics was as follows: (Note: Those are not lessons, just the order I've written the topics down).

1. Obligatory Hello World, console output
2. Comments

   > This is something missing in the curriculum you provided. I don't know how important it really is, but I like the idea to introduce comments because I usually use them in the following examples.
3. Variables, data types (the primitives and `String`)

   > This already includes `boolean`
4. Arrays

   > Here they are. I've just explained them as some kind of list where you could store multiple variables of the same type (half a page in my script).
5. Operators (mathematical, but also logical)
6. Reading user input

   > When writing the course, I put it here; but looking over it again, I'm not particulary happy with it. I think it's a good idea to keep reading user input where it is in your curriculum.
7. Conditionals (`if`, `else if`, `else`)

   > I don't explain `switch/case` here.
8. Loops (`while` and `for`)
9. Basic exception handling

   > Here I only explain `try`/`catch` as a way to do something (like printing a message) when "there are errors with a part of the program".
10. Writing and reading text files

The course continues with a second part about OOP.

---

When comparing it to your curriculum, I think there are many good elements in it. However, here are a few things I noticed:

1. The `Math` library

   > If there's no special need for it (e.g. class has just discussed trigonometry in Maths and now wants to implement something using a trigonometric function) I wouldn't include it in a starters' curriculum.
2. `switch/case` statements

   > I'm not sure whether you really need to introduce them that early. However, if there's enough time, I also don't see a problem with it. I think I'd just drop it if there are issues with time.
3. Arrays

   > As said, they are missing in this curriculum. If you drop the Math library and/or `switch/case` statements (for the reasons given above), I think you could integrate this instead. Students should already feel comfortable dealing with variables now, so the "lists of variables" can be introduced on a safe basis.
   >
   > I think it's a good idea to introduce them before loops, so you can show looping over arrays in the lesson you also introduce loops.
4. Functions

   > When designing my course, I haven't really thought of them. However, the idea teaching "functions" is probably not that bad: Students now know a way how to structure a program's flow and write reusable code without having to dig into object-oriented-programming.
   >
   > On the other hand, this could also be interpreted as downside: As Java is a strictly object oriented language, it might be bad introducing functions before introducing the concepts of OOP.

---

To sum up, the curriculum given by you sounds quite good to me. Except for the adjustments proposed above, I don't see much that needs to be changed.

> **Comments:**
> **username_8**: +1 for getting comments in there early. People need to know that code is not just for the compiler/interpreter; it's also for all of the other programmers who will need to maintain the code.  This includes future-you, who will wonder what idiot wrote this crap before seeing your own initials in the comments, and realizing that now-you was in fact an idiot by future-you's standards. (If future-you doesn't think now-you was an idiot, it's because you didn't learn enough between when you wrote and re-wrote the code.)  

---

### Answer by username_9 on 2017-07-24. Score: 13

We teach AP CS assuming that our students come to us with no prior computing background. Being that the language for AP CS A is Java, we plan our sequencing accordingly. We don't follow the approach of starting with `Hello, world.` and user input because I think it (`main`, `System.out.println`, and `Scanner`) produces too much of a cognitive load at once . I always try to minimize hand waving as much as possible in the early parts of a CS course to help students build their confidence in navigating code.

While Eclipse is commonly used in industry and higher academia, an introductory course isn't industry or higher academia. So we use an IDE that is more appropriate for the new learner. We utilize [BlueJ](https://www.bluej.org/) to begin demystifying Java from the very first day of class. Thanks to BlueJ, we don't have to discuss `main` or making tester/runner classes to run our code. In our post-AP CS course we can introduce IntelliJ or Eclipse, once the students can comfortably grasp the idea of multiple classes and project directories.

Our decision to introduce objects early was inspired by [Dr. Kolling's book's](https://www.bluej.org/objects-first/) sequencing and the fact that Java is the language taught in AP CS. Others may chime in by saying they think objects should be introduced late. I disagree for the reasons previously mentioned. Should we leave AP and teach Python or Javascript, I would wait until later in the course to introduce OOP. That being said, here is our general outline:

1. Introduction to OOP
   * What is a class and what is an object?
2. Writing Java Classes
   * What makes up a Java class?
   * Fields
   * Constructors
   * Methods
     + Conditionals
     + Logical Operators
     + Java Math and the Math Class

*At this point it's September and my students can navigate an entire Java class and the hand waving of `public static void main(String[] args)` is gone. That's hugely important and beneficial.*

3. Classes as Data Types for Other Classes

   * Encapsulation
4. Strings
5. 1D Arrays

   * Looping
6. 2D Arrays
7. The ArrayList Class
8. Inheritance, Abstract Classes, and Interfaces
9. Algorithms

   * Recursion
   * Searching
   * Sorting

Keep the students in mind. Remember where they are coming from and that your goal isn't to turn them into CS researchers or software engineers in a single year. Expose them to the content in an order that appropriately challenges them, while avoiding the statement "You can ignore that for now" as much as possible.

> **Comments:**
> **username_0**: and that fits into 1 year? Wow...  
> **username_9**: it is a lot, but that's the dictated AP curriculum. IMO, I would ditch the higher-level OOP of inheritance and dive deeper into the collections and algorithms or work with GUIs in an intro course, but our hands are tied.  
> **username_0**: but is that for 1 year?  
> **username_9**: Yes. Here I am saying that one year is composed of a fall and spring semester.  
> **username_10**: +1 You must absolutely teach data structures. By all means ditch inheritance, but keep interfaces. Generics should probably be in there somewhere, but in Java/C# they are so intuitive that they just slide in naturally when teaching lists (no need to teach co/contravariance just yet, though explicit type constraints are straightforward enough).  
> **username_0**: username_9, you're answer is great, but what username_7 wrote fits what options i have in a better way. (Partly because you address things which I can't change). On the bright side, you can get the populist badge, because you might get a score 2x more than the accepted. ok?  

---

### Answer by username_11 on 2017-07-24. Score: 5

I would be concerned that there isn't any material on planning. In a course that has the goal of building a strong foundation for students, teaching the process of specifying and planning a solution before implementing it will pay huge dividends.
Personally, I am a fan of the course order in Rick Mercer's CS1 Textbook. Chapter 1 is Program Development. It could be summed up as "plan before you code". Of course, Mercer has more specific steps which really show the value.

Phases of Program Development and related Activities

Analysis:  Understand the problem.

Design:  Develop a solution

Implementation:  Make the solution run on a computer



Analysis
This can be summarized in a few steps:

Read and re-read the problem statement
Determine what the inputs are
Determine what the outputs are
Write down information on the inputs and outputs, including names and sample values

For example:
Problem             Data Name       Input or Output   Sample Data
-------             ----------      ---------------   ------------
Count how often     aBardsWork      Input             Much Ado About Nothing
Shakespeare wrote   theWord         Input             the
a particular word   howOften        Output            220
in a particular 
play

Design
This is where the algorithm is figured out, and psuedocode is written. It's also a great place to introduce common patterns in solutions, like the Input, Process, Output pattern so common in beginner programs.
For example:
Three-Step Pattern     Pattern Applied to a Specific Algorithm
------------------     ---------------------------------------
1. Input               1. Obtain test1, test2, and finalExam
2. Process             2. Compute courseGrade
3. Output              3. Display courseGrade

This step could further elaborate on the details of the Process step, of course.
Implementation
This is where you finally code! But note that the previous steps require no knowledge of syntax at all. Those steps could be learned in the first few days of class before a single static void main(String[] args) is ever seen.
Here's the full outline of Rick Mercer's CS1 text (aimed at college freshmen):


Program Development
Java Fundamentals
Objects and JUnit
Methods
Selection
Repetition
Arrays
Search and Sort
Classes with Instance Variables
An Array Instance Variable
Two Dimensional Arrays

> **Comments:**
> **username_11**: Awesome :) In my experience, using this approach (especially the Analysis step) has helped students start tackling problems that they were initially overwhelmed by.  

---

### Answer by username_1 on 2017-07-24. Score: 5

If the set of "allowable" topics is set by a ministry, then you have no power to do anything better, but it is misguided. Tinkering around the edges of an inadequate set will have some effect, but not a lot, I'm afraid.

The problem is this. Students taught this way will solve math-y problems for quite a while before they see more interesting problems. They will build up strong reinforcement patterns that "**this** is the way we program". Then later, when given a difficult problem they will default to those patterns again and their solutions will look like C code even in more modern languages.

One reason that this dominates is that the student has two problems, one is to decompose the problem *somehow* and the other is to put a solution together. If both problems are hard then they get lost. But if they have already built up strong reinforcement patterns on the second part they can use their mental energy on the first part. But since they "*know* how to program" (i.e. C) then they will just code it that way to minimize their overall effort.

My preference is to turn it around (though recognizing that you may not have that opportunity), so that students think first about problems and how to decompose them (into objects in my case - OOP). Then they build up the reinforcement patterns on that, so it becomes "obvious" to them and they spend their effort on the coding part.

The overall result is better programs, since they are more likely to have better problem decomposition into small parts that are more easily coded anyway.

Note that I've seen the effect of this kind of learning in industrial practice. While consulting to IBM is was approached by a team member (an employee - and a good and smart one) who wanted me to look at his code. My practice was not to do that since my charter was to talk about higher level process, but he was a good kid so I consented. He showed me a bit of code (less than 2 pages) and started out by saying he could no longer understand it (his own code). It was written (Java) using the tools you describe above. The code was one method that consisted of some deeply nested structure that would be difficult to untangle. Factoring out helper methods (a la Procedural Programming) would be difficult.

My first response was that I wouldn't have started out trying to write anything that looked in any way like that, and that by the time we got to the point of solving the particular problem the method attacked, we would already have a decomposition into parts that made the required (set of) methods quite trivial too write and to understand.

The overall effect of what you propose is that you are, in the long run, reinforcing poor habits of thought. Or at least, poorer than the alternatives allow. That sounds like just opinion, I know, until you consider the effect of reinforcement and the tendency to fall back on what you know "best" which is often what you learned "first", since you've practiced it the longest time.

tl;dr You are starting with the machine and with machine level solutions. Instead, start with problems and their decomposition. Assuming you can.

> **Comments:**
> **username_0**: with 9th graders? They don't even know mathematical power rules (useful for binary). They don't have algorithmic thinking and the regular curriculum isn't the place to fix that. Maybe a summer workshop...  
> **username_1**: Fine if one of the goals is to extend their math knowledge, but early problems don't need to be math-y. They would rather be creating games anyway, I'd guess. Tradition dies hard, though.  
> **username_0**: That's one of the reasons I have doubts about that curriculum, which is why I asked for a review. I am simply unsure if the order seems good, and whether arrays should be included. I'm also asking about the functions part. It's overall about the curriculum, but also specific parts in it...  
> **username_1**: By functions, I assume you mean static methods. I'd (much) prefer non-static methods and polymorphism, of course, but without at least functions students can only write monolithic code. Not even C-like. A disaster for them in my view. FORTRAN. COBOL. ;-)  

---

### Answer by username_12 on 2018-01-04. Score: 5

I will share two starting points I use for teaching CS topics:

1) CS is about **solving problems** and developing this skill in students. To that end all of our students take a mandatory class in Computer Science - Intro To Java Programming where the focus is on solving problems using a simple visual robot simulator. In this class students spend much more time discussing and writing down ideas (in english) than "coding". Our focus is on designing advanced robot *behaviors* and interactions to solve increasingly difficult scenarios.

The important thing to note here is that we focus on developing a foundation of thinking skills and introduce computational thinking and problem solving methods. The first exposure to "programming" is base on an objects-first approach where much of the details of "coding" is hidden. (for an example see the [LightBot](https://itunes.apple.com/ca/app/lightbot-code-hour/id873943739?mt=8) app in the app store).

2) In the AP CS A class (not Principles which is usually taken first and has a strong focus on algorithms and abstraction, which build naturally upon the previous courses), I usually teach the topics in the historical order of their use, from the Abacus to Artificial Intelligence (or self learning machines like Alpha Go). I use examples that are appropriate to the current stage of CS evolution, and many of these solutions evolve as we learn and use more techniques and tools.

For example:

Early in the course we look at developing a console based guess the number game.
Our first focus is on developing an algorithm for this and evaluating solutions. Along the way we look at how to make our own random number generator, then later we look at using one from the program library, etc.
We **iterate** over various solutions improving its utility: We don't let the computer make duplicate guesses.

Solving the problem of avoiding generated duplicates can be be quite challenging, especially early on. It's worth trying on your own. You will find many interesting approaches.

1st iteration: use n-1 variables to store previous guesses
- This brings up the idea of a collection of *similar items* - arrays.

2nd iteration: use an array of size n to store all guesses
- This brings up the question of how to manage the items in the array

3rd iteration: use collections
- removing the guess as it occurs from this list of unused numbers and randomly selecting from a new, and smaller subset.

By the time we get to collections we also discuss having a collection of *heterogeneous* items. Then we talk about the problems with that, leading to strongly typed collections and Generics etc. Then we move backwards to homogeneous collections but now within the framework of *polymorphism* which bring us back to behaviors and interactions.

I find that the historic approach combined with the why did we **invent** this / *what problems does it solve*, works quite well because it gives the students a sense of why something exists, and how it might be used. It allows them to see a variety of possible solutions and be selective in their choices.  
(Why did we invent screws? What's wrong with nails?)

I use the same approach for

* global / local variables and passing parameters
* Abstract Data Types to Classes / Objects
* Manipulation of data to Interaction of objects
* And finally, developing behaviors (having objects doTheRightThing()).

and for the evolution of using

* Sentinels
* nulls (missing values)
* Null Objects

I can also challenge the students if I think they are seeing everything as a nail (overusing their hammers), or suggest if they are designing / coding caveman like solutions (do more efficient or elegant solutions exist).

Along the way their thinking moves from functional to behavioral.

> **Comments:**
> **username_1**: Welcome to CSEducators. We hope to see more such contributions in the future.  

---

### Answer by username_15 on 2017-07-24. Score: 4

*Pure ordering* should be dictated by how you intend to interconnect the ideas. For instance, I use arrays as a motivating example for `for` loops, so it makes sense to introduce arrays to my students before `for` statements. Think about segues, motivating examples, and lab assignments, and a sensible order should emerge on its own.

Questions of *what to include*, however, are not so simple. Your major curricular goals now become central considerations.

The curriculum you've shown us looks like a pretty reasonable objects-last approach to beginning Java. I do agree with you that arrays are pretty fundamental, though, particularly when utilizing an objects-last approach, as they are the only tool prior to objects that allow you to deal with variable amounts of data.

There is one additional red flag (for me) that you may want to mention to the instructor. Nowhere in your write-up is a discussion of mutability, with all of the cognitive traps that it brings. Mutability is often the *secret trap* that kids fall into, because `x = x + 1` is not a sensible algebraic statement.

If it is not specifically discussed, beginning programmers will take what they know about equality and apply it in an ad-hoc manner to code. Sometimes they get it right, sometimes they get it wrong, and there may be little consistency, *even with the same student* from one moment to another.

This is because, if mutability is not explicitly taught, folks just kind of drift *between* all of the contradictory ideas about `=` that start to float around in their minds, fuzzing from one idea to another, without any fully concrete sense of what it really is.

This notion has been discussed already fairly extensively on this site (such as my write-up [here](https://cseducators.stackexchange.com/a/345/27), or this question [here](https://cseducators.stackexchange.com/questions/1300/how-do-i-teach-math-equality-vs-cs-assignment-vs-cs-equality-logic-operat).) If you don't call attention to the idea of `=` as an *operation*, very different from the declaritive $=$ that kids know from math, they may never dig back out if that hole.

> **Comments:**
> **username_15**: It caught me unawares as well. It took me well into my 3rd year of teaching CS and scratching my head at the code students submitted on written exams before a conversation with a kid finally made the lightbulb go on for me.  

---

### Answer by username_3 on 2017-07-24. Score: 3

If you're an unofficial TA, why are you the one coming up with the curriculum? Anyway, my review is inline:

> introduction and simple printing of text

I wouldn't limit this to printing text. I would frame it as a lesson on **calling functions**. Printing text is one example. Showing a simple dialog box is another example. Come up with a list of basic functions, and get them into the habit of looking stuff up in that list. Basically you're training them to look stuff up in [the Java API](https://docs.oracle.com/javase/8/docs/api/).

> Simple Eclipse console Input\Output and user input (print what the user inputs etc.) as well as variables (just primitives, and just int,double,char and String).

I would absolutely not start them out in Eclipse. Start them out with a basic text editor and the command line. They need to understand what the compiler is doing, and how their code is being run. Eclipse is great for advanced coding, but it hides way too much of the fundamentals to start out in.

> Mathematical operators: +,-,\*,/ as well as %. The curriculum has an option to teach increment as well as +=, -= and the rest.

Make sure you teach these in an engaging way. Have them write programs that play simple math games like higher-lower or the subtraction game.

> Conditionals: if, if\else and nested ifs. Also boolean is introduced.
> switch-case. Not much to say about this at this level.

Boolean needs to come before `if` statements.

> Math library. This is one of the things that caused me to doubt the order of things in the curriculum.

I don't know why you need to treat this as a separate thing. Include it in the "mini-reference" that you give them on the first day.

> for loops and various uses. Arrays are not taught in the curriculum at all

The use cases for `for` loops in a command-line environment are not very engaging, but if you're stuck with "pure Java" then I guess that's a problem you're going to have throughout the course.

> while loops.
>
> Nested loops.

You should teach nesting as soon as possible, as it's always a point of confusion. Start with nested `if` statements above.

> functions. yes, functions

Not sure why you're saying "yes, functions" here, but this is a reasonable thing to include. I would maybe go a step further and try to get to creating classes.

Here is the order I suggested in my answer to the related [Order to Teach Topics in an Intro Programming Class](https://cseducators.stackexchange.com/questions/2793/order-to-teach-topics-in-an-intro-programming-class) question:

Instead of using "pure Java", I would use a language called [Processing](https://processing.org/), which is built on top of Java (and can be used as a Java library) and allows you to create visual, animated programs without any boilerplate code.

Even if you can't use Processing, here's the order I would talk about topics:

* Calling Functions
* Using Variables
* Creating Variables
* Creating Functions
* Debugging
* If Statements
* Animation
* For Loops
* Arrays
* User Input
* Using Objects
* Creating Classes
* ArrayLists
* Images
* Libraries
* Deploying your code

These topics can be covered in Java, albeit with a ton more boilerplate code than if you used Processing.

> **Comments:**
> **username_0**: Teaching java is something I can't change. Which is why the question is lagged with Java.  
> **username_3**: @username_0 Fair enough. I posted this mostly for the order, which wouldn't necessarily be much different for a "pure Java" course. And for what it's worth, Processing is built on top of Java and can be used as a Java library. See also: https://cseducators.stackexchange.com/questions/19/using-processing-as-an-entry-point-in-an-introductory-course  

---

### Answer by username_13 on 2017-07-24. Score: 3

Consider that the best way to teach Java might not be to teach Java (at first).

For several programming languages (those that were not designed for pedagogy/teaching), starting with a teaching language or environment, and segueing later to the more arcane/abstract coding syntax, might be the easier path, and leave less students out in the cold (or typing magic incantations with near zero understanding).


---

### Answer by username_14 on 2017-07-24. Score: 3

I learned to program by looking at simple program that did things, working out a bit about how they work, and changing them. So I learned a little bit about each topic in some random order as my overall understanding increased.

Therefore maybe start with LOGO and the class having some **fun** with a Turtle moving about the floor, then loops etc can be introduced along with "if" assuming the Turtle has some sensors on it. Once the students start having fun you can move onto the formal topics.

Otherwise you risk having everyone that has not already learned that programming is fun from their come computers not seeing the point of learning programming.

> **Comments:**
> **username_15**: Welcome to [cseducators.se]! I hope we hear more from you :)  

---

