<p>I am surprised to hear of State Machines being introduced anywhere early in a curriculum. They are a solution to a particular kind of problem, and wouldn't make much sense outside of it. So, this is an indication to me that the curriculum is getting things backwards.</p>

<p>Humans need to learn things starting with very concrete situations that are graspable. Then they can start to use those concrete ideas as building blocks. Then they can start to reason about the blocks, with a bit of abstraction, then a bit more. You can't start with abstraction, the brain simply does not work that way.</p>

<p>Eventually, after years of nights of good sleep, enough ideas and familiarity will accumulate for motivated people to start to think on their own about things like programming. (And math. Music. Art. Philosophy... Etc.) But it doesn't come easy or fast. Sounds like a song I heard long ago.</p>

<p>If people developed programming in a particular way, maybe that is the best way to teach people about programming? If brains produced those ideas in a particular order, maybe that is how brains work and we should respect that and follow it? You can't push a rope uphill, but pulling on it works every time.</p>

CC BY-SA 4.0
2019-02-15T00:52:08.123Z
*"You gotta pay your dues if you wanna sing the blues, but you know it don't come easy. You don't have to shout or leap about, you can even play them easy."*
Scott Rowe
CC BY-SA 4.0
2019-02-15T00:49:41.287Z
2019-02-15T00:49:41.287Z
Scott Rowe
<p>In addition to Buffy's excellent suggestions, I might suggest reframing your own thinking.  You are thinking and speaking rather abstractly.  Little phrases like "a means for mapping an individual's thoughts to formal language" and the question "Should state machines be introduced somehow more explicitly, with better examples" hint to me that you're really thinking about how to get them directly to your way of thinking.</p>

<p>The truth is that abstract ideas are not great starting points for great learning.  Abstraction is a way of grouping seemingly disparate ideas to allow us to utilize them more readily or more flexibly.  That's actually a key idea!</p>

<p>If we grok this notion of abstraction, then the way to achieve flexible, abstract thinking is to first have fluency with the smaller, disparate concrete ideas.  Only after several of these ideas are firmly entrenched and comfortable can we then look at them as system and make successful links between the ideas.  (BTW, I am using the word "successful" here as a marker for an abstraction that we can readily utilize.)</p>

<p>This fits in with our lived experience.  Typically, we see some small systems, discover (or learn about) how they actually operate the same way, and then expand on the abstraction through new linked ideas over time.  When the system works well, rich and complex ideas get boiled down to very simple underlying mechanisms, so that we ultimately can apply the abstraction readily in many different mental domains.</p>

<p>This distillation takes time, and it requires us to have at least a few well-understood pieces before it really kicks in.</p>

<p>Finite State Machines are wonderful, powerful concepts, but these students who haven't figured out when to utilize a function aren't there yet.  Even if you show them the abstraction, they aren't mentally positioned to take any real advantage of it.</p>

<p><strong>Therefore</strong>, your best bet is to hit the concrete ideas that you want <em>hard</em>.  Make sure they have a few of the micro-skills, and provide direct instruction.  Then, introduce abstractions slowly as systems are mastered.</p>

<p>One last thought for you: it's absolutely normal for kids to come out with only a middling understanding of the material in a prior course.  As frustrating as that can be, we muddle by with half-understandings all the time in many domains.  Don't think it beneath you to briefly run over material again, both to remind those who have forgotten, and to give a hand to those who never quite got it the first time.  (Keep these kids in your heart when you make your reviews, and the kids who just needed a reminder will be better off for it as well.)</p>

<p>Good luck!</p>

CC BY-SA 4.0
2019-02-20T00:24:32.273Z
I always started to understand the previous math core course during the current one.
Scott Rowe
CC BY-SA 4.0
2019-02-18T17:18:14.093Z
2019-02-18T17:18:14.093Z
Ben I.
<p>I will add to this, choice of language is also important, learning <code>C</code> (and forget <code>C++</code>) and how to program at the same time is to hard (see zone of proximal development).</p>
<p>Even Java is to hard:</p>
<ul>
<li>Explaining <code>public static void Main(string[] args)</code></li>
<li>Explaining that all programs need a main, but don't put anything in it, except <code>new Program().run();</code> (main does not scale).</li>
<li>Don't use static it does not scale, but we have to use it in lesson 1.</li>
<li><code>public</code>/<code>private</code> in lesson 1.</li>
<li><code>void</code> in lesson 1, but don't use it, we will use functions.</li>
</ul>
<p>May be with Unit Testing we can avoid main, but this is just the start. As an experienced programmer, I can do Java, but I find it exhausting, the amount of extra work that I have to do, just to express the most simple of ideas.</p>
<h1>So what to choose</h1>
<p>A language with contracts: adding pre/post conditions, will give you a clearer idea of what it is you are trying to do. If you don't know what you are trying to do, then how can you do it.</p>
<p>A language with a clean syntax, no extraneous words (public static void …). <code>=</code> means <code>=</code>, and assignment has its own symbol/keyword.</p>
<p>Is functional, or promotes functional.</p>
<p>A language with good defaults: data-attributes are private by default, methods are public by default.</p>
<p>The programming model, maps well to the theoretical model. E.g. Theoretical Object-oriented model maps to programming model (this is not true of most OO languages), or functional model maps to programming model.</p>
<p>Has a simple exception system (these are often overly complex). Not to hard to understand, but hard to work with.</p>

CC BY-SA 4.0
2019-02-20T00:26:25.313Z
COBOL was successful for a reason, yes?
Scott Rowe
CC BY-SA 4.0
2019-02-20T09:32:57.850Z
@ScottRowe Yes, and the reason was, that is all we had. We have learnt a lot since then. There are much better languages, for both teaching and professional programmers. Your argument is like Microsoft is successful for a reason. In this case it is because they used to be cheaper than Unix. Now it is because we follow each other. (perfect market hypothesis, see https://jimabbondante.files.wordpress.com/2010/02/change-processionary-cat.jpg?w=209&h=228 and https://notmanywise.files.wordpress.com/2012/02/caterpillars2.jpg
ctrl-alt-delor
CC BY-SA 4.0
2019-02-20T12:53:44.493Z
We have better languages. People do not get better every generation though, they all start with no concepts or experience. The Tower of Babel was not successful. A one-story house is.
Scott Rowe
CC BY-SA 4.0
2019-02-21T09:23:24.280Z
@scottrowe sorry if I suggested that things are getting better. My impression is that there was a flurry of progress in the 1960s, and then not much else. (an exception being N vs NP, sat solvers. I hear there has been much progress in these over the last 20 years, but these are not programming languages (or for beginners).
ctrl-alt-delor
CC BY-SA 4.0
2019-02-23T19:35:06.807Z
The video "The Future of Programming" is just as true today as the day it was made. I think everyone should see it. But, I am about to show coworkers how to build web applications with ASP.Net and ADO.Net.
Scott Rowe
CC BY-SA 4.0
2020-12-14T05:02:01.360Z
@ScottRowe: Can you flesh out the reference to "The Future of Programming" video? Searching online today, I see many different videos with that title.
Daniel R. Collins
CC BY-SA 4.0
2020-12-14T19:29:27.047Z
@DanielR.Collins The one by Bret Victor is probably the best.
ctrl-alt-delor
CC BY-SA 4.0
2020-12-16T16:25:56.170Z
@DanielR.Collins This link describes the video on [Bret's web site](http://worrydream.com/dbx/). I have not seen anything about him from the past 5 years, so I am wondering what he is up to.
Scott Rowe
CC BY-SA 4.0
2019-02-16T16:50:12.200Z
2019-02-16T16:50:12.200Z
2020-06-18T08:36:57.023Z
ctrl-alt-delor
<p>Here's a late answer, but I think has observations for the OP that others haven't highlighted sufficiently.</p>
<blockquote>
<p>They moreover have this (to me, crazy) habit of writing huge blocks in
main() without splitting anything, and even worse the only way they
think about of producing output is writing to the world: they don't
contemplate returning from a function. One (brilliant!) boy once asked
me with big amazement after my seemingly strong assertion: &quot;oh, so you
mean that strlen() is a function?&quot;</p>
</blockquote>
<p>I teach in a community college curriculum that uses C++ for the initial two-semester sequence of programming. (Using Gaddis, <em>Starting out with C++: from control structures through objects</em>; i.e., control structures 1st semester, objects 2nd semester). The single biggest hump for our students is to accept modularizing their programs into separate functions, which occurs about halfway into the 1st semester.</p>
<p>I think I broadly feel why they really, really don't want to start doing that. They're legitimately able to get a working program by writing all the statements in main() up to the point. The overhead of learning to add prototype, header, code, call (which of those requires the type? the identifier? both?), parameters, arguments, pass-by-value vs. pass-by-reference, return value, scoping rules, what counts as a good name, etc. is not insignificant to them. If they can just get the immediate assignment working without grappling with that new gauntlet of concepts, then they'd generally prefer to do that. Plus the advantage is really not evident at that point: they're not working in a large team-environment where the division of labor really pays off. They're not hitting any radical increase in complexity where it's infeasible to cram a few more lines into main(). Even the textbook's labs and examples are not super hygienic about this.</p>
<p>So I am aware that I really need to hit this very hard all through the last 1.5 terms of our curriculum. I make modularizing programs an explicit requirement for all programs from that point forward, and reiterate in the directions for all assignments and tests. A hefty point penalty is deducted otherwise (i.e., the entire 20% component for &quot;Readability&quot;). I uniquely spend two days reviewing the concept and justification. I uniquely (in any course I teach) have a slide in shouty 120-point font laying out the demand. The book also seems to know this is the major hurdle, as it has a double-length series of labs for that particular chapter.</p>
<p>In brief: Modularizing the code seems like the single biggest hurdle, and the curriculum really must dedicate significant time to getting students on board with it.</p>
<p>Now, in the OP's case they're really in a major dilemma if they're receiving students at the end of a curriculum and this hasn't happened to date. Teaching the early courses in a context of finite state machines, global variables, and no modularity, is perilously close to causing irreparable brain injury in this regard. It's not entirely clear what the OP's context, requirements, or flexibilities are, but solutions probably need to pick from among the following:</p>
<ol>
<li><p>If the OP has any power over the institutional curriculum, <em>change it</em>, so that modularity for future changes and expansions is taught and tested at an early stage.</p>
</li>
<li><p>If the OP does not have any power over the rest of the curriculum, but has significant flexibility in their own course design, then they likely should spend 2+ weeks at the start of the course explicitly teaching students this methodology. It's actually not bad to set that as the major theme of the course on Day 1 in a big banner to get their attention (and keep touching back to that all semester long).</p>
</li>
<li><p>If the OP hasn't any power over the program's overall curriculum, and also lacks any flexibility for what gets taught in their own course (some kind of mandated higher-level curriculum) then they need to bite the bullet and accept that most of the students are simply not going to be able to interface with higher-level concepts, and fail them. Maybe a one-day &quot;review&quot; at the start of the course, and reference to materials on the subject, is the best you can do.</p>
</li>
<li><p>If you have no power over the program sequence, and no flexibility in the individual course design, and are also not allowed to fail most of the students, then what can you do? Resign oneself to giving out fraudulent grades or leave the position, I guess.</p>
</li>
</ol>
<p>There are times when I kind of wish the modularity issue was more up-front, but in my opinion it's even less comprehensible at a point when no task takes the 5-7 statements or so that makes a cognizable function. That is: if initially every function is itself just a single statement then there's no way you can convince students that's not a big waste of time and effort (because it is). So I do think you need to establish data declarations, assignment, conditionals, and loops before you've got enough mechanics that you can legitimately abstract a chunk of functionality into a modular and reusable function.</p>
<p>An anti-example of the latter: there's an open-source work by Busbee, <em>Programming Fundamentals -- A Modular Structured Approach Using C++</em> that attempts to present modular functions first and foremost. Ch. 1 introduces a function which is a wrapper around the Windows <code>system(&quot;pause&quot;)</code> statement. But in the need to avoid all the other scoping details at this point, he falls into a trap of using global variables for all the data-passing, and gets stuck with it. I don't think there's any example in the entire text of ever using parameters, local variables, or return values (which is of course absolutely deadly to the cause).</p>
<p>In summary: <em>Somewhere</em> in the curriculum you've got to dig in and spend time clarifying this most-difficult-and-important part of the subject matter (modularizing code into functions). You're not going to get it happening by just saying it once and wishing it to be. You need some initial work developing the basic toolkit in the main function, but then need to transition to modular designs, and the longer this gets delayed the more bad habits will need unlearning later on.</p>

CC BY-SA 4.0
2020-12-16T16:37:21.260Z
When I was self-teaching in 9th grade on a PDP-11 terminal, I wrote simple programs in BASIC (or a script language... I forget after several decades) to create shapes on the terminal screen using asterisks and spaces. This requires nested loops, and pretty quickly rewards creating functions. So, a "**motivating example**" will teach the need for proper design. It is simply too hard to copy-paste the code in multiple places, change it, fix bugs and so on. Then functions seem like "a pretty neat idea." Simplifying the code becomes an organizing impulse. Choose projects that build.
Scott Rowe
CC BY-SA 4.0
2020-12-14T16:51:25.420Z
2020-12-15T03:12:37.943Z
2020-12-15T03:12:37.943Z
Daniel R. Collins
<p>There is a lot to unpack here, but first, YES, the teaching methodology can be improved, but that is always true, an unending quest. </p>

<p>Next, I'll note that C is a language with enough pitfalls that many people struggle with it at the detail level, finding it harder to think more globally. My preference, perhaps not open to you, is to start with a language at a higher level of abstraction generally and then, later in the curriculum, work both downward toward the machine and upward from where you start. An OO or pure functional language, if well taught, makes abstraction easier. </p>

<p>However, the biggest recommendation I'd make to address the problems you state is to introduce (at the beginning) <em>unit testing</em> and <em>test driven development</em> (TDD). Find a good testing environment for your language and insist on its use: No Code Without a Failing Test. </p>

<p>I normally start out a course with TDD, combined with giving assignments in an already logically decomposed way. Instead of a large program to write (large is relative, of course), I give them the "top down" decomposition initially that, in C they would be able to implement by writing a lot of functions. </p>

<p>Thus, at the beginning, I relieve them of having to face a blank screen with a large problem and nothing but 'main()' to work with. Later you can continue this, but making the pieces bigger, requiring some decomposition (helper functions) be developed. My mantra for a "too big function" is about five lines. My mantra for "too complex function" is nesting more than two levels. You can break these rules for especially boring code, but not for the interesting logic of a program, or it will be impossible to understand and maintain. </p>

<p>Note that breaking a problem up into parts is how Agile Development (Extreme Programming, Scrum, ...) actually work, with the Customer (in this case you) giving the Team (your students) manageable problems each of which contributes value. </p>

<p>Also, with TDD, you can provide some tests initially along with simple requirements. Teach them to stop programming when the tests pass. Or, write additional tests and make them pass. But the tests are small and simple, usually without internal logic, and the application code needed to make them pass should also be simple function and uses of functions. </p>

CC BY-SA 4.0
2019-02-14T16:02:07.480Z
2019-02-14T16:02:07.480Z
Buffy
<p>In my beginner experience as a teacher, the thing that's strucking me most is a sensation of my students' inability to express their (valid!) thoughts in code. Let me deepen it a bit.</p>

<p>I inherited a last year class that was supposed to know C from their previous years. Anyway they struggled in manually tracing the execution of the code they see, being it mine or theirs.
After some work I could test and evaluate them again and it now seems to me that they are actually quite good at reasoning about a sort of "abstract idea" of what they want their algorithms to do: they can use our natural language to say things like scan this, sum that, stop here or there, and they are pretty much correct. What they seem to have big difficulties in is saying the same thing using a formal language.</p>

<p>They moreover have this (to me, crazy) habit of writing huge blocks in main() without splitting anything, and even worse the only way they think about of producing output is writing to the world: they don't contemplate returning from a function. One (brilliant!) boy once asked me with big amazement after my seemingly strong assertion: "oh, so you mean that strlen() is a function?".
Of course I may understand where this comes from, but I suspect it's not healthy for their learning.</p>

<p>It seems to me that a possible reason of this observed behaviour might lie in having taught them to build huge state machines without making them have a clue that they are building huge state machines: they can reproduce some they have already seen but are really lost when needing to make a new one. Even having them apply small modifications seems to me more like a blind trial from their part than some reasoning about the meanings. The building blocks of the language do not play well together in their minds or they are just unable to think about the state transitions in the code.</p>

<p>If I have to push myself a bit more I can say that I suspect all this is a reflection of the non composability of state machines, making their use in teaching to absolute novices not effective, whereas functions are known to be composable and would presumably lead to better results, <strong>in terms of being a means for mapping an individual's thoughts to formal language</strong>.</p>

<p>Is my analysis plausible? Have you experienced anything similar? Is there any available scientific literature on these phenomena? How would you test them to investigate deeper their difficulties and how would you try to show them a more effective route? Is there anything you would do to improve the methodology for next classes?</p>

<p>Should state machines be introduced somehow more explicitly, with better examples, showing how do they actually solve problems before throwing them to the poor students with a burden of syntax that they know nothing about? They even told me clearly that syntax is the only thing they focused all their energies on in their previous years.</p>

<p>What I am doing in younger classes is proposing functions first (as in functional paradigm), to solidify the concept of building a small composable block that has input and output, waiting a bit more in the future to introduce state transitions using the classic drawing turtle of fame with the hope that its visual feedback might make things tangible.</p>

CC BY-SA 4.0
2019-02-22T23:01:25.017Z
I think answering their questions (and ensuring they feel comfortable asking) should probably be much higher priority in your teaching. If they're still learning, they probably need a lot of examples, too. I'm guessing they're not as fluent with C as your impression seems to be. They probably need more practice with it.
Brōtsyorfuzthrāx
CC BY-SA 4.0
2019-02-23T21:40:20.140Z
I find your phrase "*mapping an individual's thoughts to formal language*" mildly disturbing. Just sayin'...
Scott Rowe
CC BY-SA 4.0
2019-03-07T04:48:18.603Z
state machines, as in finite automata?
kate
CC BY-SA 4.0
2019-03-07T15:30:14.143Z
Scott: writing code is giving a shape of code to one's thoughts of operations and the like, for disturbing it may be.
user9137
CC BY-SA 4.0
2019-03-07T18:13:36.613Z
Kate: yes, state machines as in automata.
user9137
CC BY-SA 4.0
2021-01-11T05:37:10.010Z
I know this is late but I wanted to point out a great exercise to make it clear why you should not have just one giant function: write a 200-500 line program using functions and good design principles, and then add a bug. Next, make a copy and inline all the functions into the main, and hand both copies to the students and ask them to find the bug. They will see for themselves why bad code is considered bad. They will also see how much easier it is to find the bug in the well written code, despite its size.
Asad-ullah Khan
<programming><lesson-order>
Students seem to be unable to use code to express their ideas. Is the teaching methodology improvable?
# Students seem to be unable to use code to express their ideas. Is the teaching methodology improvable?

(Asked by: username_0 on 2019-02-14)

In my beginner experience as a teacher, the thing that's strucking me most is a sensation of my students' inability to express their (valid!) thoughts in code. Let me deepen it a bit.

I inherited a last year class that was supposed to know C from their previous years. Anyway they struggled in manually tracing the execution of the code they see, being it mine or theirs.
After some work I could test and evaluate them again and it now seems to me that they are actually quite good at reasoning about a sort of "abstract idea" of what they want their algorithms to do: they can use our natural language to say things like scan this, sum that, stop here or there, and they are pretty much correct. What they seem to have big difficulties in is saying the same thing using a formal language.

They moreover have this (to me, crazy) habit of writing huge blocks in main() without splitting anything, and even worse the only way they think about of producing output is writing to the world: they don't contemplate returning from a function. One (brilliant!) boy once asked me with big amazement after my seemingly strong assertion: "oh, so you mean that strlen() is a function?".
Of course I may understand where this comes from, but I suspect it's not healthy for their learning.

It seems to me that a possible reason of this observed behaviour might lie in having taught them to build huge state machines without making them have a clue that they are building huge state machines: they can reproduce some they have already seen but are really lost when needing to make a new one. Even having them apply small modifications seems to me more like a blind trial from their part than some reasoning about the meanings. The building blocks of the language do not play well together in their minds or they are just unable to think about the state transitions in the code.

If I have to push myself a bit more I can say that I suspect all this is a reflection of the non composability of state machines, making their use in teaching to absolute novices not effective, whereas functions are known to be composable and would presumably lead to better results, **in terms of being a means for mapping an individual's thoughts to formal language**.

Is my analysis plausible? Have you experienced anything similar? Is there any available scientific literature on these phenomena? How would you test them to investigate deeper their difficulties and how would you try to show them a more effective route? Is there anything you would do to improve the methodology for next classes?

Should state machines be introduced somehow more explicitly, with better examples, showing how do they actually solve problems before throwing them to the poor students with a burden of syntax that they know nothing about? They even told me clearly that syntax is the only thing they focused all their energies on in their previous years.

What I am doing in younger classes is proposing functions first (as in functional paradigm), to solidify the concept of building a small composable block that has input and output, waiting a bit more in the future to introduce state transitions using the classic drawing turtle of fame with the hope that its visual feedback might make things tangible.

**Tags:** programming, lesson-order

> **Comments:**
> **username_1**: I think answering their questions (and ensuring they feel comfortable asking) should probably be much higher priority in your teaching. If they're still learning, they probably need a lot of examples, too. I'm guessing they're not as fluent with C as your impression seems to be. They probably need more practice with it.  
> **username_2**: I find your phrase "*mapping an individual's thoughts to formal language*" mildly disturbing. Just sayin'...  
> **username_3**: state machines, as in finite automata?  
> **username_0**: Scott: writing code is giving a shape of code to one's thoughts of operations and the like, for disturbing it may be.  
> **username_0**: Kate: yes, state machines as in automata.  
> **username_4**: I know this is late but I wanted to point out a great exercise to make it clear why you should not have just one giant function: write a 200-500 line program using functions and good design principles, and then add a bug. Next, make a copy and inline all the functions into the main, and hand both copies to the students and ask them to find the bug. They will see for themselves why bad code is considered bad. They will also see how much easier it is to find the bug in the well written code, despite its size.  

---

## 5 answers

### Answer by username_8 on 2019-02-14. Score: 7 | Accepted answer

There is a lot to unpack here, but first, YES, the teaching methodology can be improved, but that is always true, an unending quest.

Next, I'll note that C is a language with enough pitfalls that many people struggle with it at the detail level, finding it harder to think more globally. My preference, perhaps not open to you, is to start with a language at a higher level of abstraction generally and then, later in the curriculum, work both downward toward the machine and upward from where you start. An OO or pure functional language, if well taught, makes abstraction easier.

However, the biggest recommendation I'd make to address the problems you state is to introduce (at the beginning) *unit testing* and *test driven development* (TDD). Find a good testing environment for your language and insist on its use: No Code Without a Failing Test.

I normally start out a course with TDD, combined with giving assignments in an already logically decomposed way. Instead of a large program to write (large is relative, of course), I give them the "top down" decomposition initially that, in C they would be able to implement by writing a lot of functions.

Thus, at the beginning, I relieve them of having to face a blank screen with a large problem and nothing but 'main()' to work with. Later you can continue this, but making the pieces bigger, requiring some decomposition (helper functions) be developed. My mantra for a "too big function" is about five lines. My mantra for "too complex function" is nesting more than two levels. You can break these rules for especially boring code, but not for the interesting logic of a program, or it will be impossible to understand and maintain.

Note that breaking a problem up into parts is how Agile Development (Extreme Programming, Scrum, ...) actually work, with the Customer (in this case you) giving the Team (your students) manageable problems each of which contributes value.

Also, with TDD, you can provide some tests initially along with simple requirements. Teach them to stop programming when the tests pass. Or, write additional tests and make them pass. But the tests are small and simple, usually without internal logic, and the application code needed to make them pass should also be simple function and uses of functions.


---

### Answer by username_2 on 2019-02-15. Score: 6

I am surprised to hear of State Machines being introduced anywhere early in a curriculum. They are a solution to a particular kind of problem, and wouldn't make much sense outside of it. So, this is an indication to me that the curriculum is getting things backwards.

Humans need to learn things starting with very concrete situations that are graspable. Then they can start to use those concrete ideas as building blocks. Then they can start to reason about the blocks, with a bit of abstraction, then a bit more. You can't start with abstraction, the brain simply does not work that way.

Eventually, after years of nights of good sleep, enough ideas and familiarity will accumulate for motivated people to start to think on their own about things like programming. (And math. Music. Art. Philosophy... Etc.) But it doesn't come easy or fast. Sounds like a song I heard long ago.

If people developed programming in a particular way, maybe that is the best way to teach people about programming? If brains produced those ideas in a particular order, maybe that is how brains work and we should respect that and follow it? You can't push a rope uphill, but pulling on it works every time.

> **Comments:**
> **username_2**: *"You gotta pay your dues if you wanna sing the blues, but you know it don't come easy. You don't have to shout or leap about, you can even play them easy."*  

---

### Answer by username_5 on 2019-02-18. Score: 5

In addition to username_8's excellent suggestions, I might suggest reframing your own thinking. You are thinking and speaking rather abstractly. Little phrases like "a means for mapping an individual's thoughts to formal language" and the question "Should state machines be introduced somehow more explicitly, with better examples" hint to me that you're really thinking about how to get them directly to your way of thinking.

The truth is that abstract ideas are not great starting points for great learning. Abstraction is a way of grouping seemingly disparate ideas to allow us to utilize them more readily or more flexibly. That's actually a key idea!

If we grok this notion of abstraction, then the way to achieve flexible, abstract thinking is to first have fluency with the smaller, disparate concrete ideas. Only after several of these ideas are firmly entrenched and comfortable can we then look at them as system and make successful links between the ideas. (BTW, I am using the word "successful" here as a marker for an abstraction that we can readily utilize.)

This fits in with our lived experience. Typically, we see some small systems, discover (or learn about) how they actually operate the same way, and then expand on the abstraction through new linked ideas over time. When the system works well, rich and complex ideas get boiled down to very simple underlying mechanisms, so that we ultimately can apply the abstraction readily in many different mental domains.

This distillation takes time, and it requires us to have at least a few well-understood pieces before it really kicks in.

Finite State Machines are wonderful, powerful concepts, but these students who haven't figured out when to utilize a function aren't there yet. Even if you show them the abstraction, they aren't mentally positioned to take any real advantage of it.

**Therefore**, your best bet is to hit the concrete ideas that you want *hard*. Make sure they have a few of the micro-skills, and provide direct instruction. Then, introduce abstractions slowly as systems are mastered.

One last thought for you: it's absolutely normal for kids to come out with only a middling understanding of the material in a prior course. As frustrating as that can be, we muddle by with half-understandings all the time in many domains. Don't think it beneath you to briefly run over material again, both to remind those who have forgotten, and to give a hand to those who never quite got it the first time. (Keep these kids in your heart when you make your reviews, and the kids who just needed a reminder will be better off for it as well.)

Good luck!

> **Comments:**
> **username_2**: I always started to understand the previous math core course during the current one.  

---

### Answer by username_6 on 2019-02-16. Score: 2

I will add to this, choice of language is also important, learning `C` (and forget `C++`) and how to program at the same time is to hard (see zone of proximal development).

Even Java is to hard:

* Explaining `public static void Main(string[] args)`
* Explaining that all programs need a main, but don't put anything in it, except `new Program().run();` (main does not scale).
* Don't use static it does not scale, but we have to use it in lesson 1.
* `public`/`private` in lesson 1.
* `void` in lesson 1, but don't use it, we will use functions.

May be with Unit Testing we can avoid main, but this is just the start. As an experienced programmer, I can do Java, but I find it exhausting, the amount of extra work that I have to do, just to express the most simple of ideas.

# So what to choose

A language with contracts: adding pre/post conditions, will give you a clearer idea of what it is you are trying to do. If you don't know what you are trying to do, then how can you do it.

A language with a clean syntax, no extraneous words (public static void …). `=` means `=`, and assignment has its own symbol/keyword.

Is functional, or promotes functional.

A language with good defaults: data-attributes are private by default, methods are public by default.

The programming model, maps well to the theoretical model. E.g. Theoretical Object-oriented model maps to programming model (this is not true of most OO languages), or functional model maps to programming model.

Has a simple exception system (these are often overly complex). Not to hard to understand, but hard to work with.

> **Comments:**
> **username_2**: COBOL was successful for a reason, yes?  
> **username_6**: @ScottRowe Yes, and the reason was, that is all we had. We have learnt a lot since then. There are much better languages, for both teaching and professional programmers. Your argument is like Microsoft is successful for a reason. In this case it is because they used to be cheaper than Unix. Now it is because we follow each other. (perfect market hypothesis, see https://jimabbondante.files.wordpress.com/2010/02/change-processionary-cat.jpg?w=209&h=228 and https://notmanywise.files.wordpress.com/2012/02/caterpillars2.jpg  
> **username_2**: We have better languages. People do not get better every generation though, they all start with no concepts or experience. The Tower of Babel was not successful. A one-story house is.  
> **username_6**: @scottrowe sorry if I suggested that things are getting better. My impression is that there was a flurry of progress in the 1960s, and then not much else. (an exception being N vs NP, sat solvers. I hear there has been much progress in these over the last 20 years, but these are not programming languages (or for beginners).  
> **username_2**: The video "The Future of Programming" is just as true today as the day it was made. I think everyone should see it. But, I am about to show coworkers how to build web applications with ASP.Net and ADO.Net.  
> **username_7**: @ScottRowe: Can you flesh out the reference to "The Future of Programming" video? Searching online today, I see many different videos with that title.  
> **username_6**: @DanielR.Collins The one by Bret Victor is probably the best.  
> **username_2**: @DanielR.Collins This link describes the video on [Bret's web site](http://worrydream.com/dbx/). I have not seen anything about him from the past 5 years, so I am wondering what he is up to.  

---

### Answer by username_7 on 2020-12-14. Score: 2

Here's a late answer, but I think has observations for the OP that others haven't highlighted sufficiently.

> They moreover have this (to me, crazy) habit of writing huge blocks in
> main() without splitting anything, and even worse the only way they
> think about of producing output is writing to the world: they don't
> contemplate returning from a function. One (brilliant!) boy once asked
> me with big amazement after my seemingly strong assertion: "oh, so you
> mean that strlen() is a function?"

I teach in a community college curriculum that uses C++ for the initial two-semester sequence of programming. (Using Gaddis, *Starting out with C++: from control structures through objects*; i.e., control structures 1st semester, objects 2nd semester). The single biggest hump for our students is to accept modularizing their programs into separate functions, which occurs about halfway into the 1st semester.

I think I broadly feel why they really, really don't want to start doing that. They're legitimately able to get a working program by writing all the statements in main() up to the point. The overhead of learning to add prototype, header, code, call (which of those requires the type? the identifier? both?), parameters, arguments, pass-by-value vs. pass-by-reference, return value, scoping rules, what counts as a good name, etc. is not insignificant to them. If they can just get the immediate assignment working without grappling with that new gauntlet of concepts, then they'd generally prefer to do that. Plus the advantage is really not evident at that point: they're not working in a large team-environment where the division of labor really pays off. They're not hitting any radical increase in complexity where it's infeasible to cram a few more lines into main(). Even the textbook's labs and examples are not super hygienic about this.

So I am aware that I really need to hit this very hard all through the last 1.5 terms of our curriculum. I make modularizing programs an explicit requirement for all programs from that point forward, and reiterate in the directions for all assignments and tests. A hefty point penalty is deducted otherwise (i.e., the entire 20% component for "Readability"). I uniquely spend two days reviewing the concept and justification. I uniquely (in any course I teach) have a slide in shouty 120-point font laying out the demand. The book also seems to know this is the major hurdle, as it has a double-length series of labs for that particular chapter.

In brief: Modularizing the code seems like the single biggest hurdle, and the curriculum really must dedicate significant time to getting students on board with it.

Now, in the OP's case they're really in a major dilemma if they're receiving students at the end of a curriculum and this hasn't happened to date. Teaching the early courses in a context of finite state machines, global variables, and no modularity, is perilously close to causing irreparable brain injury in this regard. It's not entirely clear what the OP's context, requirements, or flexibilities are, but solutions probably need to pick from among the following:

1. If the OP has any power over the institutional curriculum, *change it*, so that modularity for future changes and expansions is taught and tested at an early stage.
2. If the OP does not have any power over the rest of the curriculum, but has significant flexibility in their own course design, then they likely should spend 2+ weeks at the start of the course explicitly teaching students this methodology. It's actually not bad to set that as the major theme of the course on Day 1 in a big banner to get their attention (and keep touching back to that all semester long).
3. If the OP hasn't any power over the program's overall curriculum, and also lacks any flexibility for what gets taught in their own course (some kind of mandated higher-level curriculum) then they need to bite the bullet and accept that most of the students are simply not going to be able to interface with higher-level concepts, and fail them. Maybe a one-day "review" at the start of the course, and reference to materials on the subject, is the best you can do.
4. If you have no power over the program sequence, and no flexibility in the individual course design, and are also not allowed to fail most of the students, then what can you do? Resign oneself to giving out fraudulent grades or leave the position, I guess.

There are times when I kind of wish the modularity issue was more up-front, but in my opinion it's even less comprehensible at a point when no task takes the 5-7 statements or so that makes a cognizable function. That is: if initially every function is itself just a single statement then there's no way you can convince students that's not a big waste of time and effort (because it is). So I do think you need to establish data declarations, assignment, conditionals, and loops before you've got enough mechanics that you can legitimately abstract a chunk of functionality into a modular and reusable function.

An anti-example of the latter: there's an open-source work by Busbee, *Programming Fundamentals -- A Modular Structured Approach Using C++* that attempts to present modular functions first and foremost. Ch. 1 introduces a function which is a wrapper around the Windows `system("pause")` statement. But in the need to avoid all the other scoping details at this point, he falls into a trap of using global variables for all the data-passing, and gets stuck with it. I don't think there's any example in the entire text of ever using parameters, local variables, or return values (which is of course absolutely deadly to the cause).

In summary: *Somewhere* in the curriculum you've got to dig in and spend time clarifying this most-difficult-and-important part of the subject matter (modularizing code into functions). You're not going to get it happening by just saying it once and wishing it to be. You need some initial work developing the basic toolkit in the main function, but then need to transition to modular designs, and the longer this gets delayed the more bad habits will need unlearning later on.

> **Comments:**
> **username_2**: When I was self-teaching in 9th grade on a PDP-11 terminal, I wrote simple programs in BASIC (or a script language... I forget after several decades) to create shapes on the terminal screen using asterisks and spaces. This requires nested loops, and pretty quickly rewards creating functions. So, a "**motivating example**" will teach the need for proper design. It is simply too hard to copy-paste the code in multiple places, change it, fix bugs and so on. Then functions seem like "a pretty neat idea." Simplifying the code becomes an organizing impulse. Choose projects that build.  

---

