> To some degree, having spaghetti code and all globals is useful for teaching because it 1) gets people excited to program and see something working and 2) demonstrates why you don't want to do those things. I remember when trying to write my first text based CYOA game, I was so excited to add content to it and see it on screen, but also learned very quickly that having to scroll through 20 pages of if statements was not fun, and why functions would help. I'm not sure if someone explaining "encapsulation" to me would have really taken root.

While I'm certainly no fan of spaghetti code, I think this is an important kind of experience for novices. I, for example, let mentees at work go down a wrong/weird path with their code for a couple weeks when I see bad code patterns or poor choices in algorithms/data structures in order to give us something to discuss and correct later when they start to hit pain points that I, usually correctly, predict they'll hit. I let them know that they're making their life harder, but I don't direct them to change course (some do on their own, others don't). Telling someone who's just learning how to do things the "correct" way (to the extent that there is a singular correct or a small set of correct options) doesn't give them sufficient motivation and experience to actually learn and internalize it. Often you get a kind of cargo cult mentality around the things you teach them since they lack comprehension of why those are good ideas or better ways of organizing code or whatever, or a later rejection of what they're taught because they don't understand the motivation behind it.

Also, letting them go down the path of spaghetti code or confused structures gives an opportunity to teach them refactoring techniques, which even expert programmers still have to apply to systems they develop (most people don't write perfect code on the first pass, and most systems having changing requirements which would render the perfect code imperfect if they did).

One of my favorite authors, Robertson Davies, put this idea nicely in "The Rebel Angels":

> To instruct calls for energy, and to remain almost silent, but watchful and helpful, while students instruct themselves calls for even greater energy. To see someone fall (which will teach him not to fall again) when a word from you would keep him on his feet but ignorant of an important danger, is one of the tasks of the teacher that calls for special energy, because holding in is more demanding that crying out.

It's a quotation that I often keep in mind while helping my kids learn.

Totally agree. In addition, it can just get plain overwhelming. Don't use a global, use a function -> what's a function? -> a subprogram with parameters and return values -> what's a parameter? a variable with scope existing only for the subprogram's duration -> what's scope? -> ... -> what's an abstract syntax tree?

When really they just wanted to increment the score variable by 10.

>- A friend of mine, when showing him the statement 'x = x + 1' was confused; surely, x cannot also equal x+1.

I think the best thing that my CS 101 prof did was always refer to the assignment operator as "gets" so you'd say "eks gets eks plus one" out loud. It really helped divorce assignment and equality in my mind.

There is an implicit and optional 'Let' statement preceding variable assignment BASIC, which was originally derived from FORTRAN (along with the practice of not using it.)

It is less jarring to see:

Let x = x + 1

because it could be read: we have a given value for x, now let us replace that value with x + 1.

Another helpful thing is how many programming languages have "assignment" and "comparison" operators.

I remember TI basic has "=" for comparison, and "<-" for assignment, like, 'A<-5'. That one, to me made, the most sense. "Put the value of 5 in something called A."

iirc in TI-BASIC, assignment goes the other way so you could have "B + 5 -> A" which also helps seeing that the expression would be evaluated before storing (the button to input -> on the calc is STO, short for store).

Similarly, I had a prof that referred to it as "becomes" which made great intuitive sense to me. "x becomes x plus one" makes me think of the variable transforming to the new value.

I’ve read that Dijkstra liked to say “becomes” for the same reason.

You can also say "x is now equal to (the previous x)+1"

x:=x+1 (Pascal)

> A friend of mine, when showing him the statement 'x = x + 1' was confused; surely, x cannot also equal x+1.

Some people say a language like Haskell would be no harder, and maybe even easier, for someone with no previous programming or CS experience, than something like C or Python. Comments like that make me wonder if they're right!

(Haskell is a pure functional language. And so has the same reaction as your friend. Variables are immutable. Anything else would be madness.)

I guess it depends. Maybe for an adult. I learned the rudiments of Atari BASIC when I was seven and the book explained assignment with cartoon pictures of numbers going into boxes. I don’t remember ever being confused about what it meant. You could just try it (oh, X was 7 and now it’s 8, ok). Similarly, control flow wasn’t hard... just follow whichever line number to GOTO next. You could just play with it until it worked. Would seven-year-old me get very far with recursive functions and IO monads? I really don’t think so. So I’ll always have a soft spot for BASIC and how much fun it was. Maybe python in a Jupyter notebook would be a kind of similar experience for today’s kids? But not Haskell.

> Would seven-year-old me get very far with recursive functions and IO monads?

A few years back, there was someone who shared here his experience teaching young kids programming with a simplified/visual Haskell and it was pretty cool. It seems kids without programming preconceptions don't find it all that difficult.

It is interesting to try to think all the way back to the struggles of initially learning and wonder if things that seem difficult now (Haskell, which I know barely anything about) might have made more sense then. I often wonder this about TCL, which looks very weird compared to most languages but is really easy to learn if you remember the "12 rules": https://tcl.tk/man/tcl8.6/TclCmd/Tcl.htm

I learned programming, in part from first book, before I had algebra in school.

When teacher was explaining equations first time. I thought, "this is easy, its just like programming".

I was ten when I first started learning BASIC so it wasn't until a few years later that I first encountered algebra as a late year lesson in math class. By that time x=x+1 was very much ingrained into my way of thinking so I had to unlearn some of that before I could understand algebraic equations. Wonder how many other kids of that era ended up going through the same process.

Every programming class I ever had was using logo on an Apple II, where mostly you just sat around making making the little puck fly off the side of the screen at warp 9.9. Most of the personal computers in the 80s came with a basic interpreter built in and they were largely compatible with each other aside from some syntax differences and the extended screen characters being vastly different. Typing in programs from magazines and writing my own did far more for me then any course I ever took. I dabbled with Turbo Pascal when I got my first IBM knock-off but settled for a little $20 C compiler - Power C - that worked in real mode and spit out DoS executables really quickly. Porting code from Unix to the Power C runtime taught me a lot. Today I write in Go almost exclusively and marvel at how far things have come.

This is tricky, because on one hand, you want to ignore structure and a lot of syntax to just get started, but on the other, you want to see the results and see something real, not just print the sum of two inputs, and you quickly need a real language for that.

Interesting post. This reminded me of what it was like to be a true beginner a very long time ago.

I’d forgotten just how confusing those initial concepts like arrays could be.