2020 figosdev
Chapter 16: Education and Free Software
Summary: "If students learn how to code, they'll be able to figure out the applications."
Education is one of the best ways to get more people interested in Free software. Unfortunately, most people make education more difficult than it needs to be.
"Unfortunately, most people make education more difficult than it needs to be."It is possible to use languages like Javascript and Python (even Java) to introduce programming. Python is an especially popular language for this purpose, because it is easier to learn than Javascript or Java (or C or C++).
There are subjective elements to any sort of argument like this, and there is the general reality. I suspect teachers have less time to learn coding than students do -- some already know how to code, but others struggle.
If every school teacher has at least five students they want to teach coding to, imagine what we could accomplish with tools that make coding easy.
Looking back at previous successes in history, the languages that have helped introduce the most people to coding (people who would not have learned otherwise) include BASIC and Logo.
I love Logo, but people tend to focus on its graphics features -- which are easier to use, unless we are talking about the new breed of block-dragging Logo derivatives which make most tasks easy.
My problem with Logo as a language for schools (unless we are talking about the earliest grade levels) is that it feels "less like programming" to move a Turtle or even drag blocks around to animate a cat.
These tools are amazing, and they can help people who are even younger learn programming concepts. If that's the level you want to start at, these solutions have their place. Likewise, if you want to just start with Javascript or Python, those are already used in teaching and have their advantages (popularity among them).
I tried those as well (I write code in Javascript and Python, targeting PyPy), but I wanted to make writing code as accessible as possible -- so I tried my hand at language creation. I'd made toy languages before, how about a toy language for teaching? In the 1960s at least (when BASIC and Logo were created) it was a revolutionary concept.
Logo (as far as its Turtle features go) is fun and easy in part because its so minimal. If you want to move up, you can just say "up". In some dialects, you can just say "U". Perhaps at its most minimal, you could draw a box like this:
R D L U
Right, Down, Left, Up -- what is someone supposed to think that does? You can trace it with a pencil. You want parameters of course, so you let the user specify distance:
R 5 D 5 L 5 U 5
Now you have a box that can be a specific size. Simple little language, right? But it's getting difficult to follow. We have choices we can make in terms of design here:
r(5) d(5) l(5) u(5)
r5 d5 l5 u5
r 5 ; d 5 ; l 5 ; u 5
I have my own answer to this, but the top is a bit like BASIC or Python, The middle is very Logo-like just because of the lack of punctuation in syntax, and the latter is more like shell code.
These are similarities based on specific examples -- there isn't a specification that defines "shell code" (unless POSIX does) - nor are most dialects of Logo compliant with a standard.
But it's still a very simple language that's easy to teach and learn. I always thought it would be an interesting experiment to try to extend Logo to make it more like BASIC in its capabilities.
While Python says that explicit code is better than implicit, every explicit element adds something you can get wrong. So while you wouldn't design Python code like this:
r 5 d l u
The "5" is implicit. Or perhaps the default value is -- obviously this sort of ambiguity is worth avoiding, except perhaps when it's helpful.
Still, for an example that's very conventional:
color "orange" ; print "hello" ; print "world"
The print command doesn't have a colour parameter, yet we know that both print commands probably use orange.
What we make the first variable implicit?
v 10 ; colour 1 ; print
In this example, we print 10. It make not make a lot of sense, unless you know that each line begins with a variable. If each command has a fixed number of parameters, we can do away with the semicolons:
v 10 colour 1 print
But this runs together, so what if we make the semicolons optional:
v = 10 colour 1 ; print
Then we add special commands that don't share a line with other commands, which Python actually sort of has:
iftrue p
v = 10 ; colour 1 ; print
next
Make enough decisions like these, you can find a balance between very few rules and enough consistency to make the language worth using.
Keep your commands simple, your parameter counts short, your punctuation minimal (or optional) and your language small. You can make it extensible with a more complicated language like Python -- plus, a compiler for a language this simple is easy to take apart and learn from -- you can start from a couple hundred lines of code, work your way up to one or two thousand (for 50 to 100 commands).
Each command is really a short program, so think of it as writing a dozen or two very short programs, and how you would tie them together.
Ideally, coders and teachers would work together more often, helping teachers learn how to create their own languages for teaching.
I realise I'm saying this decades into a world where we train people how to use products, instead of teaching general concepts in the simplest way possible. But it;s my own book and I get to write the advice in it.
Underneath it's all OOP, I like to implement languages in Python, but I can implement languages in my own language. I didn't take the Brown University courses for this, but I like to make things simple when reasonable.
There are all kinds of devices you can run this stuff on. Rather than recommend a specific device, I'll just say: computers exist to be programmed. Users exist to control computers -- the other way around (using computers to control people) is generally speaking, exploiting your customers.
I teach 7 simple programming concepts:
1. variables - 2. input - 3. output - 4. basic math - 5. loops - 6. conditionals - 7. functions
This is how I define a function in my own language:
function yes parameter
iftrue parameter
now "yes, " prints
now parameter print
else
now "yes" print
next
next
Here's a function call:
now yes "dear"
And the output:
yes, dear
I often indent using a bit of Python style, but the indentation (except for inline Python) is optional.
What are the (fewer than) 100 commands for? Stuff I have always used BASIC and Python for -- simple graphics, manipulating files and strings, simple calculations and tallying items, automation.
I have advice for people interested in writing simple programming languages as well:
You can write a "hello world" program, even though its useless. But it shows you a little about how a language works.
You can create a "hello world" programming language, even though it's useless.
You can literally make a language that (when it encounters a helloworld or hello command), says "hello world" on the screen. There's your start.
Now as you would with a hello world program, make your language a little more sophisticated -- just a little. There are tutorials of course, but they won't generally tell you how to keep things simple.
If students learn how to code, they'll be able to figure out the applications. If you keep the syntax easy, you can spend more time on those algorithms people say are what coding is really about.
As to how to introduce teachers to this topic, that's the sort of thing a viable Free software movement could do. I used this to help an art teacher (whose boyfriend had always tried to show her how to code) understand coding better than she had previously.
"And this does this... and this puts it on the screen..."
# count to 10
for each = 1 10 1
p = each ; print
next
...
⬆
Licence:
Creative Commons CC0 1.0 (public domain)
