everything wrong with free software

 "free as in speech"

### the-end-of-the-free-software-era---chapter-14---education-and-free-software *originally posted:* sep 2022 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. 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 could be accomplished 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 thats 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, generally targeting pypy), but i wanted to make writing code as accessible as possible-- so i tried my hand at language creation. i had 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 its 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 isnt a specification that defines "shell code" (unless posix does)-- nor are most dialects of logo compliant with a standard. but its still a very simple language thats 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 wouldnt 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 its helpful. still, for an example thats very conventional: ``` color "orange" ; print "hello" ; print "world" ``` the print command doesnt have a colour parameter, yet we know that both print commands probably use orange. what if we make the first variable implicit? ``` v 10 ; colour 1 ; print ``` in this example, we print 10. it may 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 dont 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 im 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 its my book and i get to write the advice in it. underneath its all oop; i like to implement languages in python, but i can implement languages in my own language. i didnt 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 will 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 ``` heres 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 literally make a language that (when it encounters a helloworld or hello command), says "hello world" on the screen. theres 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 wont generally tell you how to keep things simple. if students learn how to code, theyll 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, thats 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. after that, she was pointing to various commands and saying "and this does this... and this puts it on the screen..." ``` # count to 10 for each = 1 10 1 p = each ; print next ``` license: 0-clause bsd ``` # 2018, 2019, 2020, 2021, 2022 # # Permission to use, copy, modify, and/or distribute this software for any # purpose with or without fee is hereby granted. # # THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES # WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF # MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR # ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES # WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN # ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF # OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ``` => https://wrongwithfreesw.neocities.org