Teaching Kids to Program

We take a different approach to teaching kids how to program here at the Osmosian Order of Plain English Programmers.

The Interface

The first thing we do is remove all unnecessary and distracting clutter. This, for example, is what our full-screen Integrated Development Environment (IDE) looks like:

Alphabetical menus and a status message field at the top, work area in the middle, and tabs at the bottom. No window borders, no widgets, no icons, no tool bars, and no palettes. We thus encourage the student to focus on the content in the foreground, not the background (which we leave in the background where it belongs). Whoops! Almost forgot. No scroll bars. Ever. The right mouse button is used to shove content around — horizontally, vertically, and/or diagonally — and an Incremental Find facility is used to “leap” in large files (ala the late, great Jef Raskin). The Home, End, Page Up, Page Down and Arrow keys are also used, intuitively, to change the focus as necessary.

The file system is exposed to the programmer using full path names. This is the only view the programmer is given: there are no icons, and no alternate views in “open” and “save as” dialog boxes (because we don’t use or need dialog boxes). The students are thus introduced to the exact syntax that they will need to reference files in their programs, and they only have to maintain a single mental image of the file system in their budding brains.

Our student’s applications are also clutter-free. When they clear the screen, it is erased to black, top-to-bottom and side-to-side. Their applications are real, native programs, with access to the whole screen (and computer), so their dreams can come to life exactly as they imagined them. No sandboxes.

The Language

The second difference in our approach is that we program in natural, English-language sentences. Our “keywords” are articles (like aanthe and some), and prepositions (like inof and with, etc) rather than obscure words like CONST and EVAL and INSTANCEOF (which, technically, aren’t real words at all).

We also make a point of concentrating on semantics (WHAT is being said) rather than syntax (HOW it is being said). Routines in Plain English typically have multiple headers so they can be called in various ways. This routine, for example…

To erase the screen;
To blank out the screen;
To wipe off the screen;
To clear the screen:
Unmask everything.
Draw the screen’s box with the black color and the black color.
Refresh the screen.
Put the screen’s box into the context’s box.

…can be called four different ways:

Erase the screen.
Blank out the screen.
Wipe off the screen.
Clear the screen.

The skilled teacher, familiar with the way his students normally speak, typically provides pre-coded libraries of commonly used routines with headers in the “local dialect.” Students are also encouraged to teach the compiler to speak (and think) as they do, by adding headers to existing libraries, and by developing libraries of their own.

The Depth

The third difference in our approach is that we we use the same interface and language for both novices and experts alike. This is a system for kids, but it isn’t just a system for kids. We used this very interface and language ourselves to conveniently and efficiently create the whole shebang: uncluttered desktop, simplified file manager, elegant text editor, handy hexadecimal dumper, native-code-generating compiler/linker, and wysiwyg page layout facility for documentation and other creative writing and drawing tasks. So when the student is ready to dig deeper, he can simply dig. He doesn’t have to invest in a new shovel or find another plot of land. It’s all in one place, from “Hello, World!” to the machine code.

Hello World!

Speaking of “Hello, World!”, this is a version we often use to illustrate the fundamental concepts of sequence, conditional statements, and looping. This is what we tell the students to type in:

To run:
Start up.
Clear the screen.
Use medium letters. Use the fat pen.
Pick a really dark color.
Loop.
Start in the center of the screen.
Turn left 1/32 of the way.
Turn right. Move 2 inches. Turn left.
Write “HELLO WORLD”.
Refresh the screen.
Lighten the current color about 20 percent.
Add 1 to a count. If the count is 32, break.
Repeat.
Wait for the escape key.
Shut down.

And this is what they see on the screen when they run their programs (using the Run command, which is conveniently and intuitively located under the “R” menu):

Desert Landscapes

Programming is a textual, left-brain kind of activity. But students learn best when both sides of their brains are engaged. So most of our introductory exercises produce inspiring, graphical outputs to enliven both hemispheres and the corpus callosum that connects them. Here’s another sample program:

To run:
Start up.
Draw a desert landscape.
Wait for the escape key.
Shut down.

To draw a desert landscape:
Clear the screen.
Draw the sky.
Draw the sun.
Draw the birds.
Draw the sand.

To draw the sky:
Use the lightest sky blue pen.
Imagine a line across the middle of the screen’s box.
Loop.
Draw the line.
Refresh the screen.
Darken the current color about 3 percent.
Move the line up 1 pixel.
If the line is above the screen’s box’s top, break.
Repeat.

To draw the sun:
Pick a spot anywhere in the top middle 1/4 of the screen’s box.
Make a dot between 1/4 inch and 1 inch wide.
Center the dot on the spot.
Draw the dot with the lightest yellow color.

To draw the birds:
Pick a spot in the screen’s box about 1 inch above the middle.
Use the black pen.
Loop.
Move to the spot.
Face east.
Pick a width between 1/8 inch and 1/4 inch.
Draw a quarter circle given the width.
Turn around.
Draw another quarter circle given the width.
Move the spot about 1/2 inch in any direction.
Add 1 to a count. If the count is 3, break.
Repeat.

To draw the sand:
Use the lightest orange pen.
Imagine a line across the middle of the screen’s box.
Loop.
Draw the line.
Refresh the screen.
Darken the current color about 3 percent.
Move the line down 1 pixel.
If the line is below the screen’s box’s bottom, break.
Repeat.

Note the seamless integration of vector graphics and turtle graphics. Here’s the kind of artwork that program produces:

Optical Illusions

Optical illusions are always fun and inspiring. This is one of my personal favorites:

To run:
Start up.
Draw the crooked line illusion.
Wait for the escape key.
Shut down.

To draw the crooked line illusion:
Clear the screen.
Use the fat pen.
Imagine a big box 4 inches smaller than the screen’s box.
Imagine a line across the top of the big box.
Imagine a small box 1/2 inch by 1/2 inch.
Move the small box to the top left corner of the big box.
Loop.
Draw and fill the small box with the white color.
Move the small box right 1 inch.
Refresh the screen.
If the small box is still in the big box, repeat.
Move the small box close to the left side of the big box.
Draw the line with the red color.
Move the line down 1/2 inch.
Move the small box down 1/2 inch.
If the small box is still in the big box, repeat.
Draw the line with the red color.
Use medium letters.
Write “THE RED LINES ARE ALL STRAIGHT AND PARALLEL.”
with the gold pen at the bottom of the screen’s box.
Refresh the screen.

You’re going to need a ruler to check out this result:

Conclusion

It is our belief that the programmer of the future will program his machines much as we “program” an Amazon Echo or an Apple Siri or a Google Home or a Microsoft Cortana today. When, for example, my wife says:

“Echo, set a timer for 12 minutes. Then play a song by the Beatles.”

She’s writing and executing a short program, in English. Now if the devices listed above were themselves programmed in English, well, then we’d really be on the right track. Our Plain English prototype is evidence of the feasibility of such an approach. After all, if we can conveniently write a complete and efficient Compiler and IDE in English, why not an automated assistant? This is the 21st century, last I checked. Why shouldn’t both users and programmers be speaking to our machines in the same language we use to speak to each other?

13 thoughts on “Teaching Kids to Program

  1. “…*he* can simply dig. *He* doesn’t have to invest in a new shovel…”
    “the programmer of the future will program *his* machines”
    “The skilled teacher, familiar with the way *his* students…”
    I would call this a great article, were I not appalled by the misogyny of your pronouns. It’s ironic and somewhat disgusting that you present such an inclusive language using exclusive language.

    Like

    1. I would call that a great comment, were I not “appalled” by the ageism of your remarks. I’m 66 years old and have been using masculine pronouns in their gender-neutral sense my whole life; I really can’t be expected to keep up with every politically-correct grammar-fad that arises.

      Google includes in the definition of “he” these meanings…

      • used to refer to a person or animal of unspecified sex (in modern use, now chiefly replaced by “he or she” or “they”).
      “every child needs to know that he is loved”

      • any person (in modern use, now chiefly replaced by “anyone” or “the person”).
      “he who is silent consents”

      …so I believe my writing, while perhaps not “modern” enough for some, is still intelligible.

      Google also tells me that “78.6% of computer programmers are male,” so my use of masculine pronouns really shouldn’t surprise anyone, even if they are not considered gender-neutral (as I intended them).

      I hope your focus on pronouns didn’t cause you to miss the fact that I included an example of a female programmer in the closing paragraphs of this article:

      “When, for example, my wife says…
      ‘Echo, set a timer for 12 minutes. Then play a song by the Beatles.’
      …she’s writing and executing a short program, in English.”

      And I would like you to know that, next to Niklaus Wirth, it was Grace Hopper who most influenced (and inspired) my thinking about programming languages.

      Like

      1. I believe you have the purest of intentions. Very few people intentionally decide to proliferate harmful gender stereotypes. Unfortunately, not enough people intentionally stop their spread either.
        While your use of ‘he’ as a neutral pronoun certainly matches a dictionary definition, I’d urge you think about how a younger reader would read those words. Young people are impressionable, and also not fully aware of deeper meanings of words, especially ones they use every day. They would think “those examples of the typical programmer are predominantly male”, and perhaps from there “the typical programmer is male”. Oddly enough, the reference to your wife highlights the fact that the other pronouns are male ones; it’d be more tempting to presume that ‘he’ were gender neutral if it were the only type of pronoun used.
        I admit we may have fundamentally different worldviews: I view the ‘78.6% male’ statistic as a challenge to surmount. It tells me that 22% of the potential programmers are missing in action, presumably because they don’t feel welcome. (I would argue that this is getting worse over time, but that’s beside the point.) It’s impossible for me to view the statistic as an excuse to be complacent.

        P.S. Regarding the allegations of ageism, there’s no double standard about a person’s age. Everyone of any age is responsible for fighting discrimination.

        Like

      2. I’m an old white guy. I’m also still capable of learning and changing. Promoting a new programming paradigm and stating you are incapable of change seems poor marketing at least. Reaching the most people possible would seem a good idea, and using language that “stirs things up” could be avoided. The Dawkins vs God example is another one that I’d change.

        I also don’t throw a fit about every use of he when the same article uses an example with a she. Far too much division in the world already. Addressing it is good, name calling is bad.

        But in the end, writing a new language and sharing it freely is wonderful. I’m very much enjoying this reading with the exceptions noted and I look forward to continuing to explore. It’s yours to destroy if you wish. What a loss.

        If it helps at all, here is a history of computing focused on what lead to Javascript, and it makes note (without trying) of all the women who came first:

        https://github.com/JamesNewton/AdvancedRoboticsWithJavascript/wiki#history
        First hacker (no, she wasn’t the first programmer) Ada Lovelace.
        First assembly language: Kathleen Booth
        First general purpose computer language: “Amazing” Grace Hopper (as noted)
        First to advocate for software as a profession: Margaret Hamilton (Also apollo program software lead)

        Tim Berners-Lee invents the World Wide Web. Three women later solve the problems required to make it actually work. Radia_Perlman solved network routing, Sally_Floyd managed network congestion issues, and Elizabeth_J._Feinler guided the development of ARPANET, whois, DNS, RFC’s and other infrastructure which became the modern internet.

        The fact that “78.6% of computer programmers are male,” is a shame, not an excuse. Unrelenting sexism is depriving our society of a solid percentage of good brain power. I hope future programming examples will feature those few female programmers who manage to withstand the sexism and continue on to become lead coders.

        Like

    2. If you think he is hurting his own chances of promoting his work, why don’t you just leave him alone?
      Live and let live.
      This idea that we must forcefully “correct” everyone’s thinking and coerce everyone into our way of thinking is nothing short of fascism.

      Like

  2. I agree that we probably have fundamentally different worldviews. Unfortunately, this is not the place to discuss them. If you would like to continue the discussion, feel free to contact me directly (gerry.rzeppa@pobox.com).

    Like

  3. I am learning functional programming paradigm and think “What if I code as I think, that must be more easier than remember and writing different syntax.”

    Then I found your blog, awesome! You help me understand exactly what is “thinking in declarative ways”.

    After read this article, I feel more easier to build thing by asking my self a question “What to do to resolve that problems?”

    Thank you so much!

    ps: Am I understand you correctly as English is not my mom’s language.

    Like

  4. I am learning functional programming paradigm and think “What if I code as I think, that must be more easier than remember and writing different syntax.”

    Then I found your blog, awesome! You help me understand exactly what is “thinking in declarative ways”.

    After read this article, I feel more easier to build thing by asking my self a question “What to do to resolve that problems?”

    Thank you so much!

    ps: Am I understand you correctly as English is not my mom’s language.

    Like

  5. Yes, it is the same as procedural programming.

    Functional programming strikes me as very unnatural (unless, perhaps, one is a trained mathematician).

    If you want to discuss further, please write me directly (gerry.rzeppa@pobox.com).

    Like

Leave a comment