#fsfthe idea of EASY
starts the same place that many (not all) of us start with coding-- with beginner-level script-like code. the goal cant be for everything to be scripted; you cant really script an operating system kernel or a hardware driver. (even if you could, it would probably be REALLY ugly) and for faster things you must have efficient libraries. thats why its good that many people choose to write that kind of code. but some of us never will, because it isnt necessary and we lack either the interest or the discipline.
starting out this way doesnt mean its all youll ever do. torvalds started with "hello world" in a loop, just like many of us. he went on to write a famous kernel-- certainly not in BASIC, which is the first language he coded in (probably for about 5 minutes).
the code torvalds wrote was ridiculously simple. it started off with this single line:
10 print "sarah is the best"
and then added a second line to make it loop:
20 goto 10
in bash this would be something like:
while [[ 1 ]]
do echo "sarah is the best"
the indents are optional. in python, this would work:while 1: print "sarah is the best"
you have to press CTRL-C to get it to stop.
coding this way requires a lot less discipline than coding in c, but when youre learning to code for the first time, discipline isnt the first priority of most people-- having fun or satisfying your curiosity (or gaining a skill) is. most labour begins as unskilled.
as a prelude to EASY, i toyed for a while with the idea of EASYlangs.
an ESOlang is a language that is created for the sake of being different, obscure, obtuse, or peculiar (or all of these). an EASYlang is a language created with two goals:
- be easy to code in -- ideally even for someone who has never coded
- make the language itself easy to implement (easy-to-CREATE languages)
when you are teaching someone to code, they often get stuck in a variety of ways. i try to help people past this by helping them to create their own EASYlang. so you start with someone like a hello world program--
a hello world program is pretty useless by itself. it just says "hello world" typically. but the purpose of a hello world program isnt to do something useful-- its to create familiarity with coding in a ridiculously simple example.
the purpose of a hello world PROGRAMMING LANGUAGE then, is to create familiarity with creating a programming language (a useless one at that) with the simplest example possible.
so you could for example, just make a language that opens a file, looks for the "hw" command, and whenever it finds it, it says "hello world".
you can implement that as an interpreter which runs the code immediately, or as a compiler which outputs a program that does what the code asks.
is that useful? no more than "hello world" itself. but now the BEGINNER CODER has created a simple programming language-- with a single command.
now they can add a few more commands. as they learn more about coding, they can continue adding to their language or abandon the idea for something more practical. but the odds of their next big game or application being scriptable goes way up! and instead of just writing a plain hello world, they learn a little something about processing text, about opening and closing a file, about loops and conditionals.
if you cant teach that in a week or two, rethink your lesson plan.
at the basic level, a cat command for a single file (a contradiction in terms) is basically this:
- open a file
- read each part of the file
- output each part of the file
- close the file
but its named "cat" because it can conCATenate files. so you want it to:
- open the first file
- read each part of the file
- output each part of the file
- close the file
- continue the same process with each of the other files named
python can do this with binary files, but it is probably more trivial with sequential (text) files:
for each in sys.argv[1:]:
f = open(each)
for eachline in f.readlines():
so you have cat in 6 lines. again, cheating a bit-- these 6 lines bring in all of python.
when i started teaching coding, i looked for the people that were the least interested and least inclined. i tried to make coding as ridiculously simple as possible. the language i created for the task does the above like this:
allfiles = command
forin (each, allfiles)
f = arropen(each)
forin (eachline, f)
now = eachline ; print
unlike the python version, all of the punctuation and indents are optional:
forin each allfiles
f arropen each
forin eachline f
now eachline print
i think the indents help. sometimes the punctuation does as well.
the goal of this language is to have the fewest things to explain, and the fewest questions to answer while teaching someone with no familiarity with coding. does it succeed? short of a scientific study, it might come down to your opinion.
easy doesnt mean that youll never create something complicated like a web browser. instead, it means that if you create something complicated like a web browser, most people will be able to using an easy, lego-like system that doesnt force 8 years of corporate computer science into everyones lap.
we try to make software that is easier for everyone to learn how to work with, whether that means theyre using it or making changes to it.
i know this was the idea behind emacs. with all due respect, no version of emacs (or lisp-like version of lisp) was ever the easiest possible implementation with regards to new users.
lisp inspired logo, and logo is a stupidly-easy to learn language (depending on the dialect).
i loved logo, but i learned basic first. as a coder, i always wondered what a language that crossed the style of logo with the general abilities and features of basic would be like-- until one day i finally started working on something similar to that.
but instead of just using this to transition people to creating applications (inline python is a feature, and lets you call functions written in python as native commands) i would like to see similar languages that transition people towards low-level coding as well.
and instead of lines of code, the soft, sane limit for EASY is the documentation.
if you do cat --help you may decide that cat has too many features. you may not. but if you think back to when you were first learning the command line (or ask enough people who do) theyll probably say "i still dont use all the features of cat".
if you ask the unix experts, theyll probably say that cat has too many features now.
so maybe cat should be two programs. if more things were written in scripts that were "put aside" (made more static in terms of development, maintained mostly around bugs and security flaws) once they reached a sane number of features, it would be trivial for someone else to make a lighter version. it would also generally be unecessary.
instead, we never know when to leave a program alone. we download (and bundle) things we dont need, things we will never use, forcing us to buy new hardware just to manage it.
imagine if you really could go through and just delete the things you dont use-- or download them if you needed them. im not saying we should go "cloud-based"-- not more than say, apt-get is "cloud-based".
just that we are becoming less modular, and it wont go very well. bloat isnt the only thing we need to worry about. users being helpless is the problem im most concerned about. it should be up to them what features their computer is "stuck" with. we arent tending to that, or to them. we arent teaching them, we are letting development houses instead bank on their helplessness.
pardon me, but thats the opposite of what i signed up on this free-as-in-freedom trip for. we need to look around and ask if we are really making users more free-- or if we have simply created a way for microsoft and ibm to get cheaper labour.give the user power over their computer-- or stop talking about free-as-in-freedom, because you dont get it.
(thats not for milo. i like milo, and i am glad hes writing. we need more people to follow his lead in writing about their philosophy).
per the message on my profile, this post is in the public domain. however, it will soon also have a cc0 public domain dedication / waiver.
we "know" the modern version cat is "too complicated" because nobody sane would want to explain everything it does. this is a soft measure, a philosophical measure. i hope it inspires a little bit of sanity in a crazy development world.
eventually if we have some powerful but simple languages (i set a hard limit of 100 commands for mine, and there are sane limits on command parameters too) we can make lighter versions of languages like python to accommodate the creation of these simpler languages.
The freedom to NOT run the software, to be free to avoid vendor lock-in through appropriate modularization/encapsulation and minimized dependencies; meaning any Free software can be replaced with a user’s preferred alternatives (freedom 4). -- Peter Boughton.
pypy is a feature-rich version of python that is actually implemented in a stripped-down version of python. so i dont think this idea is completely hypothetical, just partly. i think it has a practical element to it along with the philosophical one. my warning to those who havent paid attention to whats happened to free software: if you lose the philosophical aspect of what youre making, you often lose the practical element with it. open source for example, failed at separating the two.