Look I don’t want to criticise but I’ve got to say, this is the sort of thing that makes kids hate programming.

“Hey kids ready to do some super exciting math in a computer program?” Nah.

I had a computer teacher who managed to make me bored and disinterested with stuff like this, despite me being crazy crazy crazy interested in computers.

The best way to teach kids programming is via programmable graphics I.e visual games making systems. Not written code.

All I can say is it went pretty well for me. Remember that this wasn't a full-on class; it was a "career day" where I had at most 5 minutes with any student, most of whom had no experience with any kind of programming whatsoever. And my main goal was actually to get "normal", not crazy-interested-in-computers children to experience the cognitive dissonance of running `./grade.pl 10000` and seeing it print out "A". My favorite response was the girl who knitted her eyebrows for a few seconds and then exclaimed, "Oh, I see -- you tell it what to do and then it does it!" Yes, exactly. Whatever she ends up doing with her life, her attitude towards computers will different now.

> "Oh, I see -- you tell it what to do and then it does it!"

I love it

Look I don't want to criticise but I've got to say, this is the sort of thing that got me into programming as a kid.

"Hey kids ready to do some super exciting graphics with turtles in a computer program?" Nah.

I had a computer class based on Logo that managed to make me bored and disinterested with stuff like this, despite me being crazy crazy crazy interested in computers. Then as I got older I actually did get into graphics and gamedev, but early on it nearly killed all interest for me.

The best way to teach kids programming is by making sure the kids are engaged, whatever they enjoy doing.

I think you got the wrong takeaway here. It's not about Logo and Perl specifically, it's about making sure that whatever you do, it's enjoyable for the kids. For some that's math, for others it's graphics, for others it's "hacking". Whatever works for one, isn't guaranteed to work for the others.

Just as for some, Perl is pleasure, for others, Perl is pain.

And I didn't do anything like "teaching them perl". In fact, I think I may have actually used bash; and if I were doing it today I'd probably use python. The point was to have something that you could reasonably guess what it was doing from looking at it. You don't have to know anything about perl replace "A" with "E" and vice versa.

And although I wouldn't call this exercise "fun", it's something that connects with a part of their life they understand. Nobody would actually write a script like this, but someone could totally write a function like this as part of a larger program, and have exactly the kind of "bug" that was displayed there; or, could be hacked in exactly the same way.

Kids are sharp enough to know when a skill is going to be useful, even if it's not "fun".

> Kids are sharp enough to know when a skill is going to be useful, even if it's not "fun".

Kids are also a lot less dependent on fun than people think. If they actually feel useful you'd be surprised what they're interested in doing that's not considered fun.

“I had a computer class based on Logo that managed to make me bored and disinterested with stuff like this”

That’s not Logo, that’s the teaching. The whole point of Logo is that it should be 99% self-taught. The teacher’s job is to teach the bits that aren’t naturally discoverable (see my three steps above), and to offer hints and nudges towards rich new areas for exploration should they bog themselves down in old, crude inefficiencies and repetitions.

Bad Logo teaching is making kids memorize what all the buttons are called and what each one does when you push it, of setting “problems” that have one right answer which the student must return or is penalized for being wrong.

Yes the “turtle” was limited, and if all you ever did was draw “turtle graphics” with it then, yeah, you’d quickly grow bored.

But being limited to turtle drawing only was a limitation of the hardware and software of Papert’s time, plus the inability of most adults—particularly those in charge of the purse strings—to see the need to expand that platform to provide other opportunities as well. That damned turtle should’ve been just the first of a myriad of Logo “expansion packs”, but those damned grown-ups couldn’t see that because they lacked the imagination to do so. (Though if they had, they’d have been terrified by the thought: creating kids who think for themselves and can run circles around them—inconceivable!)

Because all those adults saw Logo as was just another hoop to teach students to mechanistically jump through in rote-taught lessons before putting it away and moving onto teaching the next hoop, not as an open-ended user-led tool to be put in the hands of the kids so that they can explore and experiment and teach themselves while pursuing whatever it is that is of interest to them.

That’s the worst thing about authoritarians: all they ever want to do is to make more of the same.

> That’s not Logo, that’s the teaching.

No, it's logo, because we were taught in exactly the manner you describe, to the letter. In fact I might have enjoyed it more if there were more structure.

I hated art class as a kid, and turning computer lab into art class was not something I was ready for back then. At the time I was laser focused on wanting to learn to program, and I saw logo as something different than programming.

You're using this as a weird segway to rant about authoritarians, but you're also telling me that there's a single way to teach kids programming that everyone needs to adhere to, and anyone who doesn't like it was taught wrong. Seems a bit tone deaf.

I've also run elementary school coding classes and my lesson plans and class engagement are largely the same as the OP.

The differences were just that I used Python rather than Perl and the program was a higher / lower game:

  from random import randint
  
  random_number = randint(1, 100)
  guess = 0
  
  while guess != random_number:
    guess = int(input("Guess a number: "))
    if guess > random_number:
      print("Too high!")
    
    if guess < random_number:
      print("Too low!")
  
    if guess == random_number:
      print("You win!")

(there's obviously a lot of ways you'd write this as better code but the point was to teach the absolute basics)

So the basic concept of the program is essentially the same (command line based and integer comparisons) but it's structured as a game. I too encouraged the kids to hack their programs and they loved it! In fact at every stage of the class, from teaching how strings work (eg below)....

  name = input("What is your name? ")
  print("Hello " + name)

...to the completed game, I gave kids time to hack the code and adapt it how they wanted. Kids genuinely loved it. They'd put silly code in as jokes and found it hysterical that the computers repeated their silly code etc. They were very much engaged.

Obviously there will always be outliers who don't enjoy those types of lessons -- I mean everyone is different after all. But this kind of structure for teaching code is actually very effective for engaging the majority of the class.

I teach kids to code (plus other techy stuff) for a living.

Some kids love my robotics classes using MakeCode or MicroPython. Some kids love my data science classes with Python and SQL (I doubt anyone loves the Excel formula :P). Some kids love writing games in Scratch or MakeCode Arcade. Some love writing MakeCode in Minecraft EE. The one thing they all have in common is there are always kids who get turned off by the environment we're using.

Music programming languages could also be fun. Bonus points if you can produce interesting music and interesting graphics at the same time.

When reading your comment I remembered the old LucasArts game called Loom. I wonder if that would be a proper jumping off point for a music language? Of course, my memory could just be bad.

I am probably too young for that :) but this [1] seems a nice list, perhaps there's something similar

[1]: https://github.com/toplap/awesome-livecoding

Different children like different things.

I'd try to frame it in a different way. I think the best way how to get someone excited about programming is to show them how to solve a problem they care about.

Kids like to play games, so creating their own game is a problem they will likely care about. If they spent past 10 hours trying to advance to the next level, then showing them how to hack their way to the next level is probably going to get them excited. If they are stuck in a system where everyone's focus is on their grades, showing them how to hack that system will likely get them excited. Even if it involves doing some math.

Doing things like that was exactly what got me into programming. The first code I ever wrote was an infinite print loop on an atari and that was like the coolest thing in the world to me at the time.

From there I made guessing games and text based rock paper scissor games and stuff. I didn't get into any kind of graphics programming until I was older.

Just being able to tell the computer what to do and make things happen with words on the screen was what got me fascinated with programming.

As a teen I “learnt” C (and later C++) by reading books from the library. I didn’t have access to a C/C++ compiler (the best I had was a Mac Classic and Pascal). I wrote my code with pencil and paper and checked syntax against examples.

Worked well for me — I aced all the C and C++ computer science papers all through 100/200/300-levels at University.

Yeah well, actually I liked that sort of stuff and my daughter like that sort of stuff.

Some kids do like the puzzle aspect of things. And specifically small exercise like this can be fun or not for kids who normally dont like puzzles, if you create the right mood.