sitemap: index | fig19 | fig27 | fig29 | fig30 | pzmarkup | figdesign | figcheatsheet | forlanguagegeek | figbert | understandingcomputers
jump to section: #1literacy #2whyfig #3models #4history #5mechanics #6moredetails #7faq #8changelog
you know the mantra: "im [almost] computer illiterate." nonsense... if you can turn on a lamp, you can operate a computer.
what people mean is that theyre software illiterate. and if you can read, there are only three reasons you dont understand your software:
fig is actually part of a mission to solve that final reason, but we wont get anywhere without fixing the first two.
even if software is explained well, the more it is designed without you as the operator in mind, the more trouble it is to explain (and understand.)
there are some abstractions that benefit both teachers and learners; but many more obscure so much that an understanding is going to be something "magic." having a company do all of the magic for you sounds great, doesnt it? and you dont have to worry about any of it...
until of course, when it turns on you. maybe it makes your mic live and bugs your home, or maybe it deletes your library of e-books. less menacingly, perhaps it just doesnt let you do something you want (and should be able) to do. for those reasons and more, an understading of how computers work is essential.
whether youre studying psychology, anatomy or machinery, model building is a gateway to understanding the subject better.
today, people are understanding hardware a little better because theyre buying single-board computers and connecting them to televisions, robots and others inventions they build themselves. if youre inclined to learn some serious coding skills, this is a great way to build computer literacy, fast.
but not everyone wants to build their literacy to that extent. they just want (or think they want) to understand the bare minimum they need to get by.
i believe this is why computer literacy is still treated as something remarkable. everyone wants a superficial understanding of the subject-- as superficial as possible! because theyre convinced that will keep things easy.
this superficial understanding keeps people scratching their heads when the software designed to hold their hand through everything drops them for a new "improved" design. now they will have to start all over again... (please, this time make it more superficial, please!)
underneath all that, everyday computing stays very much the same. we can still break it down into a simpler model.
fig isnt just about explaining a model of working software. it lets you build working models, and do so with arguably the easiest design possible.
before we get on with the design philosophy (because from here its more for people that already write code, but please stick around if youre curious) its worth talking about the history of similar efforts.
the 1960s and 70s saw a revolution in technological education. john kemeny wanted everyone to understand programming and computers, and with thomas kurtz designed a language called "basic" at dartmouth university, which would make learning computers easier for decades to come.
throughout the 80s and 90s, people were still learning how to code in basic. formally, basic has given way to vb and other languages that lend themselves to more "modern" tasks and interactions.
like basic, logo came out of the 1960s and is still widely used to introduce concepts in coding. some versions of logo work by dragging blocks around the screen and connecting them together, some have more features than just drawing lines and shapes and colors, and one version of logo is actually built into the writer application in the libreoffice suite.
its true that i could use any of these languages to teach computers, but what drifts away the least from what i want to demonstrate as a model includes logo, basic and python.
i have watched basic get redesigned again and again, each time gaining a level of complexity that in my opinion defeats the purpose. but its a language i love, and ive used it for decades. i definitely wanted to preserve some of the fun of basic in my own language.
logo: its syntax is more minimalist than basic; to draw up 5 steps in logo, you might have to say as little as "u5" or "u 5". its not trivial to design a more fully-featured language with minimalist syntax like that, and have it stay easy to use.
fig has some of the power i enjoy in python, with a syntax design inspired by logo and by pipes in bash scripting. in basic, colons separate commands while in bash, pipes "|" carry the output of one command to the input of the next. on all but the lines for a few special commands you begin by setting a variable:
now x is set to 0. you can do this explicitly if you prefer:
or put a (strictly optional) command separator between them:
x : 0
perhaps youd like to set it to a string instead:
x : "hello there"
now lets add the "len" command found in both basic and python:
x : "hello there" : len
now instead of being set to "hello there", x is set to len("hello there").
back to a string, add a comment: (single hashes work but i often double them)
x : "hello there" : len : str ## in python: x = str(len("hello there"))
can we concatenate? yes we can:
x : "hello there" : len : str : plus "2358 "
multi-concatenation like python then print to screen:
z : x : times 4 : print ## in python: z = x ; z = z * 4 ; print z
"plus" and "times" also work on numeric variables. here is the program without separators:
x "hello there" len str plus "2358 " z x times 4 print
which prints the following to the screen:
112358 112358 112358 112358
in most lines, fig starts with a variable which becomes the "working variable" or "main variable" for that line, like the working directory in... well, you know the current working directory or you dont.
its important to point out that fig is not designed primarily for people who understand whats being talked about in this section. fig is used as a working model for teaching such concepts, it doesnt require the user to have a pre-existing concept of them.
but to get back to the structure: fig has multi-line commands just like if/end if in basic or indentation in python. in fact, the fig command unindents, for those of you familiar with the concept. the unindent command is called fig because it returns to "fig mode" after a section of inline python:
python ## that was a fig command. now we are writing python in-line. for n in range(7): print n, if 1: pass fig
fig is not generally sensitive to indentation, but it is for inline python. it also tries not to be case-sensitive (unlike python.)
here is the same multi-line snippet without inline python code:
## this is also valid comment syntax in fig. ## i chose it over basics ' because of visibility. for n 0 6 1 ## in basic: for n = 0 to 6 step 1 z n prints " " prints next iftrue 1 pass fig
note the fig command in the final line: remember it unindents, and so is ending the iftrue block. next is an alias for the fig command, so it ends the for/next block (like in basic.)
its helpful to readability to use aliases for fig, but not necessary. you could use "fig" in every such case. you could also use any alias you like in every such case.
fig has a dictionary (call it a hash table if you refer) with most of the fig commands and how many parameters are expected. by design, the goal is to keep it as close to 1 or none as possible, but some commands read the "main variable" and others ignore it. some change the main variable (like a function returns a value,) and others leave it unchanged (like a sub which performs a task and accepts parameters, but doesnt return a value.)
only "quotes for strings." ...the rest is optional.
colons are visual help for example code, or organized code. they do nothing. parentheses would most likely generate an unintended error (except within a string or comment.)
plus, minus, divby, times. aliases are planned: + - / * but the concern is that people will assume order of operations, when fig does math more like pressing buttons on a calculator.
p "hello" len python p = 1 / 3.0 + (p * (3 + 7 * 9) ** 5.7) fig z p print
depends who you ask. for teaching programming its useful now; keeping the command count low is a design goal, and the merits of additions are carefully weighed before implementation.
fig 0.4 * feb 05 2015 * **could be first version of fig**, renamed from 0.3 of its predecessor * **last version that does the following:** * main variable starting line *only zeroes on first use* * for loops have no step parameter (changes in 0.5) 0.5 * feb 07 2015 * "main variable" is zeroed on each use: (arrays will be the exception) * ^ otherwise you have to 0 *or* keep conscious track of every global used * `for` loops are 4 instead of 3-parameter: *var, start, stop, step* * added `topwr`, `mod`, `cos`, `sin`, `sqr` 0.6 * feb 09 2015 * added `system`, `swap`, `time`, `timer`, `hex`, `oct`, `rtrim`, `string`, `tan`, `val` * note that `string` (modeled after the basic command) should be count * str * (string command implemented with wrong param order, fixed in 1.5 / apr 2015) * also note that fig has more reliable string multiplication: `times` 0.7 * feb 10 2015 * implemented `str` command (went unnoticed as placeholder with no effect from 0.4) * features: `lcase`, `end`, `try`/`except`/`resume` * gfx stuff defaults to textmode on vt (even without user calling `textmode` command) 0.8 * feb 14 2015 * **optional** command / param separator `,` changed to `:` for basic users * (`,` will come back in 2.2 when both + several more are allowed) * pygame is now optional ; runs gfx in textmode even if pygame is not installed * no more deps (colorama is still needed for windows users unless they run ansi.sys) == original requirements / goals == * 1. input (keyboard at least) * 2. output (text, graphics, files) * 3. basic math * 4. variables * 5. routines (functions) * 6. conditionals * 7. loops * 8. iteration (doing things with lists, files) > "i would rather inspire people to create their own language than to use a language that doesn't suit their needs. the more languages people write, the better the odds that one will be wonderful to use for many people." == i think there will be a "fig leaf basic" but it will be more like logo == > and now i have an idea for a closer-to-basic dialect with terse syntax which i'll call "fig basic." * jan 25 2015 > "fig basic" is not as descriptive as what i wanted to call it: "pipeline" or "toy blocks." but fig basic is based on the idea of toy blocks. i didn't want to say stacking, because then people will think of things like forth. > note this is NOT a deliberately obtuse stack-based basic. it's based on the idea of a pipeline. > there are no optional parameters. locate ALWAYS is row column: > locate y x > if you want just row 5, you can have a row statement. > but if you want x = "-5" : x = abs(int(val(x))) > it will look like this: x "-5" val int abs > there are two ways to do parameters: we can try to invent ONLY statements with zero or one parameters... OR, > we can try to keep the number down as far as possible. generally to 3 or less. > but they're always fixed. it's much less confusing that way. y mid x 5 1 #### y = mid(x, 5, 1) x left x 7 #### x = left(x, 7) 0.9 * feb 16 2015 * added `ltrim`, `lineinput`, `len`, `asc`, `atn` 1.0 * feb 19 2015 * now has arrays: `p : arr : times 100 # dim p (0 to 99)` * no way to change an existing element yet, although you can add them: p : 7 : print arr ## dim p(1) : p(1) = 7 p : plus 5 : plus 3 : print ## redim _preserve p(3) : p(2) = 5 : p(3) = 3 z p : mid 2 1 : print ## z = p(2) : print z * variables that start a line are zeroed unless they are arrays 1.1 * feb 21 2015 * set an array element using `arrset index value` * current variable can be set to output of `join arrayname string` 1.2 * feb 24 2015 * `else` added * `arrget` added (no need to copy entire array and use mid-- which still works) * `split` added * `arropen` added (read a file to an array without using inline python feature) 1.3 * mar 01 2015 * debug info in divby removed * backwards loops working as intended for first time * `forin`/`nextin` (array-processing for loops) * `ifequal` 1.4 (it says 0.14) * mar 05 2015 * `line` * `not` (converts zero to nonzero, or nonzero to zero) * `arrget` range fixed (begins at 1) * `sgn` * `for` loops support floating step, if step is constant * (1.1 -1.0 -0.10 etc) 1.5 * apr 02 2015 * fixed `string` command, fig had it backwards * in basic it is string(count, string) or string(count, ascii) * should now load files with windows or gnu/linux cr/lf vs. lf, even cr-only * (affects `arropen` and new `arrcurl` command) * `arrcurl` command gets a url. works like `arropen` except for urls * `arrsort` command * `arreverse` command (two rs. could have done 3, but didnt) 1.6 * apr 04 2015 * translator now uses crlf/cr/lf processing that arropen/arrcurl use * `instr stringtosearch stringtolookfor` * `chdir` * `shell` * `arrshell` * `instr` works on strings and arrays * `chdir` changes cwd to main variable ; aborts program if unsuccessful 1.7 * may 02 2015 * improved prints command; updates properly * date (was going to mm/dd/yy like qb, chose mm/dd/yyyy) * arreverse probably faster but: reverse added; does strings+arrays * arrstdin added: array from stdin (forin p stdin works too) * display added: qb64-style graphics screen updates * (without display command, pset just draws a dot and updates. like in qb64, after first time display is issued, graphics commands no longer update except when you call display) 1.8 * may 16 2015 * added ifmore command * added ifless command * improved some parsing of #comments * changed <> to != for python3ness (not compatible with python3) 1.9 * jun 01 2015 * increased support for printing unicode strings 2.0 * jul 01 2015 * open "w": opens current string (containing pathname) for writing * fprint somepathstring: if open, prints to somepathstring * (adds crlf to line for windows, otherwise lf) * close pathstring (containing pathname) * there are no file handles in fig; internally, file handles are stored in a hash table * this means you can only open each file (one mode at a time) once per running script, until it is closed * this is not systemwide, it is per running script * you can open more than one file at a time, as long as theyre different files 2.1 * jul 09 2015 * open, close, fprint commands now have proper internal ids * (this makes fig behave more consistently; existing programs should still work) * flineinput "filepath" implemented * flineinput all you like will not return chr(10) until it reaches eof * if you want an easier way to read files, use arropen * cls finally implemented fig 2.9: (python2, cc0, public domain) http://pastebin.com/F6kBzRxd (cheat sheet)