I wrote a book (free minimum price) to teach my son programming, starting in Terminal, and using Ruby.

https://leanpub.com/programmingforkids

It's currently Mac-only, because of the `say` command, and so that I could write instructions for just one platform. I have ideas about how I'm going to fix that, but that won't be in the near future.

My son was about the same age when I started writing it, but the book scales nicely for any 9-14 year old, I think. Please feel free to give your son a copy, and let me know if it's helpful.

> It's currently Mac-only, because of the `say` command, and so that I could write instructions for just one platform. I have ideas about how I'm going to fix that, but that won't be in the near future.

There's a package on Debian Linux based systems called "gnustep-gui-runtime" which (among a lot of other things) provides the "say" command.

On Linux, there's `espeak`, which is essentially equivalent to `say` on Mac.

Somehow I don't think he was too worried about 9-14 year olds using Linux. Probably was mostly thinking about Windows.

Your comment sound like you think Linux isn't appropriate for 9-14yos ... could you explain, all major OS are pretty much equivalent for simple uses AFAICT.

Espeak claims to also run on Windows (and other platforms): http://espeak.sourceforge.net/

Always feel when a software developer tries to teach coding to kids they seem to more wrapped up in the process and doing things the "correct" way (often over complicating things with typing, language nuance and command line rituals) than actually trying to teach what's really going on and more importantly empowering being able to step off and create something truly of their own which is the path to self sufficient learning.

The self initiated work I've seen kids create out of Scratch is seriously impressive and creative.

I'm trying to get my kids to play Human Resource Machine. I hate the name but the game is okay. Because it's basically drag and drop assembly language the amount of steps for the challenges quickly rises. That's a bit of a shame, but the upside is it does sort of teach how a primitive computer would work at a low level for a kid who was grabbed by it.

The blog author and a commenter make a good point about how back in the day getting the computer to do just about anything was thrilling, whereas now expectations are a lot higher but so is the knowledge and effort required to make that happen.

Switching on a computer and getting nothing but a ready prompt somehow made it easier (or more necessary?) to make your own fun.

Definitely necessary. I remember those days, and the realization that I could run an existing program, or I could sit and make my own, and the latter was pretty appealing to me.

I picked up Human Resource Machine when it came to the Nintendo Switch a few months ago, and I loved it pretty immediately. I think it does a great job of abstracting out the fact that you're writing assembly, masked by their very dark sense of humor (Little Inferno, anyone?). Whenever one of my friends (other grown-ups, not even kids) say things similar to wishing they knew how to program, I suggest they pick the game up and give it a try. It's like jumping in the deep end, but does a good job of showing how to think like a computer would think.

Yeah, it's more for grown-ups who don't know how to code. One of my sons is doing pretty well but I'm keeping a few levels ahead to see what's coming and I'm not sure he'll grok indirect addressing all that easily!

Another son is going through Swift Playgrounds and finding that easier to understand. He couldn't get HRM at all but immediately understood what simple functions were for in Playgrounds.

I think Kotlin would be a much better language to learn programming. Kotlin avoids much of the noise and is very readable.

The hello world example is symptomatic:

    public class Example {
        public static void main(String ...args) {
            System.out.println("Hell, World!");
        }
    }

vs

    fun main(args: Array<String>) {
        println("Hello, World!")
    }

Some more examples:

    // java
    for (Element element : collection)

    // kotlin
    for (element in collection)

    
    // java
    (OtherType) somehting;

    // kotlin
    somehting as OtherType


    // java
    a.equals(b);

    // kotlin
    a == b
  

    // java
    Color color = x < 5 ? Color.RED : Color.GREEN;

    // kotlin
    val color = if (x < 5) Color.RED else Color.GREEN

And some more like constructors just named "constructor", init blocks are name "init", varargs are prefixed with "vararg", type checks with "is", ranges with 1..9, strings wicht embedded variables ...

Kotlin or not, I feel like Java is just the wrong choice. Even Kotlin, there's a lot of noise to start with. What's a function? What's an Array? What's a String? I have to either explain all those things, or handwave it as "magic; ignore it for right now" to students. I would find that incredibly frustrating as both a student, and a teacher.

I TAed an intro to CS class in Python for a number of years. I am rather ambivalent toward Python as a developer, but as a first language to be taught it worked pretty well. There are others, but having the minimum amount of noise for some basic coding examples I think is incredibly helpful (though I admit, I think I'm basically just saying "I think dynamically/optionally typed scripting languages > statically, explicitly typed compiled languages for this task").

I started with Pascal in school (6th grade I think). The book contained a few lines of code and said: This is the smallest program possible: it does nothing.

  program HelloWorld;
  begin
  end.

I was puzzled: why would you need to write something for it to do nothing? But it becomes clear very easily: all programs need to have a special structure to be correctly defined. This structure happens to be a block of code with a name. And that explanation was enough to satisfy me for the moment. I turned a few pages, and sure enough all examples had that structure with something else inside. I was already feeling good with myself for being able to recognize well structured programs.

I agree. I have been doing the Kotlin Koans (https://try.kotlinlang.org/#/Kotlin%20Koans/), and so far it has a lot of nice functionalities that make coding more fun.

Just the way it allows you to create an inmutable class in a single line already makes it way easier to read, while also saving time.

Compare Java:

  public class Person {
      private final String name;
      private final int age;

      public Person(String name, int age) {
          this.name = name;
          this.age = age;
      }

      public String getName() {
          return name;
      }

      public int getAge() {
          return age;
      }
  }

With Kotlin:

  data class Person(val name: String, val age: Int)

Starting in a very-widely-used language is useful though - someone interested in learning further has a wide range of materials, from books to MOOCs, to choose from. Switching from one language to another before they're fully comfortable with the basic ideas of programming is not going to go well.

Pretty nice "Processing via the command line" trick. The API at https://processing.org/reference/ is much more friendly than the Java API at https://docs.oracle.com/javase/7/docs/api/

In the system we have been working on at https://build.games (an engineering platform for kids to learn and make software) we have avoided git and complicated project management systems carefully so far. Sometimes, to really appreciate some tools, one has to live without them first

You seem to have missed that his son had already played with Processing, which uses a simplified Java and a painless graphics API that lets you just put some commands in a file and get to a drawing on screen quickly. Also using it for more abstract projects like addition is not really a bad choice.

You may also be overestimating how much easier Python is to learn for a complete beginner. When I was 12 or so I discovered Python via RenPy (https://renpy.org) and although I could type some simple commands into the REPL, even the fact that you could put your code into a file to execute later was non-obvious to me. My experience with Processing was much smoother in comparison.

In my opinion, you should focus less on syntax and more on getting to an engaging experience with a fast feedback loop.

I started with QBasic and C++ when I was a kid. A lot of my later instruction was in Java, and I don't have a strong argument for why it couldn't've been used as my first language.

Lets try not to incite language flame wars in a discussion that could be super helpful without it.

I do not see Python as the natural choice for a first language. I've even had adult colleagues squint when I tried to explain decorators, or objects and all the self/static/class/method binding nonsense.

OOP in Python is something I really cannot like. I teach the language to children and as soon as I get to objects (which is not avoidable in Python, as many libraries and the language itself use objects) the number of concepts I have to explain is too much and I get the dreaded blank stare. I haven't so far found a short explanation that gives them a good enough grasp on objects that they can start making their own.

Ideally I would like to have to explain few orthogonal concepts, as learning a new concept in the abstract is hard and their mind has little patience for it, and let them experiment as soon as possible. But experimentation needs the minimum mastery required to combine the concepts and get some result. Pyhton's objects tend to expose their functions+struct guts, which does not help.

And don't get me started on warts like the "global" keyword, which makes simple scripts with global state and a few functions (a step into learning functions and structured programming) a frustrating and buggy process. I still cannot understand async/await enough to be comfortable with it, and if Armin Ronacher doesn't either... Meanwhile, languages like Oz do concurrency, with actual parallelism, beautifully.

I'm starting to think Scheme and Smalltalk would be excellent beginner languages. "Here's how to make an s-expr; these s-expr are applications, these are definitions. Now go."

I disagree, I think Python is an excellent first language. While there are many oddities, I think Python lets you ignore them, or defer them to later in the learning process. Python can be pretty much as simple as you need it to be, and I think that's important for teaching programming.

I would not expect to get to objects _properly_ (maybe things like list()) in an introduction to programming course, I think you can get very far with just functions and simple data types.

Then, once you do want to introduce objects, I think Python's class system can be kept simple enough to begin with, and the parts that are inherently tricky (like self) have equivalently tricky parts in most other languages anyway.

I think a course teaching programming that goes into async IO, needs to discuss 'global' (something I've still used only twice in 5 years of Python), talks about decorators, etc, is doing something seriously wrong.

I don't know a lot about Smalltalk, but Scheme is an interesting idea for a first language. I think it could be a good first language, but I would be concerned about what the next step is. Having learnt Python, there are lots of next steps because it has a large and active ecosystem with plenty of opportunities, I'm not sure Scheme has the same, and I feel learning a second language, while Scheme might be good preparation, is not going to be straightforward for someone who has only just learnt to code.

You can. Georgia Tech's intro to CS classes for non-engineers are both Python (the engineering one is Matlab). Objects are introduced at the end, but as a concept OO is largely deferred to the following class, in Java. GT actually used to have the intro class be in Scheme, but switched it to Python a number of years ago, which they've stayed with. I agree though, Scheme would be a good language, but the impedance mismatch to get to more popular languages would be higher (plus have students asking "who uses this?!" Being able to reply "Google" tends to satisfy that question pretty well)

When I was there, at least, the focus was on basic programming concepts, functions, variables, loops, recursion, conditionals, and library interaction was largely imperative, more focused on successful execution than on the organization of the code.

I don't have my computer around, so replying with a throwawy account. Wall of text!

> While there are many oddities, I think Python lets you ignore them

Yes, thankfully. But libraries that will make programming interesting for children usually have a rather sophisticated design, including an object-oriented interface. Pygame is slightly too complex for my taste and installing it on Windows is a pain (not Python's fault). I've tried Pyglet on that platform, despite its hard API, and am I right now comparing two students, one on each framework (although the Pygame one uses pgrun).

Once they've used Python as a means to get a game displayed, it seems easier to teach Python's useful minutiae as it helps them code. Not enough experience to assert this with certainty though.

> Then, once you do want to introduce objects, I think Python's class system can be kept simple enough to begin with, and the parts that are inherently tricky (like self) have equivalently tricky parts in most other languages anyway.

Python's OOP really has more complexity than needed. Smalltalk does objects simpler. Alan Kay used it to teach programming to children (the seventies version, the public '82 version had more stuff, meant for adults.) Children can learn to program _starting_ with OOP, not structured programming, but Python (or Java, or...) will not help you there. It seems to expect its user to understand OOP in terms of structured programming, which a practicing programmer certainly can, but a child with limited abstract thought?

Interestingly, Alan Kay was a lisper, which brings me to...

> I don't know a lot about Smalltalk, but Scheme is an interesting idea for a first language.

Can't be sure without trying it, but probably. The scheme community has projects in teaching CS through game programming, with at least one scheme dialect for games and accompanying IDE where images are first-class objects, displayed in the code.

> I think a course teaching programming that goes into async IO, needs to discuss 'global' (something I've still used only twice in 5 years of Python), talks about decorators, etc, is doing something seriously wrong.

I can see how it came out that way, but I don't teach async IO to children; I try to teach some Python to colleagues from time to time.

As for 'global', was your programming activity the one of a beginner? When you have someone that successfully wrote a single script with variables and control structures, you will want them to start writing functions to complete the introduction to structured programming. You will want to make them reuse the existing state, and once they discover the limitations of it, slowly introduce local variables, scoping rules and so on. My students often have the right reasoning at this stage but forget 'global', _repeatedly_ (that's the important part -- hint of a bad UI), which means I have to explain scoping rules, which seem to them like unnecessary wanking at this point.

Guido's attention to newbie-friendliness is obvious, but Python is old and has accumulated cruft, and its developers have blind spots. Zed Shaw listed some of them. Also don't forget that a professional in IT has developed a thick skin when it comes to complexity, or less charitably, learned helplessness in the face of shitty design. Where we think a system's idiosyncrasies are mere details (or worse, the right way to do things), an innocent mind will refuse to engage.

If you're trying to teach someone OOP with their first language, I think you're doing it wrong. If someone is new to programming, it's far more important that people get an understanding of simple procedural logic first. Anything that gets in the way of that is just likely to put people off.

I don't think Python is a great language longer term, but its simple syntax and lack of ceremony makes it pretty much ideal for beginners.

Alan Kay would disagree, and he's got some experience teaching programming to children. See my answer to your post's sibling.

Why is it far more important that people get an understanding of simple procedural logic first? (And what is it exactly? I've had a 'procedural' feeling when seeing: - assembly code - structured programming (Algol 60 and descendants) - even some kinds of logic programming)

Brother man, I started out with FreeBASIC and (for some reason) Perl when I was 8 or 9. I really don't think it matters too much.