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 a, an, the and some), and prepositions (like in, of 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?